Удаленное резервное копирование. Пример реализации в FreeBSD

ДЕНИС ПЕПЛИН

Удаленное резервное копирование

Пример реализации в FreeBSD

Резервное копирование, как правило, предусматривает наличие некоторого объема «ручной работы». Обычно это замена съемных носителей. Наличие этого этапа мешает полностью автоматизировать процесс и тем самым накладывает ограничение на частоту резервного копирования, а в некоторых случаях и на его регулярность. Выходом из ситуации может стать создание промежуточных копий на жестком диске. Это позволит, не снижая частоты резервного копирования, уменьшить частоту сохранения данных на съемные носители (а в некоторых случаях и вообще отказаться от него).

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

Пример, о котором пойдет речь, несложно реализовать в любой системе, где есть ssh и tar (последний выбран произвольно и может быть заменен на cpio, pax или даже dump). Тем не менее, поскольку некоторые детали реализации будут различны даже для FreeBSD и Linux, пришлось отказаться от идеи сделать некий универсальный пример, что привело бы только к излишнему усложнению.

Выбор ssh обусловлен необходимостью обеспечить безопасность данных при передаче по сети. Тем не менее, этот выбор сам по себе не освобождает от необходимости принятия дополнительных мер безопасности как по отношению к данным, так и по отношению к серверу, служащему для сохранения резервных копий. Для этого, во-первых, необходимо правильно устанавливать права на файлы, во-вторых, все действия должны быть выполнены под пользователями с минимально возможными привилегиями, и, наконец, в качестве дополнительной меры нелишним будет применить chroot.

Ситуацию с правами на файлы проиллюстрирую на примере:

# tar -cf etc.tar /etc

# ls -l etc.tar 

-rw-r--r--  1 root  wheel  1607680  7 мар 15:51 etc.tar

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

# ls -l /etc/master.passwd

-rw-------  1 root  wheel  6370  6 мар 18:02 /etc/master.passwd

Налицо нарушение безопасности. Исправить ситуацию поможет umask:

# rm etc.tar

# ( umask 077 ; tar -cf etc.tar /etc )

# ls -l etc.tar 

-rw-------  1 root  wheel  1607680  7 мар 16:07 etc.tar

Круглые скобки помогают оставить значение umask в сеансе пользователя неизменным. При вызове из скрипта они, как правило, не нужны.

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

В последующих примерах потребуется различать сервер, с которого производится резервное копирование и сервер, на который сохраняются копии. Назовем первый srv, а второй – backup.

Сначала нужно создать учетную запись на backup. Вручную (vipw) или же с помощью adduser или pw получаем следующее:

backup$ grep "^backup:" /etc/passwd

backup:*:6554:6554:backup:/home/backup:/bin/sh

backup$ grep "^backup:" /etc/group

backup:*:6554:

Идентификаторы пользователя и группы выбраны произвольно, и в вашей системе могут быть другими. Задайте пароль – он потребуется для первоначальной настройки. После пароль не понадобится, так как для автоматизации процесса резервного копирования авторизация по паролю должна быть заменена на авторизацию на основе ключей.

Для настройки применяется программа ssh-keygen. Она генерирует два ключа: приватный и публичный, которые сохраняются в ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub соответственно (если выбраны ключи rsa). Пароль ключа оставьте пустым. Публичный ключ скопируйте на сервер backup в ~backup/.ssh/authorized_keys.

srv# ssh-keygen -t rsa

srv# ssh backup@backup "mkdir -m 700 ~backup/.ssh"

srv# scp ~/.ssh/id_rsa.pub backup@backup:~backup/.ssh/authorized_keys

Теперь, если при входе на backup пароль не запрашивается, беспарольный вход настроен. Пароль для учетной записи backup в /etc/master.passwd необходимо заменить на *.

Для предотвращения доступа к любым файлам за пределами каталога пользователя необходимо использование chroot. Это позволяет довести уровень безопасности до приемлемого при беспарольном входе в систему (что возможно, поскольку пользователь backup не является суперпользователем и даже не входит в группу wheel). Поэтому следующий шаг настройки – вызов chroot при входе пользователя на хост backup. При вызове необходимо задать каталог, который станет новым корневым каталогом и выполняемую команду, которая в данном случае станет новой оболочкой пользователя.

В chroot-окружении можно разместить всю систему, а можно только необходимый набор файлов. По соображениям безопасности (наличие файлов suid в chroot-окружении крайне нежелательно) и экономии свободного места предпочтительнее второй вариант.

Самым минимальным набором является /bin/sh, но нам понадобятся еще /bin/cat, /bin/sleep и /usr/bin/gzip. Возможно, не совсем правильный, но вполне работоспособный вариант – скопировать их из имеющейся системы. При последующем обновлении системы придется обновлять и эти файлы, так что лучше всего создать скрипт, который проделает все сам. Скрипт, приведенный в качестве примера (назовем его makechroot.sh), нужно выполнять из под root на хосте backup, задав в качестве параметра имя пользователя backup.

