Знакомство с Linux. Часть 19. Архивные изыскания

Историки будущего наверняка проклянут когда-нибудь нашу эпоху. Поголовный переход на магнитные носители информации будут сравнивать никак не менее, чем с сожжением Александрийской библиотеки, - разве что на уровне бытовых, неофициальных документов. Если печатные (и записанные на оптические диски) книги, государственные архивы и прочие "серьёзные" тексты имеют немалые шансы достичь наших отдалённых потомков хотя бы в относительной целости, то личной перепиской раскопки наших поселений вряд ли будут богаты. А ведь только из личной переписки да дневниковых записей - из текстов, не предназначенных для совсем уж чужих ушей и глаз, - настоящий историк и может экстрагировать подлинный аромат эпохи. Начиная от глиняных табличек древнего Шумера (IV тысячелетие до н. э.) и до самого конца XX века частных писем историки и археологи разыскали немало. Теперь же мы общаемся, в основном, с использованием электронных средств связи - почты, аськи, web-форумов. Куда же уходят наши письма при "осыпании" очередного отработавшего свой срок винчестера?

Впрочем, куда он уходят - вопрос, скорее, философский. С практической же точки зрения важнее, как этот уход предотвратить - если не иметь в виду интересы историков будущего, то уж по крайней мере заботясь о своих. По личному опыту могу сказать, что перечитывать собственные семилетней давности письма, сбережённые в папке "Отправленные" (точнее, sent-mail почтового клиента pine), бывает ого-го как поучительно и полезно. Уж интересно - во всяком случае.

Конечно, у резервного копирования данных (а именно таким методом мы будем двигаться к намеченной цели) есть немало других предназначений, помимо сбережения в целости частной пользовательской переписки. Но раз мы рассматриваем домашнее применение Linux, то почтовые и "асечные" архивы (да ещё, может, save-файлы любимых игрушек) - это, наверное, исчерпывающий перечень той информации, потеря которой может нас по-настоящему огорчить. Можно добавить сюда ещё и конфигурационные файлы важнейших приложений и служб Linux (не забыли ещё про каталог /etc?), вооружившись которыми, несложно переустановить систему после серьёзного сбоя и восстановить её работоспособность в полном объёме. Да, вот ещё важная категория данных, потеря которых представляется совсем нежелательной: исходные файлы (пакеты rpm или tarballs) тех приложений, что вы самостоятельно закачиваете и устанавливаете на своём компьютере. Ели не полениться и завести для этих пакетов особый каталог, то в круговорот архивного копирования есть смысл включить и его. Наиболее педантичные системщики (а на домашнем ПК каждый сам себе системщик, верно?) ведут лог-файл любых изменений, которые производятся в системе, - от банального указания IP-адреса часто посещаемого сервера в /etc/hosts и до подробных инструкций по компилированию и установке какого-нибудь особенно капризного пакета. Вооружившись подобным логом, если он также присутствует в бэкапе (давайте уж употребим это страшноватое, но ёмкое словцо), можно существенно упростить задачу восстановления системы и даже её переустановки: достаточно просто последовательно выполнить все зафиксированные нетривиальные действия с тривиально инсталлированной системой, и на выходе у вас получится в точности та же конфигурация, что была до аварии.

И всё-таки, прежде чем заниматься восстановлением системы после сбоя, надо такой бэкап произвести на свет. Этим и займёмся...

Как уже не раз отмечалось, идеология Linux - многовариантность: одной и той же цели можно достичь различными способами, притом какой из них окажется лучшим, не всегда ясно до непосредственной реализации. Именно так обстоит дело с резервным копированием. Можно организовать его при помощи уже знакомых нам базовых утилит, можно привлечь специализированные, но также стандартные средства, а можно и найти любопытную программу на стороне. Ну, и написать свою собственную, в конце концов, - выход для полностью погружённых в суть вопроса.

Начнём с простых методов. К наипростейшим относится использование утилиты tar, о которой мы к настоящему времени и так уже знаем много хорошего. Действительно, tar по определению предназначена для сборки и упаковки данных, так что пренебрегать её потенциалом при простоте использования было бы попросту неразумно. Вчитавшись повнимательней в руководство (man tar), мы познакомимся с полезнейшей опцией -N, позволяющей создавать архивы из файлов, содержащихся в указанном каталоге и созданных не ранее даты N. Таким образом, наши действия по сохранению жизненно важной информации выстраиваются в такой вот линейный алгоритм:

1. Определить, в каких каталогах находятся важные для нас данные.

2. Создать полный tar-архив указанных каталогов (возможно, применяя сжатие, если имеются проблемы со свободным местом).

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

4. Повторять пункт 3 до тех пор, пока изменения не станут существенными.

5. Создать очередную полную резервную копию.

И так далее... Как видим, сложного тут ничего нет, за исключением пары достаточно очевидных моментов.

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

