Единственный 100% способ восстановить утерянные по той или иной причине
данные – это иметь резервную копию. В этом посте я опишу, как настроить
резервное копирование с помощью ssh и crond.
Как нетрудно догадаться, нам понадобятся две машины. На одной хранятся важные
данные и поднят sshd (сервер), на второй имеется crond и место под
хранение резервных копий (клиент).
1. Доступ к серверу без пароля
Поскольку делать backup мы будем по крону, придется настроить доступ к
серверу по identity file. Заходим на сервер, и проверяем, что
/etc/ssh/sshd_config не содержит строчки:
PubkeyAuthentication
no
По умолчанию ее там и не должно быть. Затем переходим в домашний каталог
пользователя, от чьего имени будем делать резервные копии и проверяем, что права
доступа к каталогу .ssh установлены в 700.
На стороне клиента выполняем следующую последовательность команд от
имени пользователя, от чьего имени мы будем производить резервное копирование по
крону:
Здесь мы создали пару ключей для входа на сервер по ssh и скопировали наш
public-key на сервер. Делаем проверку:
ssh user@server
Если нам удалось зайти на сервер без пароля, значит все сделано правильно. В
противном случае внимательно перечитываем эту часть и ищем ошибку.
2. Скрипт резервного копирования
На машине, с моей легкой руки названной клиентом, создаем каталог,
где будет хранится скрипт, запускаемый по крону, и каталог для резервных копий.
Для определенности, у меня это будут ~/cron-backup и ~/cron-backup/backups/
соответственно. Тут важно убедится, что последний каталог находится на разделе,
где достаточно место для хранения резервных копий. Если кто-то вдруг забыл,
проверить свободное место на диске можно командой df -h.
Вот так может выглядеть скрипт резервного копирования:
# переходим в каталог, где
находится скрипт cd/home/client-user/cron-backup
# делаем резервную копию
каталога на сервере ssh user@server \ "tar cvzf -
path/to/data/abc"> \ ./backups/data-abc-`date"+%Y-%m-%d"`.tgz
# делаем резервную копию базы данных MySQL на сервере ssh user@server \ "mysqldump --defaults-extra-file=.dbname_backup db_name | gzip"> \ ./backups/db-name-`date"+%Y-%m-%d"`.sql.gz
# удаляем резервные копии, старше одной недели find ./backups -mtime +7 -print-delete
Файл .dbname_backup на сервере должен хранить настройки подключения
к базе данных db_name и иметь права доступа 600.
[mysqldump] host
= db_host port = 3306 # или другой user =
db_user password = db_password
Меняем права доступа к нашему скрипту и проверяем его работоспособность:
Осталось самое простое – добавить одну строчку в /etc/crontab:
# make backups every
dat at 23:00 # minute hour mday month wday who command
0 23 * * * client-user
/home/client-user/cron-backup/daily-backup.sh
Тут важно помнить о переводе часов на летнее и зимнее время. Чтобы скрипт
регулярно выполнялся ровно один раз, не стоит планировать его выполнение на
период с 2-х до 3-х часов ночи включительно.
4. Заключение
Разумеется, здесь многое можно доработать или сделать по своему. Например,
кому-то нравится говорить «crontab -e» и прописывать команды на автозапуск в
локальном кронтабе пользователя вместо редактирования /etc/crontab. В
daily-backup.sh можно добавить почтовые уведомления администратора системы.
Файлы конфигурации могут хранится в других каталогах, в зависимости от вашей
системы.
В общем, не стоит следовать предложенной инструкции буквально. Если возникли
трудности или вопросы – спрашивайте в комментах, не стесняйтесь.