Автоматизация резервного копирования в Linux

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

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

Простая схема резервного копирования

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

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

Листинг 1. Shell-скрипт arc

 #!/bin/sh 
 tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1 
 exit $?

Скриптarc принимает в качестве параметра путь к файлу или каталогу, послечего создает архивный файл, имя которого содержит текущую дату.Например, для архивирования каталога beoserver скрипту arc необходимопередать путь к нему, после чего будет сформирован сжатый архив,имеющий имя приблизительно следующего вида:beoserver.20040321-014844.tgz

Упорядочить архивные файлы поможет включение в их имена даты и времени с помощью команды date.Дата имеет следующий формат: год, месяц, день, час, минуты, секунды -секунды, вероятно, в нашем случае уже лишние. О параметрах команды dateможно узнать из ее руководства, просмотреть которое можно командой man date. Кроме того, в листинге 1 мы используем параметр -v (verbose, подробно) команды tar. Команда tar, запущенная с данным параметром, отображает имена всех архивируемых файлов. Если этого не требуется, параметр -v можно убрать.

Листинг 2. Архивирование каталога beoserver

  $ ls 
 arc beoserver 
 $ ./arc beoserver 
 beoserver/ 
 beoserver/bookl.dat 
 beoserver/beoserver_ab_off 
 beoserver/beoserver_ab_on 
 $ ls 
 arc beoserver beoserver.20040321-014844.tgz

Сложные схемы резервного копирования

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

Мы будем решать эту проблему в следующем примере,основанном на некоторой распределенной сети, схема которой, приведеннаяна рисунке 1, включает системного администратора, имеющего доступ кдвум удаленным серверам и внешнему хранилищу данных.

Рисунок 1. Распределенная сеть

Резервныекопии файлов, находящихся на Сервере №1 и Сервере №2, будут безопаснымобразом передаваться во внешнее хранилище; весь процесс распределенногорезервного копирования будет выполняться полностью автоматически нарегулярной основе. Мы воспользуемся стандартным набором инструментов, вкоторый входят программы из пакета Open Secure Shell (OpenSSH),ленточный архиватор (tar) и служба планирования задач cron. В общемвиде наш план заключается в использовании cron для планирования задачрезервного копирования, реализованных с помощью shell-скриптов иленточного архиватора tar. Защищенная оболочка (ssh) будет обеспечиватьшифрование трафика и аутентификацию пользователей, а программазащищенного копирования (scp) – автоматизацию передачи файлов.Предварительно рекомендую ознакомиться с руководствами по использованиювсех перечисленных инструментов.

Защищенный удаленный доступ с использованием открытых/закрытых ключей

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

На каждом компьютере,задействованном в процессе резервного копирования, должна быть запущенаслужба защищенной оболочки OpenSSH (sshd). Используемый службой порт 22должен быть открыт для данных машин на всех промежуточных сетевыхэкранах. Если вы работаете с удаленными серверами, велика вероятность,что вы делаете это с помощью защищенной оболочки.

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

Для начала проверим, установлен ли пакет OpenSSH, и выясним номер еговерсии. На момент написания этой статьи последним выпуском OpenSSH былаверсия 3.8, увидевшая свет 24 февраля 2004 г. Рекомендуетсяиспользовать наиболее свежий и стабильный выпуск, по крайней мере болеепоздний, чем версия 2.x. В настоящий момент OpenSSH является вполне стабильной программой, неимеющей уязвимостей, обнаруженных в других SSH-инструментах.

Для отображения версии программы выполните команду ssh с параметром V (прописная буква):

$ ssh -V OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f

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

Нашим первым шагом будет вход на сервервнешнего хранилища под учетной записью, которая будет иметь доступ ксерверам 1 и 2 (рисунок 1).

$ ssh accountname@somedomain.com

После входа на сервер внешнего хранилища создайте пару из открытого исекретного ключей, запустив программу ssh-keygen с параметром -t dsa. Параметр -tявляется обязательным и используется для указания типа ключашифрования, который требуется сгенерировать. Мы воспользуемсяалгоритмом Digital Signature Algorithm (DSA), позволяющим применятьновый протокол SSH2. Дополнительную информацию по данному вопросу можнополучить, ознакомившись с руководством к программе ssh-keygen.

