Skip to content

Автоматизация резервного копирования rdiff-backup

Стоит задача автоматизации инкрементального резервного копирования системных файлов и пользовательских данных на сервере и ряде клиентов с созданием LVM-снэпшотов, где это возможно.

Существует огромное количество решений для backup’а, с внушительными каталогами которых можно ознакомиться, например, по адресам:

  • http://www.debianhelp.co.uk/backuptools1.htm
  • http://www.debianhelp.co.uk/backuptools.htm

Мы же будем использовать rdiff-backup как идеальный (IMHO, of course) компромис между логической простотой, гибкостью и функциональностью для small-medium инсталляций.

Основная идея заключается в следующем: по расписанию на машинах вызывается скрипт, который, в соответствии с настройками в fstab-like файле конфигурации совершает инкрементальное резервное копирование указанных разделов/блочных устройств в локальный или удаленный каталог, предварительно создав LVM-снэпшот раздела (для тех случаев, где это возможно). Инкрементальное копирование означает сохранение лишь различий между двумя backup’ами, что значительно сокращает требования к времени и ресурсам дисковой подсистемы.

Стоит отметить, что основное предназначение приведенных скриптов — облегчить работу именно с блочными устройствами, поскольку с просто файлами/каталогами rdiff-backup отлично умеет разбираться самостоятельно. Поэтому, для случая, когда требуется бэкап лишь нескольких директорий или файлов, приведенные ниже скрипты являются излишними.

Шаг 1: установка

На всех машинах, которые хотим вовлечь в процесс бэкапа, устанавливаем rdiff-backup. В Ubuntu Intrepid сейчас доступна версия 1.1.16, в Debian Lenny — 1.2.5, поэтому, если планируется использовать сервер с Debian’ом, а клиентов на Убунте, необходимо в последней установить rdiff-backup из PPA. Иначе, из-за несовпадения мажорных версий, не будет работать режим удаленного копирования.

Какой-то дополнительной настройки rdiff-backup не требует, могу лишь порекомендовать почитать `man rdiff-backup` и документацию в /usr/share/doc/rdiff-backup.

Шаг 2: backuptab

Резервное копирование будет организовано централизованно (за небольшим исключением, о котором позже).

В файле /etc/backuptab пропишем “план” бэкапа в следующем формате:

# <Block device>\t+<Target backup directory>\t+<Increments keep time>\t+<snapshot>
/dev/orion/betelgeuse	/srv/backup/betelgeuse		1W	1
/dev/sda1		/srv/backup/betelgeuse/boot	1W	0
/dev/orion/data		/srv/backup/data		1W	1

Т.е. это разделенные одним или несколькими табами:

  • Исходное блочное устройство,
  • Целевая директория, в которую будет производится копирование,
  • Максимальный срок хранения инкрементальной информации rdiff-backup,
  • Флаг, указывающий, создавать ли снэпшот перед копированием раздела (что, естественно, применимо только к LVM logical volumes).

Шаг 3: скрипты

Этот файл будет читаться самописным скриптом, который бесхитростно назовем backup.sh.

Данный скрипт читает наш /etc/backuptab, пропускает комментарии и пустые строки и поочередно для каждой строки вызывает worker-скрипт с соответствующими параметрами. Последний делает всю основную работу по созданию снэпшотов, монтированию устройств, вызовам rdiff-backup, etc. Исходник: backup-worker.sh.

Оба этих скрипта нужно разместить где-нибудь в PATH, я кладу их в /usr/local/sbin, этот же путь является значением по умолчанию. Команда для экспорта backup.sh и backup-worker.sh из SVN @ ungrund.org:

# svn export --force http://svn.ungrund.org/dev/adm/backup /usr/local/sbin

При изменении имени или пути двух файлов: backuptab и backup-worker.sh необходимо переопределить значения по умолчанию в главном скрипте backup.sh.

Шаг 4: cron

Теперь осталось добавить в крон вызов backup.sh по расписанию:

0  3    * * *   root    /usr/local/sbin/backup.sh

Шаг 5: клиенты

Бэкап с клиентских машин можно осуществлять по инициативе либо сервера, либо самих клиентов. Я выбрал второй вариант, потому что:

  • В первом случае сильно усложняется процесс создания LVM-snapshot’ов;
  • Клиенты могут самостоятельно выбирать время бэкапа, что, на мой взгляд, просто удобнее.

Записи в backuptab будут выглядеть примерно так:

/dev/blacksun/root	betelgeuse.ori::/srv/backup/blacksun		1W    1
/dev/blacksun/home	betelgeuse.ori::/srv/backup/blacksun/home	1W    1

Где ‘::’ разделено имя сервера и каталог на нем, куда будет производится копирование.

Крон аналогично серверу.

Да, рут с клиента должен иметь возможность логиниться по ssh на сервер по открытому ключу (или иным способом, но без непосредственного ввода пароля, что, естественно, критично для автоматизации). В простейшем случае достаточно будет на сервере изменить значение PermitRootLogin в файле /etc/ssh/sshd_config на without-password и добавить ключ с клиента командой:

# cat /root/.ssh/id_rsa.pub  ssh <servername> 'cat - >> /root/.ssh/authorized_keys'

Шаг 6: Оконец

По времени: первичный локальный бэкап 500Gb занимает порядка четырех часов. Последующие вызовы сокращают время до нескольких минут, в зависимости от количества файлов (AFAIU). По сетке процесс копирования затягивается в разы, так что будьте готовы.

That’s it!

Комментарии приветствуются.