Учебное пособие для экзамена LPI 102, тема 111: Задачи администрирования

Страница 6 из 10  Опции документа Обсудить Выскажите мнение об этом учебном пособии Помогите нам улучшить содержание

Резервное копирование данных

Этот раздел охватывает материал по теме 1.111.5 экзамена 102 Администрирование Linux для начинающих (LPIC-1). Рейтинг темы 3.

Из этого раздела вы узнаете, как:

• Планировать стратегию резервного копирования
• Создать дамп сырого устройства в файле или восстановить содержимое сырого устройства из файла
• Осуществить частичное или ручное резервное копирование
• Проверить целостность файлов резервного копирования
• Частично или полностью восстановить файловые системы из резервных копий

Планирование стратегии резервного копирования

Наличие хорошей резервной копии — необходимая часть системного администрирования, но принятие решения о том, что, когда и как должно копироваться, может вызвать затруднения. В сфере бизнеса обычно бывают крайне важны базы данных, такие как заказы клиентов или опись имущества, и часто используются специализированные средства резервного копирования и восстановления данных, описание которых выходит за рамки этого учебного пособия. С другой стороны, некоторые файлы являются временными, и нет необходимости в их резервном копировании. В этом разделе мы фокусируем внимание на системных файлах и пользовательских данных и обсуждаем некоторые принципы, методы и средства резервного копирования таких данных.

Существует три основных метода резервного копирования:

1. Полное резервное копирование — обычно создание резервной копии всей файловой системы, каталога или группы связанных файлов. Создание такой копии занимает длительное время и обычно осуществляется в сочетании с одним из следующих двух методов.
   
   
2. Дифференциальное или кумулятивное резервное копирование — резервное копирование всех данных, которые изменились после создания последней полной резервной копии. Для восстановления требуется полная резервная копия плюс самая последняя дифференциальная резервная копия.
   
   
3. Инкрементальное резервное копирование — резервное копирование только тех данных, которая изменилось после создания последней инкрементальной копии. Для восстановления требуется полная резервная копия плюс все инкрементальные копии (по порядку), созданные после последнего полного резервного копирования.

Что подлежит резервному копированию

Решая, что копировать, следует принять во внимание, насколько меняются данные. Это поможет определить, как часто должны создаваться их резервные копии. Подобным образом, резервные копии наиболее важных данных должны создаваться чаще, чем копии менее важных данных. Вашу операционную систему, вероятно, можно будет относительно легко восстановить, особенно если вы используете общий образ для нескольких систем, хотя важнее было бы создать копии файлов настроек для каждой системы.

