LXF105:Резервирование он-лайн

Материал из Linuxformat.

Удаленное резервирование Пусть рухнет все вокруг: ваши данные все равно уцелеют

Резервирование: страховка данных

Для повышения надежности хранения данных не обойтись без резервирования на стороне: оно спасет даже самых рассеянных. Джульетта Кемп все объяснит.

Локальные средства резервирования – например, внешние диски или даже ленточные устройства – это хорошо и прекрасно в своей области. Я даже рискну сказать: они обязательны, если вы действительно заботитесь о своих данных. Кто уже терялданные, знает, что я права. Кто не терял – пожалуйста, поверьте мне: лучше не искать неприятностей на свою, э-э-э, голову!

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

Мы рассмотрим два способа резервирования на стороне. Первый – при помощи Rsync – полезен, если у вас есть консольный доступ к другой, удаленной машине; второй использует для хранения сервис Google Gmail. Оба основаны на сети, а значит, имеют некоторые ограничения по размеру, отчасти зависящие от скорости вашего соединения. В конце урока мы обсудим возможности, существующие для больших объемов данных.

Rsync

При наличии доступа ко внешней консольной учетной записи (полученного в рамках пакета хостинга или, возможно, за дополнительную плату), пригодится старый инструмент резервирования Unix, rsync.

Вот стандартная команда rsync:

rsync /каталог/источник /каталог/назначение

Она просматривает /каталог/источник и сравнивает его с /каталог/назначения. Если все файлы в исходном каталоге новые или обновленные, rsync копирует их в каталог назначения. То есть при первом запуске для некого каталога, он скопирует все его содержимое, и на это потребуется время. Во второй и последующие разы скопируются только изменившиеся файлы, и все будет намного быстрее. Это сберегает и время, и (при передаче во внешний мир) сетевой трафик.

Команда, приведенная выше, лишь синхронизирует один локальный каталог с другим локальным каталогом, действуя, в итоге, как версия славного cp. Для наших целей важно то, что /каталог/назначения в действительности может располагаться на другом компьютере: тогда он принимает форму имя_машины.пример.com:/каталог/назначения. И наоборот, можно копировать из исходного каталога на удаленной машине в локально расположенный каталог, что полезно при восстановлении данных.

Rsync предусматривает множество опций. Те, что вы, вероятно, захотите использовать, такие: -avuz. По очереди опишем их: -v устанавливает режим подробного вывода, чтобы вы понимали, что происходит; -a – опция архивирования, учитывающая структуру каталогов, а также сохраняющая владельца, права доступа, временные отметки и так далее; -u настраивает опции обновления, чтобы не портить файлы, которые в каталоге назначения новее, нежели в источнике; а -z сжимает во время передачи, немного ускоряя процесс.

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

Например, если ваша учетная запись доступна по адресу offsite.example.com и вы настроили для резервирования каталог /home/user/backup, можно создать резервную копию каталога /test так:

rsync -avuz /test user@offsite.example.com:/home/user/backup

Вам потребуется rsyncd, запущенный на удаленной машине. У владельцев коммерческой учетной записи, вероятно, он есть; если нет, поговорите с сисадмином. Если удаленная машина принадлежит вам, установите соответствующий пакет для своего дистрибутива. В Debian вам также потребуется отредактировать /etc/default/rsync, установив RSYNC_ENABLE в true, а затем выполнить /etc/init.d/rsync start.

У вас запросят ваш SSH-пароль – попозже мы рассмотрим, как этого избежать; затем rsync объявит, что создает список файлов. Это означает, что он выясняет, какие файлы необходимо копировать. В данном случае нужно копировать все, поскольку это первое резервное копирование. Потом начнется перенос данных – а поскольку мы использовали опцию -v, rsync сообщит нам о каждом файле. В итоге ваши зарезервированные файлы окажутся в /home/user/backup/test на offsite.example.com.

На данном этапе стоит подумать, каким образом rsync работает с каталогами. А работает он по-разному, в зависимости от того, есть ли в конце каталога источника слэш или нет. В простом примере

rsync /test/one /backup

все файлы передаются из /test/one в /backup/one. Другими словами, копируется весь каталог (и его содержимое) с именем. Следующий код:

rsync /test/one/ /backup

(отметьте завершающий слэш в каталоге источнике) перенесет все файлы из /test/one в /backup, то есть скопируется только содержимое, но не сам каталог. Скорее всего, вам подойдет первая версия: она както опрятнее.

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

SSH без пароля

Итак, rsync резво копирует файлы на вашу удаленную машину, но пока что требует SSH-пароль – для автоматизации это ни к чему! Чтобы обойтись без него, понадобится – угадайте! – вот именно, настроить SSH-аутентификацию без пароля.

