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

Содержание 1 Назад, к основам 1.1 Живое ископаемое 1.2 Резервное копирование с tar 1.3 6 постулатов резервирования 1.4 Сохраним на века

Назад, к основам

Первое правило системного администратора гласит «никому не говори о системном администрировании». Второе – «резервируйте как маньяки».

Диски сейчас достаточно надежны, и легко поддаться иллюзии, что хранимые на них данные вечны. Чтобы открыть нам глаза на их эфемерность, нужна катастрофа. Есть такая шутка, что в мире существует два типа системных администраторов – те, кто регулярно делают резервные копии данных и те, кто хотел их сделать. За последние десять лет лично у меня было два сбоя жесткого диска. Последний случай был с нашим Sky HD, и он, наверное, не в счет. Второй – с ноутбуком. Но я слышал и о других, включая незабываемую историю, когда ребенок решил отключить папин USB-диск и спустил его в унитаз. Здорово.

За годы я перепробовал многие способы резервного копирования. В своей прошлой жизни (до Linux), я пользовался двумя программами: dump и restore. Мы записывали дамп на полудюймовую магнитную ленту 800bpi (бит на дюйм) – это, наверное, было где-то в 1977. Важно отметить, что dump и restore работали с инкрементными резервными копиями. Мы начинали с дампа «уровня 0», в котором было все. На следующий день делался дамп «уровня 1», который содержал лишь изменения по сравнению с предыдущим уровнем 0, и так далее. Инкрементальное резервное копирование – очень выгодная штука, потому что большинство файлов не изменяется за день и можно сэкономить массу времени, полосу пропускания сети и носители.

Живое ископаемое