#!/bin/sh

username=$1

if [ "${username}" = "" ]; then

    echo "Usage: $_ username"

    exit 1

fi

homedir=`pw usershow $username | awk -F: "{print $9}"`

if [ ! -d ${homedir} ]; then

    echo "Error: no such dir ${homedir}"

    exit 1

fi

cd ${homedir}

mkdir -p bin usr/bin

cp -p /bin/sh /bin/cat /bin/sleep bin

cp -p /usr/bin/gzip usr/bin

После подготовки chroot-окружения необходимо определиться со способом вызова chroot. Наиболее универсальный способ – сделать вызов при запуске оболочки пользователя, в этом случае он будет выполнен независимо от способа входа в систему.

Можно указать в качестве оболочки пользователя программу, которая выполняет chroot, а затем вызывает оболочку. Вот пример такой программы:

#include

#include

#include

#include

#include

#define SHELL "/bin/sh"

main (int argc, char **argv, char **envp) {

    char *home;

    gid_t uid, gid;

    home = getenv("HOME");

    if (chroot(home)) {

           perror("");

           exit(1);

    }

    gid = getgid();

    uid = getuid();

    setegid(gid); seteuid(uid);

    if (execvp(SHELL, argv/*, envp*/)) {

           perror("");

    }

}

Поскольку вызов chroot может выполнять только суперпользователь, программу необходимо устанавливать с битом suid. После вызова привилегии суперпользователя больше не нужны: программа устанавливает эффективные идентификаторы пользователя и группы (euid и egid) в соответствии реальным, а затем запускает оболочку /bin/sh.

Вот соответствующий Makefile:

all:

    cc -o chrootsh chrootsh.c

install: all

    install -m 4555 chrootsh /bin/chrootsh

    @if [ -z `grep "/bin/chrootsh" /etc/shells` ] ;

    then

           echo "/bin/chrootsh" >> /etc/shells ;

    fi

clean:

    rm chrootsh

Не забудьте сменить оболочку пользователя на /bin/chrootsh. Вся последовательность действий будет такой:

backup# make install clean

backup# ./makechroot.sh backup

backup# pw usermod backup -s /bin/chrootsh

Теперь можно зайти с хоста srv и убедиться, что все работает:

srv# ssh backup@backup

