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

Схема сети

Немного вернёмся в прошлое и рассмотрим схему моей сети, в которой работает описываемый в этой статье скрипт. В приводимом примере есть два Ethernet-сегмента, связанные между собой более медленным каналом связи через OpenVPN. Сетевой доступ извне полностью ограничен, поэтому возможность использовать в rsync ssh-туннель не используется. Между Ethernet-сегментами всю работу по шифрованию трафика берёт на себя VPN-туннель.

Итак, в каждом сегменте есть сервер и несколько рабочих станций. Количество рабочих станций в принципе значения не имеет, хотя и изображено у меня только две. Схема резервного копирования достаточно проста: все рабочие станции каждого сегмента сети выполняют backup на «свои» сервера, который в свою очередь обмениваются копиями данных между собой.

Разделяй и властвуй

Жизнь давно научила меня при реализации подобных решений на bash (да и не только), не засовывать всё в один файл. Очень важно на этапе реализации чётко разделить программную часть скрипта и его изменяющуюся от системы к системе часть. Очевидно, что перечень архивируемых каталогов и файлов, а также адрес назначения копирования и будут той самой изменяющейся частью. А вот сам «движок» будет везде одинаков, что позволит в будущем, дополнив ваш скрипт новыми возможностями, бездумно скопировать его на все рабочие станции и сервера, не затронув при этом списка копируемых файлов и каталогов и целевого сервера.

Файл конфигурации

Громковато сказано, но по-другому назвать это никак не могу. Итак, выше мы определились, что перечень копируемых файлов и каталогов, а также путь к серверу мы будем хранить в отдельном файле. Этот файл представляет собой обычный bash-скрипт, который будет выполняться из «основного» как только это понадобится. В нём определён адрес сервера и перечень подлежащих копированию файлов в виде массива. Выглядеть это может примерно так:

В переменной DSTURL хранится путь к rsync-серверу и модулю, в который будет производиться архивация данных. Переменная SRCDIRS представляет собой массив со списком каталогов и, возможно, файлов подлежащих копированию. Обратите внимание, что пути к каталогам не заканчиваются слешами!. В массиве EXCLUDEPATTERNS перечислены шаблоны имён файлов, которые rsync будет пропускать при выполнении синхронизации. Сам файл я разместил в /usr/local/etc/rsyncb.conf.

Скрипт

А вот и сам скрипт, выполняющий всю работу.

Скрипт предельно прост. Логику работы я попытался описать в комментариях. Обратите внимание на то, что для синхронизации серверов между собой, во-первых, не создаются дополнительные каталоги в целевом rsync-модуле, а во-вторых, используется дополнительный параметр -R, указывающий rsync использовать относительные имена файлов при копировании.

Установка скрипта

Всё, что осталось сделать — это разместить файлы скрипта на рабочих станциях и серверах и создать задание для cron. Файл конфигурации, как было сказано выше, я рекомендую разместить в /usr/local/etc/rscynb.conf, а файл скрипта — в /usr/local/bin/rsyncb.sh. Не забудьте установить бит, разрешающий запуск скрипта:

После того, как всё установлено и настроено обязательно произведите пробный запуск. Если всё пройдёт успешно, то можно добавить задание в cron:

В приведённом примере запуск скрипта будет выполняться раз в сутки, в два часа ночи. Как уже говорилось выше, не делайте одинаковым время запуска скрипта на всех системах! Особенно это касается синхронизации между собой серверов.

Замечания

• если в вашей сети несколько или более чем несколько участвующих в процессе резервного копирования рабочих станций, то неплохо бы задуматься о том, чтобы не запускать копирование одновременно со всех них. Не забывайте, что ресурсы серверов не резиновые и на них могут рассчитывать другие процессы и пользователи. Таким образом, постарайтесь равномерно распределить время запуска backup-скриптов на ваших рабочих станциях.

To do

• в предлагаемой реализации резервного копирования нет «обратной связи». То есть, если на какой-то рабочей станции удаляется файл, то на сервере он продолжает храниться. Это одновременно хорошо и плохо. Хорошо потому, что вспомнив через год о каком-то нужном вам файле, который вы в порыве или нечаянно удалили, вы всегда сможете вернуть его обратно. Не совсем приятная сторона такого подхода заключается в том, что свободное дисковое пространство отнюдь не резиновое и настанет тот день или ночь, когда копировать новый данные будет уже некуда. Поэтому неплохо бы продумать и реализовать механизм удаления устаревших резервных копий. Как самый простой вариант: например, раз в месяц запускать отдельный скрипт-"чистильщик", который и будет удалять все несуществующие на рабочей станции копии данных. Ну а в идеале, конечно, нужно чтобы перед удалением неактуальных копий сперва выполнялась проверка на предмет времени последнего изменения копии. Это нужно для того, чтобы не получилось следующее. Запуск процесса «чистки» у вас запланирован на 1 число каждого месяца, а 31-го декабря с бокалом водки в руке вы на рабочей станции удаляете /etc или что-нибудь в этом духе. А второго января будет уже поздно пить «Боржоми»... Но если скрипт будет не тупо удалять все неактуальные копи, а сперва просматривать время последнего доступа к файлу, отсчитывать, скажем, месяц, и лишь тогда удалять — вот это будет самое оно.