Удивительно, но эти две древние программы дожили до сегодняшнего Linux (см. http://dump.sourceforge.net). dump и restore работают не как большинство программ. Они не получают доступ к данным файла через обычные системные вызовы, а открывают устройство раздела диска (например, /dev/sda1) и взаимодействуют со структурой файловой системы напрямую. Отсюда – несколько важных следствий. Во-первых, dump и restore работают только с файловыми системами ext2 и ext3. Они не могут, например, создать резервную копию образов файловых систем Reiser или FAT32. Во-вторых, желательно не пользоваться ими на рабочих файловых системах, во всяком случае, не на критических. Некоторые администраторы перед резервным копированием размонтируют раздел, другие монтируют его в режиме «только для чтения». На интенсивно работающих серверах предприятия ни один из этих подходов применять нельзя.

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

Более популярный, по крайней мере для небольших и средних систем, способ резервного копирования – просто поддерживать с помощью Rsync актуальную копию файловой системы, скажем, на сменном жестком диске, на сервере для резервного копирования в сети или даже – если скорость позволяет – на диске, поставляемом вашим провайдером. Этот подход подробно описан Джульеттой Кемп [Juliet Kemp] в ее превосходном руководстве по Rsync в LXF105, и я не буду здесь его обсуждать.

Есть и третий инструмент, очень популярный для создания и хранения архивов – tar. Например, многие пакеты на сайте SourceForge хранятся в виде tar-архивов. В tar удобно то, что архивы можно сжимать. Навскидку: сжатый tar-архив каталога /lib на моем компьютере имеет размер 90 МБ; сама файловая система занимает 262 МБ. Второй тест – архивирование 400 МБ картинок в JPEG – дает выигрыш менее одного процента, что неудивительно, так как эти файлы сжаты сами по себе.

Резервное копирование с tar

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

Предположим, я начинаю в «первый день» с каталога mypics, в котором есть три файла:

$ ls ~/mypics
caption.jpg storm1.jpg sunset1.jpg

Если создать архив tar, в нем будут все три файла. Это наша резервная копия «уровня 0»:

$ cd ~/mypics
$ tar cvf /backups/mypics.0.tar -g mypics.snar .
./
./caption.jpg
./mypics.snar
./storm1.jpg
./sunset1.jpg

Первый аргумент tar (cvf) – это на самом деле набор из трех опций. c означает «создать архив», v – «подробный» (выводить имена файлов во время их записи в архив), а f – «следующий аргумент будет именем файла-архива». Здесь я предполагаю, что /backups – точка монтирования файловой системы сервера NFS или внешнего диска. Интересен флаг -g. Он велит tar сохранить запись о том, что было архивировано (и когда) в файл снимка mypics.snar. Наконец, вроде бы ничего не значащая точка . в конце команды – это имя каталога, который нужно архивировать, в данном случае – текущая директория.

На второй день я добавил в каталог новый файл baby.jpg. Я создаю другой архив. Он содержит только новый файл и является нашим «уровнем 1»:

$ tar cvf /backups/mypics.1.tar -g mypics.snar .
./
./baby.jpg

На третий день я могу продолжить, создав резервную копию уровня 2 следующим образом:

$ tar cvf /backups/mypics.2.tar -g mypics.snar .

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

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

 $ tar xvf /backups/mypics.0.tar -g /dev/null
 ./
 ./caption.jpg
 ./mypics.snar
 ./storm1.jpg
 ./sunset1.jpg
 $ tar xvf /backups/mypics.1.tar -g /dev/null
./
./baby.jpg
$ tar xvf /backups/mypics.2.tar -g /dev/null
./
./chris1.jpg

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

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

$ cp mypics.snar mypics.snar-2
$ tar cvf /backups/mypics.day2.1.tar -g mypics.snar-2 .

и на третий день делаете то же самое снова:

$ cp mypics.snar mypics.snar-3
$ tar cvf /backups/mypics.day3.1.tar -g mypics.snar-3 .

Двухуровневая и многоуровневая схемы резервного копирования предоставляют компромисс между размером резервных копий и сложностью процесса полного восстановления.

6 постулатов резервирования

1. Самое важное – не выбрать самую последнюю, самую быструю технологию с суперсжатием, а гарантировать, что вы будете его делать, каким-то разумным способом, на последовательной и регулярной основе. Резервное копирование чем-то похоже на уплату страховых взносов: вы надеетесь, что страховой случай никогда не наступит, и появляется соблазн не платить их совсем.
2. Создавать резервные копии файловой системы на том же жестком диске – все равно, что назначать свидание Карле Саркози, т.е. пустая трата времени. Не делайте этого.
3. Если вы сохраняете резервную копию на другой компьютер в сети, помните, что если взломают ваш компьютер, то и до сервера резервных копий тоже могут добраться. (Ничто не убедит вас в сохранности данных сильнее, чем три метра расстояния между локальной сетью и внешним USB-накопителем на полке.)
4. Если резервные копии сохраняются на сменном диске, помечайте его!
5. Храните внешние носители (CD или жесткие диски) в других помещениях. Мне помогают в этом соседи. Конечно, они получают доступ к личным данным, поэтому им нужно доверять (или предполагать, что они не сумеют добраться до данных).
6. Какой бы метод вы ни использовали, убедитесь, что данные на деле можно восстановить. Проведите «учения» – представьте, что несколько файлов утеряны, и восстановите их.

Сохраним на века

Сколько, вы думаете, проживет носитель с резервной копией? Месяц? Год? Десять лет? Век? Ответ на этот вопрос может сильно повлиять на выбор технологии резервного копирования. В восьмидесятых я встречал совершенно безумных администраторов, которые бережно хранили резервные копии своих баз данных на полудюймовой магнитной ленте, хотя у них больше не было компьютера с соответствующей лентопротяжкой. Наверное, то же самое сейчас происходит с дискетами. Исходный код тех важных утилит, который вы бережно записали на восьмидюймовую дискету в 1977 году – сколько человек сможет восстановить их сейчас? И, если вы уже улыбнулись, сколько времени пройдет, прежде чем автор статьи напишет в журнале то же самое «об этих древних CD и DVD» и пошутит про «смешные старые USB-брелки всего на 4 ГБ»?