Для отдела разработчиков может быть достаточно хранить резервные копии репозиториев, таких как репозитории CVS, в то время как личные песочницы (sandbox'ы) программистов могут быть менее важными. В зависимости от того, насколько важна для вашей деятельности электронная почта, может быть достаточно иметь нечасто создаваемые резервные копии почты или может быть необходимо иметь возможность восстановить почту на самую последнюю возможную дату. У вас может возникнуть желание хранить резервные копии файлов системного cron, но вы не станете волноваться о запланированных задачах отдельных пользователей.

Filesystem Hierarchy Standard предоставляет классификацию данных, которые могут помочь при выборе объектов и методов резервного копирования. Подробнее см. в Учебнике для экзамена LPI 101, Тема 104: Устройства, файловые системы Linux и стандарт Filesystem Hierarchy Standard.

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

Автоматизация резервного копирования

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

В начало

Создание дампов и восстановление содержимого сырых устройств

Один из способов создания полной резервной копии файловой системы — создать образ разделов, на которых она расположена. Сырое устройство, например, /dev/hda1 или /dev/sda2, может быть открыто и прочитано как последовательный файл. Точно так же оно может быть записано с резервной копии как последовательный файл. Это не требует со стороны средства резервного копирования знаний относительно расположения файловой системы, но необходимо, чтобы восстановление было сделано в такое место, которое имеет по крайней мере такой размер, как оригинал. Некоторые средства для управления сырыми устройствами готовы к работе с файловой системой, что означает, что они понимают одну или более файловых систем Linux. Эти утилиты могут создать дамп сырого устройства, но не могут создать дамп неиспользованной части раздела. Они могут требовать или не требовать для восстановления наличия раздела такого же или большего размера. Команда dd — пример утилиты первого типа, а команда dump — пример утилиты второго типа, который характерен для файловых систем типа ext2 и ext3.

Команда dd

Самая простая форма использования команды dd — копирование входного файла в выходной файл, где любой файл может быть сырым устройством. Для резервного копирования сырого устройства, такого как /dev/hda1 или /dev/sda2, входной файл будет сырым устройством. В идеале для уверенности, что в ходе резервного копирования данные не будут изменены, файловая система не должна быть смонтирована на устройстве или смонтирована только для чтения. В листинге 39 показан пример.

                    
[root@lyrebird ~]# dd if=/dev/sda3 of=backup-1
2040255+0 records in
2040255+0 records out
1044610560 bytes (1.0 GB) copied, 49.3103 s, 21.2 MB/s

Параметры if и of определяют входной и выходной файлы соответственно. В этом примере входной файл — сырое устройство dev/sda3, а выходной файл — файл backup-1 в домашнем каталоге пользователя root. Чтобы создать дамп файла для записи его на пленку или на дискету, следует указать что-то типа of=/dev/fd0 или of=/dev/st0.

Обратите внимание, что было скопировано 1,044,610,560 байт данных, и выходной файл имеет очень большой размер, несмотря на то, что фактически используется только около 3% этого конкретного раздела. Вы, наверно, захотите сжать данные, если только вы не используете при копировании на ленту аппаратное сжатие. В листинге 40 показан способ достичь этого, а также вывод команд ls и df, которые показывают размеры файлов и процент использования файловой системы на /dev/sda3.

                    
[root@lyrebird ~]# dd if=/dev/sda3 | gzip > backup-2
2040255+0 records in
2040255+0 records out
1044610560 bytes (1.0 GB) copied, 117.723 s, 8.9 MB/s
[root@lyrebird ~]# ls -l backup-[12]
-rw-r--r-- 1 root root 1044610560 2007-07-08 15:17 backup-1
-rw-r--r-- 1 root root  266932272 2007-07-08 15:56 backup-2
[root@lyrebird ~]# df -h /dev/sda3
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             972M   28M  944M   3% /grubfile

Сжатие при помощи gzip уменьшило размер файла примерно до 20% от его полного размера. Однако неиспользованные блоки могут содержать какие-то данные, поэтому даже сжатая резервная копия может быть значительно больше общего размера содержащихся на разделе данных.

Если разделить размер на количество записей, обработанных dd, вы увидите, что dd записывает данные блоками размером 512 байт. При копировании на сырое выводное устройство, например, ленту, это может серьезно понизить производительность, поэтому dd может читать или записывать данные гораздо более крупными блоками. Укажите опцию obs для изменения размера вывода или опцию ibs для определения размера выводного блока. Также можно определить только bs, чтобы установить одинаковый размер блока для ввода и вывода.

Если для хранения резервной копии необходимо сделать запись на несколько лент или сменных накопителей, копию следует разбить на более мелкие части, например, при помощи утилиты split.

Если необходимо пропустить блоки, например, ярлыки дисков или лент, это можно сделать при помощи dd. Примеры см. в страницах руководства man.

Помимо простого копирования данных, команда dd может преобразовывать данные, например, между ASCII и EBCDIC, между порядками "от старшего к младшему" (big-endian) и "от младшего к старшему" (little-endian) или между записями данных переменной длины и записями данных фиксированной длины. Очевидно, эти преобразования могут быть полезны при копировании реальных файлов, а не сырых устройств. Подробности также см. в страницах руководства man.

Коанда dump

Команда dump может использоваться для полного, дифференциального или инкрементального резервного копирования на системах ext2 или ext3. В листинге 41 показан пример.

                    
[root@lyrebird ~]# dump -0 -f backup-4 -j -u /dev/sda3
  DUMP: Date of this level 0 dump: Sun Jul  8 16:47:47 2007
  DUMP: Dumping /dev/sda3 (/grubfile) to backup-4
  DUMP: Label: GRUB
  DUMP: Writing 10 Kilobyte records
  DUMP: Compressing output at compression level 2 (bzlib)
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 12285 blocks.
  DUMP: Volume 1 started with block 1 at: Sun Jul  8 16:47:48 2007
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Closing backup-4
  DUMP: Volume 1 completed at: Sun Jul  8 16:47:57 2007
  DUMP: Volume 1 took 0:00:09
  DUMP: Volume 1 transfer rate: 819 kB/s
  DUMP: Volume 1 12260kB uncompressed, 7377kB compressed, 1.662:1
  DUMP: 12260 blocks (11.97MB) on 1 volume(s)
  DUMP: finished in 9 seconds, throughput 1362 kBytes/sec
  DUMP: Date of this level 0 dump: Sun Jul  8 16:47:47 2007
  DUMP: Date this dump completed:  Sun Jul  8 16:47:57 2007
  DUMP: Average transfer rate: 819 kB/s
  DUMP: Wrote 12260kB uncompressed, 7377kB compressed, 1.662:1
  DUMP: DUMP IS DONE
[root@lyrebird ~]# ls -l backup-[2-4]
-rw-r--r-- 1 root root 266932272 2007-07-08 15:56 backup-2
-rw-r--r-- 1 root root 266932272 2007-07-08 15:44 backup-3
-rw-r--r-- 1 root root   7554939 2007-07-08 16:47 backup-4

В этом примере-0 определяет уровень дампа, выражающийся целым числом, исторически сложилось, что используется значение от 0 до 9, где 0 обозначает полный дамп. Опция -f определяет выходной файл, который может быть сырым устройством. Укажите -, чтобы направить вывод на стандартный вывод. Опция -j определяет уровень сжатия по умолчанию, равный 2, с использованием сжатия bzlib. Если вы предпочитаете сжатие zlib, используйте опцию -z. Опция -u указывает, что запись информации о дампе, обычно это /etc/dumpdates, должна быть обновлена. Все параметры, стоящие после опций, — файл или список файлов, причем файл также может быть сырым устройством, как в этом примере. Обратите внимание, насколько резервная копия меньше в случае, если программа резервного копирования осведомлена о структуре файловой системы и может не сохранять неиспользуемые блоки устройства.

Если выводом является такое устройство как лента, когда его объем будет полностью использован, команда dump запросит другой том. Также можно предусмотреть несколько имен файлов, разделенных запятыми. Например, если вам нужно, чтобы автоматически был создан дамп, которому требуется две ленты, вы можете вставить ленты в /dev/st0 и /dev/st1, запланировать команду dump, указав обе ленты в качестве вывода, и отправиться домой спать.

Если определить уровень дампа выше 0, будет создан инкрементальный дамп из всех новых файлов и файлов, изменившихся с момента создания последнего дампа уровня меньшего, чем данный. Поэтому дамп уровня 1 будет дифференциальным, даже если одновременно был получен дамп уровня 2 или выше. В листинге 42 показан результат обновления метки времени существующего файла на /dev/sda3 и создания нового файла, а затем сделан дамп уровня 2. После этого создан другой новый файл и сделан дамп уровня 1. Также показана информация из /etc/dumpdates. Для краткости часть вывода второго дампа опущена.

                    
[root@lyrebird ~]# dump -2 -f backup-5 -j -u /dev/sda3
  DUMP: Date of this level 2 dump: Sun Jul  8 16:55:46 2007
  DUMP: Date of last level 0 dump: Sun Jul  8 16:47:47 2007
  DUMP: Dumping /dev/sda3 (/grubfile) to backup-5
  DUMP: Label: GRUB
  DUMP: Writing 10 Kilobyte records
  DUMP: Compressing output at compression level 2 (bzlib)
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 91 blocks.
  DUMP: Volume 1 started with block 1 at: Sun Jul  8 16:55:47 2007
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Closing backup-5
  DUMP: Volume 1 completed at: Sun Jul  8 16:55:47 2007
  DUMP: 90 blocks (0.09MB) on 1 volume(s)
  DUMP: finished in less than a second
  DUMP: Date of this level 2 dump: Sun Jul  8 16:55:46 2007
  DUMP: Date this dump completed:  Sun Jul  8 16:55:47 2007
  DUMP: Average transfer rate: 0 kB/s
  DUMP: Wrote 90kB uncompressed, 15kB compressed, 6.000:1
  DUMP: DUMP IS DONE
[root@lyrebird ~]# echo "This data is even newer" >/grubfile/newerfile
[root@lyrebird ~]# dump -1 -f backup-6 -j -u -A backup-6-toc /dev/sda3
  DUMP: Date of this level 1 dump: Sun Jul  8 17:08:18 2007
  DUMP: Date of last level 0 dump: Sun Jul  8 16:47:47 2007
  DUMP: Dumping /dev/sda3 (/grubfile) to backup-6
   ...
  DUMP: Wrote 100kB uncompressed, 16kB compressed, 6.250:1
  DUMP: Archiving dump to backup-6-toc
  DUMP: DUMP IS DONE
[root@lyrebird ~]# ls -l backup-[4-6]
-rw-r--r-- 1 root root 7554939 2007-07-08 16:47 backup-4
-rw-r--r-- 1 root root   16198 2007-07-08 16:55 backup-5
-rw-r--r-- 1 root root   16560 2007-07-08 17:08 backup-6
[root@lyrebird ~]# cat /etc/dumpdates
/dev/sda3 0 Sun Jul  8 16:47:47 2007 -0400
/dev/sda3 2 Sun Jul  8 16:55:46 2007 -0400
/dev/sda3 1 Sun Jul  8 17:08:18 2007 -0400

Обратите внимание, что backup-6 на самом деле больше, чем backup 5. Дамп уровня 1 иллюстрирует использование опции -A для создания таблицы содержимого, которая может использоваться, чтобы определить, находится ли файл в архиве, без необходимости действительно монтировать архив. Это особенно полезно при использовании лент или других сменных архивных накопителей. Вы снова увидите эти примеры позже в этом разделе, когда мы будем обсуждать восстановление данных.

Команда dump может создавать файлы или подкаталоги дампа, но не может обновить /etc/dumpdates, и поддерживается только уровень дампа 0, то есть полный дамп.

Листинг 43 иллюстрирует процесс формирования и записи на дискету дампа каталога /usr/include/bits и его содержимого при помощи команды dump. В этом случае дамп не помещается на одну дискету, поэтому требуется новый том. Запрос и ответ выделены жирным шрифтом.

                    
[root@lyrebird ~]# dump -0 -f /dev/fd0 /usr/include/bits
  DUMP: Date of this level 0 dump: Mon Jul  9 16:03:23 2007
  DUMP: Dumping /dev/sdb9 (/ (dir usr/include/bits)) to /dev/fd0
  DUMP: Label: /
  DUMP: Writing 10 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 2790 blocks.
  DUMP: Volume 1 started with block 1 at: Mon Jul  9 16:03:30 2007
  DUMP: dumping (Pass III) [directories]
  DUMP: End of tape detected
  DUMP: Closing /dev/fd0
  DUMP: Volume 1 completed at: Mon Jul  9 16:04:49 2007
  DUMP: Volume 1 1470 blocks (1.44MB)
  DUMP: Volume 1 took 0:01:19
  DUMP: Volume 1 transfer rate: 18 kB/s
  DUMP: Change Volumes: Mount volume #2
  DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") y
  DUMP: Volume 2 started with block 1441 at: Mon Jul  9 16:05:10 2007
  DUMP: Volume 2 begins with blocks from inode 2
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Closing /dev/fd0
  DUMP: Volume 2 completed at: Mon Jul  9 16:06:28 2007
  DUMP: Volume 2 1410 blocks (1.38MB)
  DUMP: Volume 2 took 0:01:18
  DUMP: Volume 2 transfer rate: 18 kB/s
  DUMP: 2850 blocks (2.78MB) on 2 volume(s)
  DUMP: finished in 109 seconds, throughput 26 kBytes/sec
  DUMP: Date of this level 0 dump: Mon Jul  9 16:03:23 2007
  DUMP: Date this dump completed:  Mon Jul  9 16:06:28 2007
  DUMP: Average transfer rate: 18 kB/s
  DUMP: DUMP IS DONE

Если резервная копия записывается на ленту, следует помнить, что обычно лента перематывается после каждого использования. Устройство с именем типа /dev/st0 или /dev/st1 перематывается автоматически. Соответствующие неперематываемые эквивалентные устройства — /dev/nst0 и /dev/nst1. В любом случае всегда можно воспользоваться командой mt для выполнения таких операций с магнитной лентой как проматывание файлов и записей, перемотка и запись отметок конца файла (EOF marks). Дополнительную информацию см. в страницах руководств man для mt и st.

Разумный выбор уровней дампов позволит минимизировать количество архивов, необходимых для восстановления к любому определенному уровню. Пример стратегии на основе головоломки Ханойская башня см. в страницах руководства man для dump.

Эти команды, как и команда dd, имеют большое количество опций, не описанных в этом кратком введении. Подробнее см. в страницах руководства man.

В начало

Частичное и ручное резервное копирование

До сих пор вы знакомились с инструментами, которые хорошо работают резервном копировании файловых систем целиком. Иногда бывает необходима резервная копия не всей файловой системы, а отдельных файлов или подкаталогов. Например, может понадобиться создавать резервную копию большей части файловой системы еженедельно, а резервную копию файлов электронной почты — ежедневно. Для этих целей обычно используются другие две команды, cpio и tar. Обе они могут записывать архивы в файлы или на устройства, например, на ленты и дискеты, и обе могут восстанавливать данные из таких архивов. Сейчас из этих двух команд чаще используется tar, возможно потому, что она лучше работает с полными каталогами, и GNU-версия tar поддерживает сжатие и с помощью gzip, и с помощью bzip.

Использование cpio

Команда cpio работает для создания архива в режиме copy-out, для восстановления архива — в режиме copy-in, для копирования набора файлов из одного места в другое — в режиме copy-pass. В режиме copy-out используются опции -o или --create, в режиме copy-in — опции -i или --extract и в режиме copy-pass — опции -p или --pass-through. Вводом является список файлов, получаемый на стандартный ввод. Вывод происходит на стандартный вывод, или на устройство, или в определенный файл при помощи опции -f или --file.

В листинге 44 показано, как сгенерировать список файлов при помощи команды find. Обратите внимание, что команда find с опцией -print0 используется для создания строк, оканчивающихся на ноль (null-terminate), для имен файлов и команда cpio с опцией --null — для чтения этого формата. Это позоволяет правильно оперировать именами файлов, имеющими пробелы или символы перевода строки.

                    
[root@lyrebird ~]#  find ~ian -depth -print0 | cpio --null -o >backup-cpio-1
18855 blocks

Чтобы видеть список файлов по мере их архивирования, добавьте к cpio опцию -v.

Как и при использовании других команд, способных архивировать файлы, можно задать размер блока. Подробнее об этих и других опциях см. в страницах руководства man.

Использование tar

Команда tar (название происходит от Tape ARchive) создает архивный файл, или tarfile, или tarball из набора входных файлов или каталогов; также она восстанавливает файлы из таких архивов. Если в качестве ввода для tar используется каталог, все файлы и подкаталоги включаются автоматически, что делает tar очень удобным для архивирования поддеревьев структуры каталогов.

Как и для других команд, которые мы обсуждали, вывод может быть направлен в файл, на устройство, такое как лента или дискета, или на стандартный вывод. Местоположение вывода определяется при помощи опции -f. Другие наиболее часто используемые опции — это -c для создания архива, -x для разархивирования, -v для подробного вывода, содержащего список обрабатываемых файлов, -z для сжатия с использованием gzip и -j для сжатия с использованием bzip2. Большинство опций команды tar имеет короткую форму, при которой используется один дефис, и длинную форму, при которой используется пара дефисов. Описание длинных форм и других опций см. в страницах руководства man.

В листинге 45 показано, как создать резервную копию системных заданий cron при помощи tar.

                    
[root@lyrebird ~]# tar -czvf backup-tar-1 /etc/*crontab /etc/cron.d
tar: Removing leading `/' from member names
/etc/anacrontab
/etc/crontab
/etc/cron.d/
/etc/cron.d/sa-update
/etc/cron.d/smolt

В первой строке вывода указано, что tar удалит лидирующий слеш (\) из имен членов. Это позволяет восстановить файлы в какое-то другое место для проверки, прежде чем заменить системные файлы. Это хорошая идея, которая позволит при создании архивов избежать перемешивания абсолютных и относительных имен файлов, поскольку при восстановлении из архива все имена будут относительными.

Команда tar при помощи опции -r или --append может добавить в архив дополнительные файлы. Это может привести к тому, что в архиве будет несколько копий файла. В таком случае в ходе операции восстановления будет восстановлен только последний файл. Для выбора одного из нескольких файлов используется опция --occurrence. Если архив находится не на ленте, а на обычной файловой системе, для обновления архива используется опция -u или --update. Это работает подобно дополнению архива, за исключением того, что метки времени для файлов в архиве сравниваются с метками в файловой системе и добавляются только те файлы, которые изменились после создания заархивированной версии. Как было упомянуто, это не работает с архивами на лентах.

Как и другие изучаемые здесь команды, команда tar имеет множество опций, не описанных в этом кратком введении. Подробнее см. в страницах руководств man или info.

В начало

Целостность файла резервной копии

Целостность файла резервной копии чрезвычайно важна. Если резервная копия испорчена, нет смысла хранить ее. Хорошая стратегия резервного копирования также подразумевает проверку резервных копий.

Первый шаг к обеспечению целостности резервной копии — убедиться, что данные, для которых делается резервная копия, собраны правильно. Для того чтобы данные, для которых создается резервная копия, не изменились в процессе копирования, обычно бывает достаточно, чтобы система не была смонтирована или была смонтирована только для чтения. Если вам необходимо создать резервную копию файловых систем, каталогов или файлов, которые меняются в то время как создается резервная копия, следует убедиться, что не было сделано изменений в ходе резервного копирования. Если изменения были, необходимо избрать стратегию для их сбора, или повторив резервное копирование, или, возможно, заменив такие файлы внутри резервной копии. Разумеется, это затрагивает и процедуру восстановления.

Допустим, вы получили хорошие резервные копии, их необходимо периодически проверять. Один из способов состоит в том, чтобы восстановить резервную копию на запасной том и убедиться, что результат совпадает с тем, что было скопировано. Это самое простое, что следует сделать, прежде чем позволить обновить файловые системы данными резервной копии. Если резервная копия сохранена на медиа-носитель, такой как CD или DVD, можно использовать команду diff как часть процедуры резервного копирования, чтобы убедиться в качестве резервной копии. Помните, что даже качественные резервные копии при хранении могут портиться, поэтому, даже если они проверялись во время резервного копирования, их следует периодически проверять. Хранение дайджестов используемых программ, таких как md5sum или sha1sum — также хороший способ проверки целостности файла с резервной копией.

В начало

Восстановление файловых систем из резервных копий

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

Родственная проблема — необходимость убедиться, что нужные элементы находятся в определенной резервной копии, поскольку часто возникает необходимость получить доступ к версии файла, который был изменен, или, возможно, удален "когда-то на прошлой или позапрошлой неделе". Имея в виду все вышесказанное, давайте рассмотрим опции восстановления.

Восстановление dd-архива

Вспомните, что команда dd не распознает файловую систему, поэтому, чтобы узнать, что находится в дампе раздела, необходимо восстановить его. В листинге 46 показано, как раздел, из которого ранее в листинге 39 был создан дамп, восстановить на раздел /dev/sdc7, специально созданный на сменном USB-устройстве только с этой целью.

                    
[root@lyrebird ~]# dd if=backup-1 of=/dev/sdc7
2040255+0 records in
2040255+0 records out
1044610560 bytes (1.0 GB) copied, 44.0084 s, 23.7 MB/s

Вспомните, что после того как была получена эта резервная копия, мы добавили к файловой системе на /dev/sda3 некоторые файлы. Вы увидите, что это действительно так, если подмонтируете недавно восстановленный раздел и сравните его с оригиналом, как показано в листинге. Обратите внимание, что файл, метка времени которого была обновлена при помощи touch, здесь не показан, как следовало бы ожидать.

                    
[root@lyrebird ~]# mount /dev/sdc7 /mnt/temp-dd/
[root@lyrebird ~]# diff -rq /grubfile/ /mnt/temp-dd/
Only in /grubfile/: newerfile
Only in /grubfile/: newfile

Восстановление dump-архива при помощи restore

Вспомните, что в последний раз мы использовали dump для дифференциального резервного копирования и что мы создали таблицу содержимого. В листинге 48 показано, как, используя сам архив (backup-5) или таблицу содержимого (backup-6-toc), воспользоваться командой restore для проверки файлов из архива, созданного при помощи dump.

                    
[root@lyrebird ~]# restore -t -f backup-5
Dump tape is compressed.
Dump   date: Sun Jul  8 16:55:46 2007
Dumped from: Sun Jul  8 16:47:47 2007
Level 2 dump of /grubfile on lyrebird.raleigh.ibm.com:/dev/sda3
Label: GRUB
         2      .
    100481      ./ibshome
    100482      ./ibshome/index.html
        16      ./newfile
[root@lyrebird ~]# restore -t -A backup-6-toc
Dump   date: Sun Jul  8 17:08:18 2007
Dumped from: Sun Jul  8 16:47:47 2007
Level 1 dump of /grubfile on lyrebird.raleigh.ibm.com:/dev/sda3
Label: GRUB
Starting inode numbers by volume:
        Volume 1: 2
         2      .
    100481      ./ibshome
    100482      ./ibshome/index.html
        16      ./newfile
        17      ./newerfile

Команда restore также может при помощи опции -C сравнить содержимое архива с содержимым файловой системы. В листинге 49 мы обновили newerfile и затем сравнили резервную копию с файловой системой.

                    
[root@lyrebird ~]# echo "something different" >/grubfile/newerfile
[root@lyrebird ~]# restore -C -f backup-6
Dump tape is compressed.
Dump   date: Sun Jul  8 17:08:18 2007
Dumped from: Sun Jul  8 16:47:47 2007
Level 1 dump of /grubfile on lyrebird.raleigh.ibm.com:/dev/sda3
Label: GRUB
filesys = /grubfile
./newerfile: size has changed.
Some files were modified!  1 compare errors

Восстановление при помощи команды restore может производиться интерактивно или автоматически. В листинге 50 показано, как восстановить newerfile в домашний каталог пользователя root (так что при необходимости его можно проверить, прежде чем заменить обновленный файл), а затем заменить обновленный файл резервной копией. Этот пример иллюстрирует интерактивное восстановление.

                    
[root@lyrebird ~]# restore -i -f backup-6
Dump tape is compressed.
restore > ?
Available commands are:
        ls [arg] - list directory
        cd arg - change directory
        pwd - print current directory
        add [arg] - add `arg' to list of files to be extracted
        delete [arg] - delete `arg' from list of files to be extracted
        extract - extract requested files
        setmodes - set modes of requested directories
        quit - immediately exit program
        what - list dump header information
        verbose - toggle verbose flag (useful with ``ls'')
        prompt - toggle the prompt display
        help or `?' - print this list
If no `arg' is supplied, the current directory is used
restore > ls new*
newerfile
newfile
restore > add newerfile
restore > extract
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume # (none if no more volumes): 1
set owner/mode for '.'? [yn] y
restore > q
[root@lyrebird ~]# mv -f newerfile /grubfile

Восстановление архива cpio

Команда cpio в режиме copy-in (опция -i или --extract) может вывести список содержимого архива или восстановить избранные файлы. Использование опции --absolute-filenames при перечислении файлов уменьшит количество ненужных сообщений, которые в противном случае выдаст cpio, поскольку эта опция отбросит все лидирующие символы / от каждого имени пути, имеющего / в начале. В листинге 51 показан частичный вывод листинга нашего предыдущего архива.

                    
[root@lyrebird ~]# cpio  -id --list --absolute-filenames <backup-cpio-1
/home/ian/.gstreamer-0.10/registry.i686.xml
/home/ian/.gstreamer-0.10
/home/ian/.Trash/gnome-terminal.desktop
/home/ian/.Trash
/home/ian/.bash_profile

В листинге 52 показано, как восстановить все файлы, содержащие в имени пути или имени файла слово "samp". Вывод пропущен через команду uniq, чтобы уменьшить количество сообщений вида "Removing leading '/' ...". Для создания каталога следует использовать опцию -d; в противном случае все файлы будут созданы в текущем каталоге. Кроме того, cpio не заменит на файловой системе никакие более новые файлы на архивные копии, если только не использовалась опция -u или --unconditional.

                    
[root@lyrebird ~]# cpio  -ivd "*samp*" < backup-cpio-1 2>&1 |uniq
cpio: Removing leading `/' from member names
home/ian/crontab.samp
cpio: Removing leading `/' from member names
home/ian/sample.file
cpio: Removing leading `/' from member names
18855 blocks

Восстановление архива tar

Команда tar также может сравнивать архивы с текущей файловой системой и восстанавливать файлы из архивов. Для выполнения сравнения используются опции -d, --compare, или --diff. Вывод покажет файлы, содержимое которых отличается, а также файлы, у которых отличаются метки времени. В листинге 53 показан расширенный вывод (использована опция -v), полученный в результате сравнения ранее созданного файла и файлов в /etc после того как с целью изменить метку времени был затронут файл /etc/crontab. Опция --directory / дает команде tar указание выполнить сравнение, начиная не с текущего, а с корневого каталога.

                    
[root@lyrebird ~]# touch /etc/crontab
[root@lyrebird ~]# tar --diff -vf backup-tar-1 --directory /
etc/anacrontab
etc/crontab
etc/crontab: Mod time differs
etc/cron.d/
etc/cron.d/sa-update
etc/cron.d/smolt

В листинге 54 показано, как извлечь из текущего каталога только /etc/crontab и /etc/anacrontab.

                    
[root@lyrebird ~]# tar -xzvf backup-tar-1 "*tab"
etc/anacrontab
etc/crontab

Обратите внимание, что tar, в отличие от cpio, автоматически создает иерархию каталогов.

В следующем разделе этого учебного пособия показано, как управлять системным временем.

В начало

	Страница 6 из 10