Прежде всего, необходимо создать себе закрытый ключ. На вашей домашней машине, откройте окно терминала и введите

ssh-keygen -t rsa -f ~/.ssh/rsync

чтобы сгенерировать RSA-ключ (можно сгенерировать ключ и другого типа – за деталями обратитесь к man-страницам), и сохраните его в /home/ser/.ssh/rsync. Будет выдан запрос на парольную фразу – просто нажмите Enter, задав пустой пароль. Как только это будет сделано, у вас должны появиться файлы /home/user/.ssh/rsync и /home/user/.ssh/rsync.pub.

С обычным ключом и паролем вам было бы надо теперь добавить содержимое /home/user/.ssh/rsync.pub в файл /home/user/.ssh/authorized_keys2 на offsite.example.com, и все. Однако в данном случае это опасно: ведь пароля у ключа нет, и каждый, кто имеет доступ к вашей домашней машине, сможет добраться до offsite.example.com и сделать все, что захочет, с вашими файлами прямо там или в любом другом месте, к которому вы имеете доступ – какая уж тут безопасность!

Для снижения такого риска можно отредактировать файл authorized_keys2 на offsite.example.com, ограничив ваш ключ так, чтобы с ним можно было выполнять только вашу команду резервного копирования. Скопируйте /home/user/.ssh/rsync.pub в tmpfile и отредактируйте tmpfile так, чтобы его единственная строка (на вид – большой блок, забитый случайными символами; но это и есть открытый ключ) в начале имела следующее:

command=”rsync -avuz -e “ssh -i /home/user/.ssh/rsync” /test user@offsite.example.com:/home/userbackup”,
no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Теперь добавьте содержимое tmpfile в /home/user/.ssh/authorized_keys2 на offsite.example.com (вырежьте и вставьте, или используйте cat, если хотите). Убедитесь, что все это – одна строка.

Команде rsync нужно знать, где искать ваш зарытый ключ, так что выполните

rsync -avuz -e “ssh -i /home/user/.ssh/rsync” /test user@offsite.example.com:/home/user/backup

Это указание на используемый SSH-ключ. Данная строка должна сочетаться с командой, которую вы занесли в файл authorized_keys2 выше.

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

Автоматизация с cron

Горькая, но неопровержимая истина в том, что при необходимости помнить о резервировании оно просто не будет выполняться достаточно часто. Так что последний шаг – автоматизация ее запуска. Наберите crontab -e и добавьте следующую строку в ваш файл crontab:

5 0 * * * rsync -auz /test user@offsite.example.com:/home/user/backup

Заметьте, что опции -v больше нет – вам не нужен длинный вывод от Cron. Понятно, что вместо /test вам следует вставить имя своего каталога. Не забудьте также изменить файл authorized_keys2 на offsite.example.com! Он должен соответствовать запускаемой вами команде. Число в начале записи crontab означает, что задача будет запускаться ежесуточно пять минут первого ночи (за деталями обратитесь к man-страницам crontab). Готово – ваш процесс резервирования теперь будет запускаться автоматически каждую ночь.

Gmail

Gmail бесплатно предоставляет уже 5 ГБ пространства, и это количество планируется увеличивать (а если вам этого мало, можете заплатить за учетную запись с большими ресурсами) – чем не решение для удаленного резервирования файлов? Можно настроить скрипт Perl на отсылку по электронной почте определенного набора файлов на вашу учетную запись Gmail, а затем настроить его автоматическое выполнение при помощи Cron каждую ночь.

Детальное описание программирования на Perl выходит за рамки нашего урока, но скрипт должен быть довольно прост. Для него вам понадобятся установленные модули Net::SMTP, File::Find, Mime::Lite, Archive::Tar и IO::Zlib. В Debian первые два из них устанавливаются по умолчанию, как часть стандартного Perl; остальные доступны в виде libmime-lite-perl, libarchive-tar-perl и libio-zlib-perl.

Если вы не нашли модули в своем дистрибутиве, можете установить их со CPAN, используя строку

perl -MCPAN -e “install Net::SMTP”

(подставьте имена своих модулей вместо Net::SMTP).

А вот и сам скрипт:

#!/usr/bin/perl -w
 use strict;
 use Archive::Tar;
 use File::Find;
 use MIME::Lite;
 use Net::SMTP;
 sub sendmail();
 sub wanted();
 my $email        = ‘my.
 name@gmail.com’;
 
 my $email       = ‘my.
 name@gmail.com’;
 my $smtpserver = “smtp.example.com”;
 my @archive_list;
 my $backup_dir = “/home/jkemp/personal/”;
 my $tarfile = “/home/jkemp/gmailtar.tgz”;
 find ( \&wanted, $backupdir );
 Archive::Tar->create_archive($tarfile, “1”, @archive_list);
 sendmail();
 sub sendmail() {
 my $msg = MIME::Lite->new(To => $email,
               Subject => “Backup email”,
               Type => “multipart/mixed”);
 $msg->attach(Type => “application/gzip”,
         Path => $tarfile,
         Filename => “backup.tgz”);
 $msg->send(‘smtp’, $smtpserver);
  }