Второй: дисковое пространство, потребное для хранения копий, должно быть менее уязвимо для внезапных сбоев, чем то устройство, резервирование информации на котором производится. В самом крайнем случае подойдёт другой раздел того же винчестера, с которого производится бэкап, - другой по отношению к тем разделам, данные с которых надо сберечь. То есть, допустим, если мы помещаем в архив каталоги /etc и /home, то целью для создания tar-копии нужно выбрать логически обособленный от них раздел /tmp. Или /var. Или даже предусмотреть особый раздел (скажем, /usr/local/opt) при исходном форматировании HDD.

Нетрудно сделать вывод, что хорошо бы для полноценного резервирования обзавестись отдельным винчестером, - ну, скажем, использовать для этой цели верного жёсткого пластинчатого друга, оставшегося не у дел после недавней установки 120-Гбайтного HDD. Однако этот вариант лучшим назвать трудно, поскольку старый винчестер, как бы надёжно он до сих пор ни работал, всё-таки находится гораздо ближе к концу срока службы, чем новый, - а надёжность резервных копий в каком-то смысле важнее надёжности рабочих оригиналов архивируемой информации. Ставить же на машину два новых "винта", один из которых предназначался бы только для бэкапа, бессмысленно, - тогда уж лучше построить RAID-масив с горячим резервированием, благо он реализуется вообще вне зависимости от устанавливаемой поверх операционной системы.

Сисадминам в крупных организациях хорошо, - они для решения подобных задач используют ленточные накопители. Именно "под ленту" создано одно из популярнейших среди профессионалов средств резервного копирования - утилита dump. Её главное отличие от tar в том, что копированию здесь подвергаются не каталоги, а дисковые разделы целиком. Для восстановления используется утилита restore, входящая с dump в единый комплект. Здесь также имеется возможность создавать многоуровневые архивы: точнее, всего уровней девять, из которых один (нулевой) - полная копия, а остальные представляют собой переплетающиеся ветви добавочного копирования. Углубившись в страницу руководства по dump, можно узнать, как правильно производить глубинный бэкап с применением десяти лент - что позволяет в течение долгого времени не беспокоиться о сохранности своих данных (по крайней мере, всех, - вплоть до вчерашних). Однако, повторюсь, ленточный накопитель - устройство, на домашнего пользователя не ориентированное. Дороговаты они и неуниверсальны: иных применений, помимо резервирования данных, у них нет.

Совсем другое дело - оптические носители: CD-R, RW и в особенности различные варианты записываемых DVD. Если бы не дороговизна последних, им бы вообще не было конкурентов в деле сбережения домашних архивов. CD можно использовать без проблем, за единственным ограничением - 700 Мбайт на сегодняшний день всё-таки не слишком много. Хотя если речь идёт действительно о каталоге /etc и почтовых каталогах в домашней директории, этого объёма на какое-то время должно хватить.


Итак, создание архива. Как водится, обо всём разнообразии аргументов команды dump интересующиеся смогут прочесть на странице руководства man dump, а для практики применим с вами лишь пару опций: -0u, задающую архивацию на нулевом уровне, то есть полностью, и -f - указание имени итогового архивного файла. Последним аргументом пойдёт указание на то, какой раздел подвергнется архивации (dump оперирует с разделами целиком, да). И это всё: в том случае, если копирование создаваемого файла производилось бы на ленточный накопитель, не пришлось бы даже указывать имя "мишени".


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

Созданный dump'ом архив можно записать на CD-RW, используя стандартную связку mkisofs и cdrecord, либо присутствующие в KDE и Gnome графические интерфейсы к ним. Обратная процедура восстановления посредством restore выглядит ничуть не сложнее. Разве что необходимо помнить: прежде всего следует перейти (командой cd) в тот раздел, который восстановлению непосредственно подлежит. Если программой dump проводился "накопительный" бэкап, то сперва при помощи restore восстанавливается его нулевой уровень, а затем, по мере необходимости, последующие.

И всё-таки... Как бы ни была замечательна команда dump, какими бы удобными ни представлялись CD-RW-копии бэкапов, есть у такой организации архивного труда одна неприятная особенность: слишком уж много ручной работы. Нет, правда, очень много. Автоматизировать само создание резервных копий - не сложно. А вот запись на компакт-диск... Нужно же как минимум следить, чтобы в вашем пишущем приводе всегда находился очередной CD-RW - не абы какой, не оставшийся с прошлого бэкапа, а именно строго очередной! В учреждениях за сменой лент в накопителе резервирования следит системный администратор или одна из его правых рук. Но это - его работа. С домашними же данными сложнее: тут каждый сам себе начальство... Что иногда приводит к нежелательным последствиям.