После запуска ssh-keygen вам будет предложено указать каталог, вкотором будут созданы файлы ssh-ключей, после чего будет запрошенпароль. Если на вопрос о каталоге для сохранения ключей ответитьпростым нажатием Enter, программа создаст скрытый каталог .ssh (если онне был создан ранее), в котором будут находиться два файла, содержащиеоткрытый и секретный ключи.

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

Листинг 3. Старайтесь выбрать хорошую парольную фразу

 [offsite]:$ ssh-keygen -t dsa 
 Generating public/private dsa key pair. 
 Enter file in which to save the key (/home/accountname/.ssh/id_dsa): 
 Enter passphrase (empty for no passphrase): (enter passphrase) 
 Enter same passphrase again: (enter passphrase) 
 Your identification has been saved in /home/accountname/.ssh/id_dsa. 
 Your public key has been saved in /home/accountname/.ssh/id_dsa.pub. 
 The key fingerprint is: 
 7e:5e:b2:f2:d4:54:58:6a:fa:6b:52:9c:da:a8:53:1b accountname@offsite

Поскольку каталог .ssh, создаваемый ssh-keygen, является скрытым, чтобыего увидеть, необходимо выполнить команду ls с параметром -a.

[offsite]$ ls -a . .. .bash_logout .bash_profile .bashrc .emacs .gtkrc .ssh

Перейдите в скрытый каталог .ssh и выведите его содержимое:

[offsite]$ cd .ssh [offsite]$ ls -lrt id_dsa id_dsa.pub

Видно, что в скрытом каталоге .ssh находятся файлы секретного (id_dsa)и открытого (id_dsa.pub) ключей. Просмотреть содержимое этих файловможно с помощью текстового редактора, например, vi или emacs, иливоспользовавшись командами less или cat. При просмотре содержимогофайлов вы увидите, что оно состоит из алфавитно-цифровых символовкодировки base64.

Далее нам потребуется скопировать иустановить открытый ключ на серверы 1 и 2. Не нужно использовать дляэтого ftp. Вместо этого воспользуйтесь программой защищенногокопирования.

Листинг 4. Установка открытых ключей на удаленные серверы

 [offsite]$ scp .ssh/id_dsa.pub accountname@server1.com:offsite.pub 
 accountname@server1.coms password: (enter password, not new passphrase!) 
 id_dsa.pub 100%  -> ***************************** ->  614 00:00

 [offsite]$ scp .ssh/id_dsa.pub accountname@server2.com:offsite.pub 
 accountname@server2.coms password: (enter password, not new 
 passphrase!) 
 id_dsa.pub 100%  -> ***************************** ->  614 00:00

После установки новых открытых ключей мы сможем заходить на каждый изсерверов, используя парольную фразу, указанную при создании открытого исекретного ключей. А пока войдите на каждый из серверов и добавьтесодержимое файла offsite.pub в конец файла authorized_keys,находящегося в каталоге .ssh. Это можно сделать с помощью текстовогоредактора или команды cat:

Листинг 5. Добавление offsite.pub к списку авторизованных ключей

 [offsite]$ ssh accountname@server1.com 
 accountname@server1.coms password: (enter password, not new 
 passphrase!) 
 [server1]$ cat offsite.pub >> ./ssh/authorized_keys

На следующем шаге мы примем дополнительные меры безопасности. Сначаламы изменим права доступа к .ssh таким образом, чтобы доступ к данномукаталогу на чтение, запись и выполнение имел только его владелец. Затеммы убедимся, что доступ к файлу authorized_keys имеет только еговладелец. И наконец, мы удалим за ненадобностью ранее загруженный файлоткрытого ключа offsite.pub. Очень важно правильно назначить правадоступа, поскольку сервер OpenSSH может отказать в использованииключей, для файлов которых заданы небезопасные права доступа.