Помните, что перед его запуском вам необходимо будет изменить права доступа, чтобы он мог запускаться от имени пользователя (chmod u+x gmail.pl).

Perl-компот

Итак, давайте просмотрим скрипт. Флаг -w в первой строке означает, что Perl предупредит вас, если вы ляпнете что-то не то – то есть опечатку или заскок. Следующая строка, use strict – еще одна мера для перехвата ошибок: она заставляет вас описывать все переменные до их использования. Рекомендую всегда использовать обе эти строки в ваших скриптах Perl. Труд невелик, зато сберегает много времени при отладке.

Команда find (из File::Find) обращается к указанному вами каталогу (здесь это /home/jkemp/personal/). Используйте небольшие каталоги – как мы увидим далее, этот метод имеет ограничения на размер. Команда find вызывает подпрограмму wanted, объявленную в начале скрипта и определенную позднее [в листинге ее нет, – прим.ред.]. Подпрограмма проверяет, что обрабатываемое имя действительно соответствует файлу [например, вызовом -f $_[0], – прим. ред.], и если так, то добавляет полное имя этого файла в массив файлов для архивирования @archive_list.

Строка, начинающаяся с Archive::Tar, выполняет всю тяжелую работу. Она создает tar-архив c именем, определяемым переменной $tarfile, и сжимает (вот откуда взялась цифра 1 – «true» означает сжи- мать, «false» – не сжимать) в него файлы из @archive_list.

Затем скрипт отправляет электронное письмо. (Я выделила это в процедуру, чтобы при тестировании можно было легко отделить строку отсылки письма, когда вы проверяете, что ваш архив содержит все, что нужно.) Код электронного письма вполне понятен. Создается новое MIME-сообщение, к нему подцепляется gzip-ованный файл резервной копии, и сообщение отсылается. Вам понадобится имя вашего SMTP-сервера – спросите у провайдера, если не уверены, или гляньте настройки вашей почтовой программы.