Так что в качестве практического примера организации резервирования предлагаю рассмотреть вот какой. Во-первых, воспользуемся не dump'ом, а tar'ом - просто затем, чтобы не обрекать себя на обязательное архивирование разделов целиком. Во-вторых, в качестве хранилища получаемых архивов пусть выступает один из разделов жёсткого диска компьютера - он всегда под рукой, и нынешние диски, как правило, не умирают в один момент - спасти данные при первых признаках "осыпания" - удастся. И наконец, каждый действительно сам кузнец своего счастья: вы просто будете знать, что в указанное место на винчестере регулярно "сваливается" бэкап ваших текущих данных. И если они для вас действительно важны, не поленитесь "закатать" хоть раз в неделю архивчик на CD-RW.

Итак, приступим. Сам скрипт автоматического резервного копирования с применением tar уже, как и следовало ожидать, давно написан и распространяется свободно - остаётся только немного его модифицировать. А именно, указать нужные значения для переменных COMPUTER, DIRECTORIES, BACKUPDIR и TIMEDIR. Вот он:

#!/bin/sh
# скрипт полного и инкрементного резервного копирования
# создан 12 ноября 2003
# Основан на скрипте Daniel O'Callaghan <danny@freebsd.org>
# Модифицирован Gerhard Mourani <gmourani@videotron.ca>
# Измените значения следующих пяти переменных:
COMPUTER=localhost # имя данного компьютера
DIRECTORIES="/home" # что именно архивируем
BACKUPDIR=/backups # где храним архив
TIMEDIR=/backups/last-full # где хранится время полной резервной копии
TAR=/bin/tar # путь к исполняемому файлу tar
#То, что написано ниже, менять НЕ СЛЕДУЕТ:
PATH=/usr/local/bin:/usr/bin:/bin
DOW=`date +%a` # День недели, например Mon
DOM=`date +%d` # Дата, например 27
DM=`date +%d%b` # Дата и месяц, например 27Sep
# 1-го числа каждого месяца регулярно делаем полную резервную копию.
# Каждое воскресенье делаем полную копию - переписываем копию,
# оставшуюся с последнего воскресенья.
# В остальное время делаем добавочную резервную копию. Каждая добавочная
# резервная копия переписывает добавочную копию от предыдущей недели с
# тем же именем.
#
# если NEWER = "", тогда tar создает резервные копии всех файлов в каталог,
# иначе - только файлов, созданных позже, чем дата в NEWER. NEWER берет
# дату из файла, записываемого каждое воскресенье.
# Ежемесячная полная резервная копия:
if [ $DOM = "01" ]; then
NEWER=""
$TAR $NEWER -cf $BACKUPDIR/$COMPUTER-$DM.tar $DIRECTORIES
fi
# Еженедельная полная резервная копия:
if [ $DOW = "Sun" ]; then
NEWER=""
NOW=`date +%d-%b`
# Обновление даты еженедельной полной резервной копии:
echo $NOW > $TIMEDIR/$COMPUTER-full-date
$TAR $NEWER -cf $BACKUPDIR/$COMPUTER-$DOW.tar $DIRECTORIES
# Создание добавочной резервной копии - переписывание аналогичной с
# последней недели:
else
# Берем дату последней полной резервной копии:
NEWER="--newer `cat $TIMEDIR/$COMPUTER-full-date`"
$TAR $NEWER -cf $BACKUPDIR/$COMPUTER-$DOW.tar $DIRECTORIES
fi

Скрипт лаконичен и вполне функционален, надо заметить. Как он действует? Ровно так, как написано в комментариях. Конструкции команд оболочки, которые в нём применяются, настолько синтаксически прозрачны, что по этому скрипту вполне можно научиться создавать свои собственные. Обратите только внимание на первую строку: её во всех bash-скриптах следует воспроизводить один к одному, поскольку она как раз и обозначает, что всё нижеследующее содержимое файла - исполняемый в оболочке bash (и только в ней!) набор команд.

Как же теперь заставить эту великолепную конструкцию заработать? Очень просто - поставить в известность о ней демона crond, отвечающего за регулярный автоматический запуск служб и пользовательских программ Linux.

Давайте действовать последовательно. Создадим сперва пустой файл для нашего скрипта:

touch /etc/cron.daily/backup.cron

Далее - откроем файл при помощи редактора vi и скопируем в него текст скрипта (строка #!/bin/sh обязательно должна идти первой и начинаться с первой позиции!). После чего создадим файл, содержащий временную метку:

date +%d%b > /backups/last-full/myserver-full-date

(Вместо myserver поставьте то имя, которое вы присвоили переменной COMPUTER в файле скрипта.). Команда date выводит, как нетрудно догадаться, дату, а указанные параметры форматируют её к нормально воспринимаемому человеком виду вроде 12Nov. Проверьте, существуют ли все указанные вами в именах переменных каталоги. Смените права доступа для файла скрипта -

chmod 755 /etc/cron.daily/backup.cron

Теперь он стал исполняемым и, поскольку находится в каталоге /etc/cron.daily/, будет исполняться ежедневно, в один час ночи по местному (компьютерному) времени. Вот теперь у вас есть собственная система инкрементного резервирования файлов. Чем бы заняться дальше? Следите за нашими выпусками!