Листинг 6. Изменение прав доступа командой chmod

 [server1]$ chmod 700 .ssh 
 [server1]$ chmod 600 ./ssh/authorized_keys 
 [server1]$ rm offsite.pub 
 [server1]$ exit

После выполнения этого процесса на сервере 2 мы перейдем на сервервнешнего хранилища для проверки работы нового способа доступа,основанного на парольной фразе. Сделать это можно, выполнив следующуюкоманду на сервере внешнего хранилища:

[offsite]$ ssh -v accountname@server1.com

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

Автоматизация доступа к компьютеру с помощью ssh-агента

ssh-агент играет роль шлюза, по требованию предоставляющего безопасныйдоступ к ключам. После запуска ssh-агент работает в фоновом режиме иможет использоваться такими программами пакета OpenSSH как, например,ssh или scp. С его помощью программа ssh может использовать заранеерасшифрованный ключ вместо того, чтобы запрашивать парольную фразу прикаждой необходимости.

Давайте взглянем на программу ssh-agent поближе. Ssh-agent выводит команды:

Листинг 7. ssh-agent в действии

 [offsite]$ ssh-agent 
 SSH_AUTH_SOCK=/tmp/ssh-XX1O24LS/agent.14179; export SSH_AUTH_SOCK;
 SSH_AGENT_PID=14180; export SSH_AGENT_PID; 
 echo Agent pid 14180;

Мы можем указать оболочке выполнять команды, выводимые программой ssh-agent, с помощью встроенной команды eval:

[offsite]$ eval `ssh-agent` Agent pid 14198

