Автоматизация резервного копирования 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 пропишем “план” бэкапа в следующем формате:

# \t+\t+\t+
/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 ‘cat — >> /root/.ssh/authorized_keys’

Шаг 6: Оконец

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

That’s it!

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



Запись опубликована в рубрике Скрипты, Софт с метками , . Добавьте в закладки постоянную ссылку.


Поделиться с друзьями




Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *