Резервное копирование базы данных и файлов по SSH

22 ноября 2009

Единственный 100% способ восстановить утерянные по той или иной причине данные – это иметь резервную копию. Репликация не спасет вас от случайного удаления таблицы, а RAID – от пожара в дата-центре. В этом посте я опишу, как настроить резервное копирование с помощью ssh и crond.

Как нетрудно догадаться, нам понадобятся две машины. На одной хранятся важные данные и поднят sshd (сервер), на второй имеется crond и место под хранение резервных копий (клиент).

1. Доступ к серверу без пароля

Поскольку делать backup мы будем по крону, придется настроить доступ к серверу по identity file. Заходим на сервер, и проверяем, что /etc/ssh/sshd_config не содержит строчки:

PubkeyAuthentication no

По умолчанию ее там и не должно быть. Затем переходим в домашний каталог пользователя, от чьего имени будем делать резервные копии и проверяем, что права доступа к каталогу .ssh установлены в 700.

На стороне клиента выполняем следующую последовательность команд от имени пользователя, который будет производить резервное копирование по крону:

ssh-keygen
cat ~/.ssh/id_rsa.pub | ssh user@server "cat >> .ssh/authorized_keys"

Здесь мы создали пару ключей для входа на сервер по ssh и скопировали наш public-key на сервер. Делаем проверку:

ssh user@server

Если нам удалось зайти без пароля, значит все сделано правильно. В противном случае внимательно перечитываем эту часть и ищем ошибку.

2. Скрипт резервного копирования

На машине, с моей легкой руки названной клиентом, создаем каталог, где будет хранится скрипт, запускаемый по крону, и каталог для резервных копий. Для определенности, у меня это будут ~/cron-backup и ~/cron-backup/backups/ соответственно. Важно убедится, что последний каталог находится в разделе, где достаточно место для хранения резервных копий.

Вот так может выглядеть скрипт резервного копирования:

#!/bin/sh
# daily-backup.sh script
# (c) Alexandr Alexeev 2009 | http://eax.me/

# переходим в каталог, где находится скрипт
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

Примечание: Помните, что для получения горячей копии базы данных в непротиворечивом состоянии необходимо использовать утилиту mysqldump с флагом --lock-tables (возможно, --lock-all-tables – см man) в случае с MyISAM или --single-transaction в случае с InnoDB. При резервном копировании файлов может быть целесообразно создать снапшот файловой системы (см пятый пункт шестого выпуска мини-заметок).

Файл .dbname_backup на сервере должен хранить настройки подключения к базе данных db_name и иметь права доступа 600.

[mysqldump]
host            = db_host
port            = 3306 # или другой
user            = db_user
password        = db_password

Меняем права доступа к нашему скрипту и проверяем его работоспособность:

chmod u+x daily-backup.sh
./daily-backup.sh
ls -la backups

Дополнение: Также хорошо зарекомендовала себя утилита rsync. В отличие от tar rsync производит копирование только измененных и созданных с прошлого бэкапа файлов (а также удаляет удаленные) вместо того, чтобы каждый раз производить полное копирование. Пример Makefile, использующего rsync:

# Мейкфайл для синхронизации файлов
# (c) 2011 Александр Алексеев | http://eax.me/

# не забываем слэши на конце!
REMOTE=user@example.ru:path/to/directory/
LOCAL=./
# кстати, при LOCAL=./ сам мейкфайл тоже синхронизируется :)

put:
  rsync -e ssh --progress --del -zutr ${LOCAL} ${REMOTE}
get:
  rsync -e ssh --progress --del -zutr ${REMOTE} ${LOCAL}

Для резервного копирования говорим «make get», для восстановления файлов – «make put».

3. Запуск скрипта по крону

Осталось самое простое – добавить одну строчку в /etc/crontab:

# make backups every dat at 23:00
# minute hour mday month wday who         command
  0      23   *    *     *    client-user /path/to/daily-backup.sh

Тут важно помнить о переводе часов на летнее и зимнее время. Чтобы скрипт регулярно выполнялся ровно один раз, не стоит планировать его выполнение на период с 2-х до 3-х часов ночи включительно. Перевод часов на зимнее время отменили, так что головной боли теперь меньше.

4. Заключение

Разумеется, здесь многое можно доработать или сделать по своему. Например, кому-то нравится говорить «crontab -e» и прописывать команды на автозапуск в локальном кронтабе пользователя вместо редактирования /etc/crontab. В daily-backup.sh можно добавить почтовые уведомления администратора системы. Файлы конфигурации могут хранится в других каталогах, в зависимости от вашей системы. В общем, не стоит следовать предложенной инструкции буквально.

Дополнение: Восстановление из бэкапа рассмотрено в статье Мой опыт переноса блога с шаред хостинга на VDS. Также вас может заинтересовать статья Скрипт на Python для создания оффлайн копии блога.