Команда evalвычисляет (выполняет) команды, генерируемые программой ssh-agent.Убедитесь, что используются именно обратные (`), а не одинарныекавычки! Команда eval `ssh-agent` возвращает идентификатор процесса агента. Незаметно для нас были экспортированы переменные оболочки SSH_AUTH_SOCK и SSH_AGENT_PID. Их значения можно просмотреть путем вывода в консоль следующей командой:

[offsite]$ echo $SSH_AUTH_SOCK /tmp/ssh-XX7bhIwq/agent.14197

Переменная $SSH_AUTH_SOCK(сокращение от SSH Authentication Socket) содержит путь к локальномусокету, предназначенному для связи приложений с программой ssh-agent.Чтобы убедиться в том, что переменные SSH_AUTH_SOCK и SSH_AGENT_PID всегда заданы, добавьте команду eval `ssh-agent` в файл ~/.bash_profile.

После этого ssh-agent становится фоновым процессом, увидеть который можно с помощью команд top и ps.

Теперь мы можем организовать с его помощью совместный доступ кпарольной фразе. Для того, чтобы это сделать, нам потребуется программаssh-add, добавляющая (отправляющая) парольную фразу программеssh-agent.

Листинг 8. Использование ssh-add для входа на сервер без лишних трудностей

 [offsite]$ ssh-add 
 Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase) 
 Identity added: /home/accountname/.ssh/id_dsa 
 (/home/accountname/.ssh/id_dsa)

Теперь при получении доступа к server1 парольная фраза запрашиваться не будет:

[offsite]$ ssh accountname@server1.com [server1]$ exit

Если приведенный пример кажется вам неубедительным, попробуйте выгрузить (kill -9)процесс ssh-agent и повторно подключиться к server1. В этом случае вызаметите, что server1 запросит парольную фразу секретного ключа,хранящегося в файле id_dsa, который находится в каталоге .ssh.

[offsite]$ kill -9 $SSH_AGENT_PID [offsite]$ ssh accountname@server1.com Enter passphrase for key /home/accountname/.ssh/id_dsa:

Упрощенный доступ к ключам с помощью скрипта keychain

К данному моменту мы узнали, как работают некоторые программы пакетаOpenSSH (ssh, scp, ssh-agent и ssh-add), а также создали и установилисекретный и открытый ключи для того, чтобы обеспечить безопасныйавтоматический процесс входа на сервер. Вы, вероятно, уже поняли, чтобольшую часть работы по настройке требуется выполнить только единожды.Например, процесс создания и установки ключей, а также настройказапуска ssh-agent из .bash_profile выполняются только один раз длякаждого сервера. Это хорошо.

Плохо то, чтопрограмма ssh-add должна запускаться каждый раз, когда мы входим насервер внешнего хранилища и, помимо этого, в том, что обеспечениесовместимости программы ssh-agent с планировщиком с, которыйпотребуется нам для организации резервного копирования, требуетдополнительных усилий. Причина неспособности cron взаимодействовать сssh-agent заключается в том, что задачи cron выполняются как дочерниепроцессы планировщика и поэтому не получают копию переменной $SSH_AUTH_SOCK.

К счастью, данная проблема имеет решение, позволяющее не только снятьограничения, связанные с использованием ssh-agent и ssh-add, но ииспользовать cron для автоматизации всех видов задач, требующихбезопасного беспарольного доступа к удаленным машинам. В своем цикле OpenSSH key management,состоящем из трех статей, опубликованных developerWorks в 2001 году,Дэниел Роббинс (Daniel Robbins) представил скрипт keychain,представляющий собой интерфейс к программам ssh-agent и ssh-add,облегчающий процесс беспарольного доступа. Со временем был сделан рядулучшений данного скрипта, который теперь поддерживается АрономГриффисом (Aron Griffis). Последний выпуск, датированный 17 июня 2004г., имеет номер 2.3.2-1.

Текст скрипта keychainслишком велик для того, чтобы его можно было привести в данной статье,поскольку он, как и любой качественно написанный скрипт, включаетбольшое количество проверок возникновения ошибок, подробнуюдокументацию и внушительный объем кроссплатформенного кода. Несмотря наобширные возможности, скрипт keychain можно быстро загрузить сweb-сайта проекта (http://www.gentoo.org/proj/en/keychain/index.xml).

Работать со скриптом, после того как вы его загрузите и установите,очень просто. Просто зайдите на каждый из серверов и добавьте следующиедве строки в конец файлов .bash_profile:

keychain id_dsa . ~/.keychain/$HOSTNAME-sh

Когда вы зайдете на серверы в следующий раз, keychain запроситпарольную фразу. При последующих входах, однако, ввод парольной фразыне будет запрашиваться до момента перезагрузки сервера. И, что самоеглавное, задачи cron смогут осуществлять безопасный доступ к удаленныммашинам без ввода пароля. Теперь наше решение совмещает преимуществаповышенной безопасности и простоты использования.

Листинг 9. Инициализация keychain на каждом сервере

 KeyChain 2.3.2; http://www.gentoo.org/projects/keychain
 Copyright 2002-2004 Gentoo Technologies, Inc.; Distributed under the GPL
 * Initializing /home/accountname/.keychain/localhost.localdomain-sh 
 file... 
 * Initializing /home/accountname/.keychain/localhost.localdomain-csh 
 file... 
 * Starting ssh-agent 
 * Adding 1 key(s)... 
 Enter passphrase for /home/accountname/.ssh/id_dsa: (enter passphrase)

Автоматизация процесса резервного копирования

Нашей следующей задачей является написание скриптов, выполняющихоперации, необходимые для резервного копирования. Целью работы данныхскриптов будет создание полной резервной копии баз данных, находящихсяна серверах server1 и server2. На каждом из серверов в рассматриваемомпримере установлена СУБД MySQL. Соответственно для экспорта несколькихтаблиц в виде SQL-скрипта мы будем использовать утилиту mysqldump,работающую в командной строке.

Листинг 10. Скрипт dbbackup.sh для сервера 1

 #!/bin/sh
 # переходим в каталог backup_agent, в котором хранятся файлы данных.
 cd /home/backup_agent

 # экспортируем таблицы баз данных с помощью утилиты mysqldump
 mysqldump -u sitedb -pG0oDP@sswrd --add-drop-table sitedb --
 tables tbl_ccode tbl_machine tbl_session tbl_stats > userdb.sql

 # архивируем и сжимаем файлы tar czf userdb.tgz userdb.sql

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

[server1]:$ chmod +x dbbackup.sh

Разместив копии файла dbbackup.sh на серверах 1 и 2, мы возвращаемся насервер внешнего хранилища, где создаем скрипт, выполняющий их передзапуском процесса удаленного копирования сжатых архивов (.tgz).

Листинг 11. Скрипт backup_remote_servers.sh для размещения на сервере внешнего хранилища

  #!/bin/sh
 # используем ssh для удаленного выполнения скрипта dbbackup.sh на сервере 1
 /usr/bin/ssh backup_agent@server1.com /home/backup_agent/dbbackup.sh

 # используем scp для безопасного копирования созданного архивного файла userdb.tgz 
 # с сервера 1. Обратите внимание на использование команды date
 для формирования временной отметки 
 # при размещении файла на сервере внешнего хранилища. 
 /usr/bin/scp backup_agent@server1.com:/home/backup_agent/userdb.tgz /
 home/backups/userdb-$(date +%Y%m%d-%H%M%S).tgz

 # выполняем скрипт dbbackup.sh на сервере 2 
 /usr/bin/ssh backup_agent@server2.com 
 /home/backup_agent/dbbackup.sh
 
 # используем scp для копирования transdb.tgz на сервер внешнего хранилища. 
 /usr/bin/scp backup_agent@server2.com:/home/backup_agent/transdb.tgz /
 home/backups/transdb-$(date +%Y%m%d-%H%M%S).tgz

Скрипт backup_remote_servers.sh использует ssh для удаленноговыполнения скриптов на серверах. Поскольку доступ, организованный нами,не требует ввода пароля, программа ssh может удаленно выполнять командына серверах 1 и 2 с сервера внешнего хранилища. Благодаря keychainпроцесс аутентификации происходит полностью автоматически.

Планирование задач

Наша следующая и последняя задача заключается в планировании выполненияскрипта backup_remote_servers.sh на сервере внешнего хранилища. Дляэтого мы добавим в конфигурационный файл планировщика cron две новыезаписи, согласно которым скрипт резервного копирования будетзапускаться дважды в день – в 3:34 и в 20:34. Чтобы добавить записи,запустите на сервере внешнего хранилища программу crontab с параметром -e.

[offsite]:$ crontab -e

Программа crontab запустит используемый по умолчанию текстовый редактор, указанный в переменных среды VISUAL или EDITOR. Теперь введите две новые записи, после чего сохраните и закройте файл.

Листинг 12. Записи crontab на сервере внешнего хранилища

  34 3 * * * /home/backups/remote_db_backup.sh 
 34 20 * * * /home/backups/remote_db_backup.sh

Запись файла crontab состоит из двух основных частей: спецификациивремени выполнения и команды, подлежащей выполнению. Спецификациявремени выполнения включает следующие поля:

Листинг 13. Формат записи crontab

  +---- минута 
  ->  +----- час 
  ->   ->  +------ день 
  ->   ->   ->  +------ месяц 
  ->   ->   ->   ->  +---- день недели 
  ->   ->   ->   ->   ->  +-- команда, подлежащая выполнению 
  ->   ->   ->   ->   ->   ->  
 34 3 * * * /home/backups/remote_db_backup.sh

Верификация резервных копий

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

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

Дополнительные меры обеспечения информационной безопасности

Для повышения уровня информационной безопасности можно установить инастроить на каждом сервере систему обнаружения вторжений (IntrusionDetection System, IDS), например, Snort. Система обнаружения вторженийпредназначена для оповещения о попытках взлома системы, происходящих вданный момент или имевших место недавно. Наличие такой системы позволитнаращивать уровень информационной безопасности за счет применения такихтехнологий как цифровая подпись и шифрование резервных копий.

Архивные файлы можно защитить с помощью распространенных инструментов соткрытым исходным кодом, например GNU Privacy Guard (GnuPG), OpenSSL иncrypt, однако, применять их без дополнительного уровня защиты,предоставляемого системой обнаружения вторжений, не рекомендуется.

Заключение

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