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

Схема сети

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

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

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

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

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

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

# rsyncb configuration file
# @version 10.5.4

# Destination URL to sync
# This URL must be URl of rsync MODULE
# Example: rsync://hostname/module_name
DSTURL=rsync://myserver/backups
# Source files, directories to sync
SRCDIRS=(\
	/etc \
	/usr/local \
	/var/log \
	/home \
	)
# Filenames patterns to exclude
EXCLUDEPATTERNS=(\
	*.[mM][pP]3 \
	*.[mM]3[uU] \
	*.[wW][mM][aA] \
	*.[aA][vV][iI] \
	*.swp \
	)

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

Скрипт

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

#!/bin/bash
#
# Performs rsync from this host to another
# Configuration must be placed into /usr/local/etc/rsyncb.conf
#
# @version 10.5.4

# Проверяем, доступен ли файл конфигурации для чтения
[ ! -r /usr/local/etc/rsyncb.conf ] && {
	echo "Configuration file not found"
	exit 1
}

# Выполняем файл конфигурации
. /usr/local/etc/rsyncb.conf

# Если в имени этого хоста нет фрагмента "server"
# (у меня все сервера имеют в имени такой суффикс),
# то есть, иными словами ЕСЛИ ЭТОТ ХОСТ - НЕ СЕРВЕР,
#  то в модуле назначения нам нужно будет создать каталог с именем этого хоста.
# При синхронизации серверов между собой, такого делать не требуется.
{ echo ${HOSTNAME} | grep -vq server; } && DSTURL=${DSTURL}/${HOSTNAME}

# Определяем, доступна ли rsync
RSYNCBIN=`which rsync`
[ ! -x ${RSYNCBIN} ] && {
	echo "rsync not found"
	exit 1
}

# Определяем параметры, которые будут передаваться rsync
RSYNCFLAGS="-vau"

# При синхронизации серверов дополнительно
# будет использоваться параметр -R
{ echo ${HOSTNAME} | grep -vq server; } && RSYNCFLAGS=${RSYNCFLAGS}R

# Формируем значение параметра --exclude для rsync
EXCLUDESTR=""
for PATTERN in ${EXCLUDEPATTERNS[@]}
do
	EXCLUDESTR="${EXCLUDESTR} --exclude ${PATTERN}"
done
# Поехали!
for DIR in ${SRCDIRS[@]}
do
	echo "Start rsync ${DIR}"
	${RSYNCBIN} ${RSYNCFLAGS} ${EXCLUDESTR} ${DIR} ${DSTURL}
	echo "Finish rsync ${DIR}"
done

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

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

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

chmod 0755 /usr/local/bin/rsyncb.sh

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

sudo crontab -e

0 2 * * * /usr/local/bin/rsyncb.sh

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

Замечания

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

To do

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