backup$ echo /*

/bin /usr

Эта команда показала содержимое текущего корневого каталога. Если вызов chroot прошел успешно, это каталог ~backup.

Процедура резервного копирования некоего каталога теперь сводится примерно к следующему:

srv# tar -cf - /somedir | ssh backup@backup "umask 077; cat > somedir.tar"

Опция «f -» указывает tar копировать архив на стандартный выход, который перенаправляется на ssh. На удаленном сервере sshd запускает сначала umask, а затем cat, на стандартный вход которой и подается архив. Небольшая проблема возникает при использовании опции tar –z, поскольку при таком способе копирования размер архива немного изменяется. Для tar это несущественно, а gzip, хотя и распаковывает архив нормально, все же выдает ошибку. Обойти проблему очень просто:

srv# tar -cf - /somedir | ssh backup@backup "umask 077; cat | gzip > somedir.tgz"

Если в целях экономии трафика при передаче по сети должно быть использовано сжатие, его можно включить соответствующей опцией ssh.

Как упоминалось выше, tar можно заменить на любую другую программу резервного копирования. На выбор программы мало влияет тот факт, что копирование производится удаленно, ведь все, что нужно – скопировать архив на стандартный выход.

Если предполагается сохранять файловую систему целиком, лучше всего воспользоваться программой dump: она позволяет с помощью флагов nodump исключать каталоги и отдельные файлы из архива (по умолчанию эти флаги игнорируются на уровне 0), так что после некоторой подготовительной работы можно научиться создавать архивы, содержащие только нужные файлы. По некоторым оценкам dump обеспечивает наилучшее качество резервного копирования, хотя архивы можно распаковать только на такой же файловой системе (в то время как архивы tar может распаковать даже Winzip).

Другой подход, на который ориентирована в первую очередь cpio и с которым может работать tar – упаковка только необходимых файлов. Список файлов для cpio подается ей на стандартный вход, а для tar включается опцией –I (она же –T или —files-from). Этот подход несколько упрощает создание архивов в случае, если нет необходимости сохранять всю систему целиком.

Вот один из способов применения такого подхода:

• Установить систему и все необходимые пакеты.
• Определиться с меткой времени завершения установки. Этой меткой может быть один из только что созданных файлов, или же можно задать ее явно:

# touch /root/startdate

• Создать список установленных пакетов:

# pkg_info > /root/pkg_list

• Отредактировать список пакетов, убрав из него зависимости (опционально).
• Настроить систему и приложения.
• Создать список измененных файлов (который будет состоять в основном из файлов конфигурации):

# find / -newer /root/startdate -print > /root/modfiles

Отредактировать список, добавив туда необходимые файлы и каталоги.

Список, полученный таким способом, нужно периодически обновлять (обычно при изменении конфигурации). Иногда проще добавить целый каталог, чем разбираться с отдельными файлами – tar архивирует каталоги целиком и нет смысла добавлять файлы из каталога, если добавлен каталог (cpio ведет себя по-другому). Не забудьте также про опцию –X, она может понадобиться, если потребуется исключить отдельные файлы и каталоги.

Резервное копирование теперь выполняется так:

srv# tar -I /root/modfiles -cf - | ssh backup@backup "umask 077; cat | gzip > arcname.tgz"

Теперь, выбрав период резервного копирования, можно добавить запись в crontab.

Фактически создан довольно удобный «sandbox», в который можно сбрасывать все что угодно. Но сброшенный туда файл – еще не совсем резервная копия в строгом смысле этого слова. Резервную копию необходимо обезопасить от любых последующих воздействий. Классический метод, которым это обычно делается – запись копии на ленту с последующей ротацией лент и периодическим откладыванием их в архив. Но если у вас есть ленточный накопитель достаточной емкости, совсем необязательно создавать на диске промежуточные копии. Можно сразу указать вместо arcname.tgz имя файла устройства (пользователя backup потребуется включить в группу operator), а cat заменить на dd:

srv# tar -I /root/modfiles -cf - | ssh backup@backup "dd of=/dev/sa0 obs=20b"

Если же ленточного накопителя нет, в качестве сменного носителя можно выбрать компакт-диски. Они далеко не так удобны как ленты, хотя их и можно использовать напрямую почти так же как последние, лишь сменив dd на burncd (для ATA CD-RW):

srv# tar -I /root/modfiles -cf - | ssh backup@backup "burncd data - fixate"

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

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

Конечно, сервера резервного копирования далеко не новость. Выше показано лишь как можно сделать нечто подобное стандартными средствами UNIX, не углубляясь в дебри программирования. Не хватает только одной детали: после создания копии она должна быть перенесена за пределы chroot-окружения пользователя backup.

Попутно можно наладить классическую систему ротации резервных копий (понять, что это такое, можно посмотрев, что делает с логами newsyslog), и написать для этого небольшой скрипт. Можно поступить проще, применив для именования копий команду date, вычищая впоследствии старые копии с помощью find. Последний вариант привлекателен и тем, что не связывает частоту резервного копирования с временем хранения копий и таким образом делает возможным откладывание копий в архив (с возможным сбросом на съемные носители) с любой периодичностью.

Его можно реализовать примерно так:

backup# umask 077; cp ~backup/arcname.tgz /backupdrive/backup/arc`date "+%d%m%y"`.tgz

Имя файла формируется на основе текущей даты, что очень удобно. При желании можно добавить еще и время.

И создание промежуточной копии и перенос копии на хосте backup выполняются из-под root. И если в первом случае это зачастую необходимость, то во втором можно создать второго пользователя, входящего в ту же группу, что и пользователь backup и копировать файлы с его правами. Значение umask при удаленном копировании потребуется изменить на 007, а при переносе копии оставить неизменным. Группа backup должна использоваться только для резервного копирования и ни для чего больше по соображениям безопасности. Еще один вариант – создать пользователя с тем же uid, что и у backup, но с другой оболочкой и выполнять перенос копий с его правами. В зависимости от настроек системы этот вариант может как улучшить, так и ухудшить безопасность копий.

Для автоматизации всего процесса резервного копирования потребуется решить одну небольшую проблему: синхронизировать процесс создания промежуточной копии и ее переноса. Даже если часы обеих серверов синхронизированы, невозможно заранее определить продолжительность процесса создания промежуточной копии. Можно задать заведомо достаточный временной интервал (например, один час), а можно оставлять метку о завершении первого процесса и заставить второй процесс ждать появления этой метки. В две строки это выглядит так:

0 5 * * * cd ~backup; while [ done -ot arcname.tgz ]; do sleep 60; done; umask 077; touch arcname.tgz;

    cp arcname.tgz /backup/srv/`date +\%d\%m\%y`.tgz

0 5 * * * tar -I /root/mfiles -cf - | ssh backup@backup "umask 007; cat | gzip > arcname.tgz && sleep 1 && echo > done"

Первая строка должна быть помещена в crontab на хосте backup, а вторая – на хосте srv. Предполагается, что оба запускаются приблизительно одновременно, хотя на самом деле порядок их запуска и временной интервал между запусками не так уж важен (в разумных пределах).

Проверка на время изменения файла – не самое очевидное решение. Но именно таким способом можно выполнить все действия на хосте backup, не прибегая к учетной записи суперпользователя, а воспользовавшись пользователем из той же группы, что и пользователь backup. Права на домашний каталог пользователя backup лучше всего установить в 750.

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