Чтобы протестировать, все ли работает хорошо, закомментируйте строку sendmail(), добавив символ решетки (#) в начало, и сохраните программу. Далее запустите ее (/путь/к/gmail.pl) и проверьте местоположение вашего файла gmailtar.tgz. Если он там есть, перенесите его в пустый тестовый каталог и распакуйте (tar -zxf gmailtar.tgz). Все файлы на месте? Прекрасно. Теперь раскомментируйте строку Sendmail, сохраните и запустите программу снова. Проверьте учетную запись Gmail – у вас должно быть новое сообщение с прикрепленным gzip-архивом.

Этот скрипт создает tar-архив и оставляет его на вашем компьютере. Для его удаления добавьте строку

unlink $tarfile;

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

Третий вариант

Основное неудобство работы с Gmail в том, что объем данных, которые можно отослать таким способом, ограничен. Необъятные электронные письма – проблема, способная вызвать отказ сети, а некоторые сервера вообще откажутся принимать их, так что метод действительно полезен для небольшого числа мелких файлов. Текстовые файлы обычно невелики, так что смело шлите самому себе по почте черновик своей новой супер-повести каждую ночь. А вот для резервирования фотографий или музыки этот вариант не подходит. Сервер web-почты, очевидно, может быть любым; мы взяли Gmail просто потому, что он предлагает больше всех места. Оба автоматизированных варианта с использованием сети, описанные здесь, честно говоря, весьма ограниченные решения для задачи резервирования на стороне. Основная проблема в размере данных: пересылка данных по сети занимает много времени, и чем больше данных, тем больше и времени (не говоря уж о деньгах, для большинства домашних тарифных планов). Ни один из этих методов на самом деле не подходит в качестве удаленного резервирования, скажем, вашей фонотеки или фотоальбома. Они больше для таких файлов, как текстовые и других важных, но небольших документов.

Одна из альтернатив – использование внешнего диска для снижения начальных расходов. Закачайте вашу музыку или фото на внешний диск дома, прихватите его с собой к удаленной машине (может быть, в вашем офисе, если вы сделали копию накануне вечером, хотя на это уж лучше получить «добро» у работодателя!) и выгрузить уже на нее. После этого, любые обновления будут меньше, и могут выполняться при помощи rsync.

Или заведите два диска: один дома, один на работе, и меняйте их раз в неделю. Подключаете диск дома и настраиваете rsync использовать Cron для локального запуска каждую ночь, чтобы сделать резервную копию на внешнем диске. В понедельник переносите этот диск к удаленной машине – то есть на работу – и оставляете его на столе. Берете ваш следующий диск домой и подключаете его вечером. Повторяйте переключение каждую неделю. Ваша удаленная резервная копия будет недельной давности, но это все-таки лучше, чем ничего. Конечно же, здесь есть не автоматизированные элементы, раз уж надо помнить о смене дисков!

Идем дальше

Как обсуждалось выше, вы все еще ограничены в смысле возможности хранения старых данных. Если вам позарез нужна длительная история резервирования или хранение больших файлов – вероятно, стоит присмотреться к специальному решению для резервирования, типа Bacula (http://www.bacula.org), или к оплачиваемому хостингу.

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

CPAN

CPAN – это огромная коллекция бесплатных модулей Perl, а точнее, инструментариев Perl для многократного использования. На нашем уроке описан безболезненный метод установки. Если вы регулярно пишете на Perl, вам стоит здесь порыться. Качество неоднородное, потому что внести вклад в CPAN может любой, но имеются несколько хороших образчиков, а документация может быть весьма полезна. А главное, благодаря ей вам не придется изобретать велосипед. Для определения значимости модулей CPAN, полезно проверять очки ‘kwalitee’ на странице тестирования сервиса CPAN (http://cpants.perl.org/kwalitee.html); просмотрите рекомендуемые модули CPAN на сайте Perl Foundation (http://www.perlfoundation.org/perl5/index.cgi?recommended_cpan_modules) и проверьте рейтинги CPAN (http://cpanratings.perl.org).

Anacron

Если ваш компьютер не включен постоянно – например, если это ноутбук – вы можете использовать Anacron вместо Cron.

В Cron вы настраиваете задание на определенное время и дату. Если в это время машина выключена, то задание просто не выполняется (пока вновь не наступит назначенное время). В Anacron вы назначаете запуск задания через определенные интервалы – например, ежедневно, еженедельно или ежемесячно. Anacron будет стараться как можно точнее держаться этого расписания, когда машина включена. Так, если задание предполагается запускать ежедневно, и при включении компьютера демон Anacron обнаружит, что оно не выполнялось за последние 24 часа, задание будет тут же запущено.

Правда, Anacron умеет мерить интервалы только в днях – в отличие от Cron, способного заускать задание хоть по минутам. Для нас это не проблема, коли мы решили резервироваться только раз в день. Еще один момент: Anacron должен настраиваться из-под root (а Cron – не обязательно). Но ведь на своей-то машине у вас всяко есть root-права!

Измените файл /etc/anacrontab, из под root, добавив строку:

 1 5 backup rsync -auz -e “ssh -i /home/user/.ssh/rsync” /test user@offsite.example.com:/home/user/backup

Эта строка будет запускать указанную команду rsync каждый день (первый параметр), с задержкой в 5 минут (второй параметр), и определит журнал работ как «backup» (третий параметр).

Subversion

Преимущество Gmail-метода в том, что при этом хранится несколько версий ваших файлов. Каждое письмо – это отдельная копия, и оно хранится, пока вы не удалите его (или не кончится место). С rsync, файлы перезаписываются, но не удаляются. Для удаления в пункте назначения файлов, отсутствующих в источнике, предусмотрен флаг --delete. Проблема с перезаписью файлов rsync в том, что если вы допустите ошибку и не заметите этого до выполнения резервирования, то будет уже поздно. Старая версия исчезнет, и единственная версия, которая вам останется – это текущая.

Избежать подобных бед можно с помощью системы управления версиями, типа Subversion: она хранит все изменения, сделанные с вашими файлами, и если вы что-то испортите, нужно будет всего лишь вернуться к предыдущей версии. Используйте rsync для резервирования вашего репозитория (вашей базы данных управления версиями), и все будет хорошо.

Не нравится? Есть и другие варианты. Одна из возможностей – настроить на вашей удаленной машине задание Cron, выполняемое непосредственно перед плановым запуском rsync: пусть скопирует вашу старую резервную копию каталога в другое место. Эту работу может выполнить такая строка в вашем Crontab:

5 23 * * * cp -rf /home/user/backup /home/user/backup2

Она запускается ежедневно в 23:05. Сохранится только одна дополнительная копия данных, за предыдущий день, но этого может быть для вас достаточно. Если написать более сложный скрипт, чтоб сохранял копии других дней, за это придется платить дисковой памятью. Каждый добавленный день займет еще один такой же участок пространства на диске, как и предыдущий – аппетиты системы контроля версий могут оказаться куда скромнее.