Backup в Linux: настраиваем rsync-сервер

2010-05-05 от ashep

Систем для создания и управления резервными копиями в Linux создано великое множество. Не столько создано, сколько портировано с других систем, но суть та же. Понятное дело, что если вы администрируете сеть предприятия, состоящую ну никак не из десятка компьютеров, а являющую собой большой парк машин, то вам вполне подойдёт что-то вроде Amanda или ей подобных. В этой заметке я не буду рассматривать такой случай. Здесь я хочу рассказать о простом и удобном для меня способе создания резервных копий важных данных, имея в наличии небольшой набор компьютеров и установленную по-умолчанию практически во всех дистрибутивах утилиту rsync.

Почему rsync?

Вообще, когда мы говорим о резервном копировании данных, то мы как правило имеем ввиду копирование этих самых данных из места А в место Б на случай, если с данными в месте А что-то случится и они станут недоступными. Вариантов места Б множество: оптические диски, стримеры, жёсткие диски, короче всё, что может данные хранить. Одним из наиболее важных требований к хранилищу резервных копий является требование, чтобы хранилище физически располагалось подальше от основного места хранения данных. Понятное дело, что случившийся пожар не будет разбираться какой сервер уничтожать, а какой оставлять, поскольку у вас там резервные копии.

Раз уж речь идёт о географической распределённости и использование каналов передачи данных, то уже при более-менее существенном объёме данных может резко встать вопрос о нагрузке на используемый канал передачи. Именно по этой причине эффективность cp, rcp, scp и прочих инструментах, копирующих изменённые файлы целиком, снижается в разы.

rsync, разработанная как замена rcp, позволяет копировать файл не целиком, а частично, лишь изменённые его части. Для этого используется алгоритм, предложенный Andrew Tridgell и Paul Mackerras. Об этом алгоритме достаточно много написано, в том числе и на русском языке, поэтому всех интересующихся отсылаю по ссылкам.

Немного об rsync

Что rsync умеет:

• синхронизировать целые каталоги и файловые системы;
• сохранять при синхронизации символические и жёсткие ссылки, владельцев файлов/каталогов, права доступа, файлы устройств и временные метки;
• для работы программы не нужны права суперпользователя;
• использование внутренней конвейерной обработки снижает время обработки нескольких файлов одновременно;
• может использовать rsh, ssh или же просто сокеты в качестве транспорта.

rsync может синхронизировать файлы как в пределах локальной системы, так и за её пределы, а также из-за её пределов. Правда выполнять синхронизацию между двумя удалёнными системами она, к сожалению, не умеет :(

Существует два способа связи rsync с удалённой системой: через оболочку, например ssh, или же при помощи подключения к rsync, запущенной на удалённой системе в режиме демона. Поскольку rsync никак не шифрует трафик, то при использовании незащищённого соединения предпочтительней, конечно, использовать ssh в качестве транспорта. В данной статье, однако, я использую «родной» rsync-транспорт для примеров. Делаю это сознательно лишь с целью осветить настройку rsync-демона и об ипользовании ssh-транспорта, надеюсь, ещё расскажу в будущем.

Структура сети

Как говорила некогда моя учительница русского: «У каждого свой Пушкин». Думается, что и сеть у каждого своя :-) В качестве примера я привожу свою небольшую сеть и свою схему резервного копирования. Для своих же собственных нужд, я уверен, вы сотворите что-то своё, невероятное и неповторимое, как тот самый велосипед :-)

Итак, у меня имеется два сервера (я использую их оба, ибо чем больше копий — тем спится спокойней), разделённых большим расстоянием и каналом связи пропускной способностью порядка 15 Мбит/сек. К каждому из серверов посредством стамегабитного Ethernet подключены рабочие станции, с которых я и делаю резервные копии. Назовём сервера именами S1 и S2, а рабочие станции — буквами P1 и P2. Что-то наподобие этого:

Схема резервного копирования

От того, насколько тщательно вы продумаете схему резервного копирования ваших данных, зависит многое: от эффективности использования каналов передачи данных до корректности выполнения самого копирования. Конечно, если вы просто копируете каталог из точки А в точку Б — мало что может произойти непредвиденного. Однако если вы собираетесь организовывать хранение копий на нескольких серверах, то обязательно всё продумайте как можно тщательней.

В моём же примере всё достаточно просто. Рабочая станция P1 копирует данные на сервер S1, а рабочая станция P2 — на сервер S2. После чего между серверами происходит обмен содержимым каталогов с резервными копиями. Таки образом резервные копии данных каждой рабочей станции оказываются и на одном, и на другом серверах.

