Историки
будущего наверняка проклянут когда-нибудь нашу эпоху. Поголовный
переход на магнитные носители информации будут сравнивать никак не
менее, чем с сожжением Александрийской библиотеки, - разве что на
уровне бытовых, неофициальных документов. Если печатные (и записанные
на оптические диски) книги, государственные архивы и прочие "серьёзные"
тексты имеют немалые шансы достичь наших отдалённых потомков хотя бы в
относительной целости, то личной перепиской раскопки наших поселений
вряд ли будут богаты. А ведь только из личной переписки да дневниковых
записей - из текстов, не предназначенных для совсем уж чужих ушей и
глаз, - настоящий историк и может экстрагировать подлинный аромат
эпохи. Начиная от глиняных табличек древнего Шумера (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/,
будет исполняться ежедневно, в один час ночи по местному
(компьютерному) времени. Вот теперь у вас есть собственная система
инкрементного резервирования файлов. Чем бы заняться дальше? Следите за
нашими выпусками!
|
|
