LXF107:DrVraun3
|
|
|
Содержание |
Назад, к основам
- Первое правило системного администратора гласит «никому не говори о системном администрировании». Второе – «резервируйте как маньяки».
Диски сейчас достаточно надежны, и легко поддаться иллюзии, что хранимые на них данные вечны. Чтобы открыть нам глаза на их эфемерность, нужна катастрофа. Есть такая шутка, что в мире существует два типа системных администраторов – те, кто регулярно делают резервные копии данных и те, кто хотел их сделать. За последние десять лет лично у меня было два сбоя жесткого диска. Последний случай был с нашим 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 постулатов резервирования
- Самое важное – не выбрать самую последнюю, самую быструю технологию с суперсжатием, а гарантировать, что вы будете его делать, каким-то разумным способом, на последовательной и регулярной основе. Резервное копирование чем-то похоже на уплату страховых взносов: вы надеетесь, что страховой случай никогда не наступит, и появляется соблазн не платить их совсем.
- Создавать резервные копии файловой системы на том же жестком диске – все равно, что назначать свидание Карле Саркози, т.е. пустая трата времени. Не делайте этого.
- Если вы сохраняете резервную копию на другой компьютер в сети, помните, что если взломают ваш компьютер, то и до сервера резервных копий тоже могут добраться. (Ничто не убедит вас в сохранности данных сильнее, чем три метра расстояния между локальной сетью и внешним USB-накопителем на полке.)
- Если резервные копии сохраняются на сменном диске, помечайте его!
- Храните внешние носители (CD или жесткие диски) в других помещениях. Мне помогают в этом соседи. Конечно, они получают доступ к личным данным, поэтому им нужно доверять (или предполагать, что они не сумеют добраться до данных).
- Какой бы метод вы ни использовали, убедитесь, что данные на деле можно восстановить. Проведите «учения» – представьте, что несколько файлов утеряны, и восстановите их.
Сохраним на века
Сколько, вы думаете, проживет носитель с резервной копией? Месяц? Год? Десять лет? Век? Ответ на этот вопрос может сильно повлиять на выбор технологии резервного копирования. В восьмидесятых я встречал совершенно безумных администраторов, которые бережно хранили резервные копии своих баз данных на полудюймовой магнитной ленте, хотя у них больше не было компьютера с соответствующей лентопротяжкой. Наверное, то же самое сейчас происходит с дискетами. Исходный код тех важных утилит, который вы бережно записали на восьмидюймовую дискету в 1977 году – сколько человек сможет восстановить их сейчас? И, если вы уже улыбнулись, сколько времени пройдет, прежде чем автор статьи напишет в журнале то же самое «об этих древних CD и DVD» и пошутит про «смешные старые USB-брелки всего на 4 ГБ»?
