Crazy Rebel: викификация, оформление, иллюстрация

2009-10-21T08:13:12Z

викификация, оформление, иллюстрация

Новая страница

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

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

Диски сейчас достаточно надежны, и легко поддаться иллюзии, что хранимые на них данные вечны. Чтобы открыть нам глаза на их эфемерность, нужна катастрофа. Есть такая шутка, что в мире существует два типа системных администраторов – те, кто
регулярно делают резервные копии данных и те, кто хотел их сделать.
За последние десять лет лично у меня было два сбоя жесткого диска. Последний случай был с нашим 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:Резервирование он-лайн|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 .

<center>[[Изображение:LXF107_47_1.jpg]]</center>
: Двухуровневая и многоуровневая схемы резервного копирования предоставляют компромисс между размером резервных копий и сложностью процесса полного восстановления.

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

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

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

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

LXF107:DrVraun3 - История изменений

Crazy Rebel: викификация, оформление, иллюстрация