Очень важный момент в такой схеме — это исключить одновременный запуск синхронизации с S1 на S2 и S2 на S1, поскольку это увеличит загрузку и без того загруженного канала передачи, а также потребление ресурсов самих серверов, на которых помимо rsync ещё есть чему работать. И второй момент: думаю, логично постараться избежать запуска межсерверной синхронизации одновременно с работающим процессом резервного копирования данных с рабочей станции. Не забудьте об этом позаботиться во время настройки выполнения скриптов в cronе.

Настройка rsync-демона

Как правило в дистрибутивах Linux/Unix утилита rsync включена по-умолчанию в перечень устанавливаемых программ. Если вы сомневаетесь в том, что она присутствует в вашей системе, проверьте это командой:

which rsync

Далее в статье подразумевается, что у вас установлена Ubuntu 10.04 Server Edition. Я не знаю, насколько в других дистрибутивах всё так же, как и в ней, но у меня кроме неё ничего нет, поэто всё буду показывать на примере этого дистрибутива.

Итак, первым делом необходимо проверить, настроен ли автоматический запуск демона rsync при загрузке системы. Для этого просмотрите содержимое файла /etc/default/rsync и убедитесь, что RSYNC_ENABLE=true.

Теперь необходимо создать файл конфигурации демона. Он должен находиться в /etc/rsyncd.conf. По-умолчанию он отсутствует, поэтому даже с RSYNC_ENABLE=true демон запуститься не сможет.

Немного о структуре файла /etc/rsyncd.conf. Формат файла достаточно прост и идентичен ini-файлам. В нём описываются «глобальные» параметры, контролирующие поведение демона в целом, а также «модули», описывающие доступ к конкретным каталогам файловой системы. Обо всё этом можно в полном объёме ознакомиться при помощи man rsyncd.conf, я же ограничусь использованием нужных мне параметров с их описанием.

Глобальных параметров менять никаких не пришлось, поэтому я сразу перешёл к настройке модуля.

Прежде чем мы будем описывать модуль, необходимо определиться в каком каталоге мы будем хранить получаемые от удалённых компьютеров данные. В моём примере это будет каталог /var/backups/my_network. Для обоих серверов конфигурация модуля будет идентична, за исключением, естественно, параметра hosts allow.

Рассмотрим, что у меня получилось:

[backups]

comment = For backups

path = /var/backups/my_network

use chroot = true

uid = backup

gid = backup

log file = /var/log/rsyncd/backups.log

read only = false

write only = false

hosts allow = s1 p2

hosts deny = *

transfer logging = false

• Описание каждого модуля начинается с его имени, заключённого в квадратные скобки;
• параметр comment может содержать комментарий к модулю, которое будет видно удалённой системе при просмотре перечня модулей этого сервера;
• параметр path содержит путь к каталогу на файловой системе, с которой будет работать данный модуль;
• параметр use chroot заставляет rsync после установки соединения выполнить chroot в каталог, указанный в параметре path. Это повышает безопасность, однако для использования этого параметра демон должен быть запущен суперпользователем;
• параметры uid и gid заставляют rsync после установки соединения вести всю работу с файлами от имени указанных пользователя и (или) группы;
• log file указывает демону место для ведения протокола работы;
• параметры read only и write only, установленные в false разрешают удалённой системе работать в модулем в как в режиме чтения, так и в режиме записи;
• hosts allow и hosts deny задают перечень хостов (разделённых пробелами), которым разрешено и запрещено работать с модулем;
• параметр transfer logging управляет ведением подробного протокола принятых/отданных данных. Устанавливать значение этого параметра в true я рекомендую разве что в целях отладки, поскольку размер этого файла будет стремительно расти при регулярных синхронизациях. Хотя, если уж очень нужно, можно и logrotate на него натравить.

После создания и сохранения файла /etc/rsync.conf проверьте, чтобы пользователь, указанный в параметре uid имел право на запись в этот каталог.

Теперь, когда конфигурационный файл создан и всё проверено, можно запускать демон rsync:

sudo service rsync start

Проверить состояние демона вы всегда можете проверить командой:

sudo service rsync status

Если демон был успешно запущен, то можно попробовать подключиться к нему по протоколу rsync и получить список доступных модулей:

rsync rsync://localhost

В ответ вы должны получить примерно следующее:

backups For backups

Первое — это имя модуля, а второе — это комментарий к нему.

На этом процесс настройки rsync-сервера для приёма резервных копий от rsync-клиентов можно считать завершённым. В следующих статьях мы рассмотрим работу rsync со стороны клиента и автоматизируем процесс создания резервных копий, а также синхронизацию их между серверами.