Настройка режима инкрементного архивирования
Категория: Резервное копирование | Автор: admin | 25-11-2009, 03:14 | Просмотров: 4808

Самые распространенные программные средства создания резервных копий и восстановления из них данных — команды dump и restore. Эти команды входят в состав операционной системы UNIX уже длительное время и их характеристики хорошо известны. В большинстве организаций команды dump и restore используются автоматизированными системами резервной: копирования.

 

Архивирование файловых систем

 

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

  • резервные копии могут быть записаны на несколько лент;
  • можно выполнять резервное копирование и восстановление файлов любого типа (даже файлов устройств);
  • можно восстанавливать права доступа, принадлежность и время модификации файлов;
  • обеспечивается правильная обработка файлов с "дырами";
  • резервное копирование может производиться в инкрементном режиме (на ленту записываются только модифицированные версии файлов).

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

Первое ограничение заключается в том, что каждая файловая система должна архивироваться в индивидуальном порядке. Если диск разбит на разделы, придется копировать каждый раздел отдельно. Следующее ограничение: разрешается копировать только файловые системы локальной машины, а файловую систему NFS архивировать нельзя. Тем не менее, можно создать резервную копию локальной файловой системы на удаленном ленточном накопителе; для этого используется программа rdump

 

Самая важная особенность команды dump состоит в поддержке инкрементного резервного копирования. Можно, конечно, каждый день создавать копии всей системы, но это не совсем практично. В инкрементном режиме резервируются только те файлы, которые изменились с момента последнего копирования.

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

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

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

Команда dump анализирует свои аргументы не так, как большинство остальных команд UNIX. В строке ее вызова сначала следует указывать все флаги, а затем перечислять аргументы флагов. Другими словами, вместо строки -а 5 -b -с10 команда dump ожидает строку abc 5 10.

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

Свою выходную информацию команда dump посылает на некое стандартное устройство. Как правило, это основной ленточный накопитель. Если необходимо задать другое устройство, воспользуйтесь флагом f, чтобы сообщить команде dump, куда она должна отправлять данные. Когда на одну ленту помещается несколько архивов, укажите имя ленточного устройства не поддерживающего режим перемотки (т.е. задайте файл устройства, который не вызывает перемотку ленты по окончании записи — для большинства ленточных устройств такой файл создается наряду со стандартным). Чтобы определить имя соответствующего файла, прочтите man-страницу с описание ленточного устройства (табл. 10.2).

Таблица 10.2. Файлы устройств для стандартного ленточного устройства SCSI

Система

Режим перемотки

Без режима перемотки

Solaris

HP-UX

Red Hat

FreeBSD

/dev/rmt/0

/dev/rmt/0m

/dev/st0

/dev/rsa0

/dev/rmt/on

/dev/rmt/0mn

/dev/nst0

/dev/nrsa0

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

Если архив помещается в удаленную систему с помощью программы rdump, удаленное устройство нужно задать в формате имя:устройство, например:

# rdump 0uf anchor:/dev/nst0 /spare

 

Права доступа к удаленному ленточному устройству задаются в файле .rhosts. Но мы рекомендуем воспользоваться системой SSH.

Раньше нужно было указывать команде dump точную длину ленты, чтобы она могла прекратить запись при достижении конца ленты. Современные накопители самостоятельно обнаруживают конец ленты и сообщают об этом команде dump, которая перематывает ленту обратно, выталкивает носитель из устройства и запрашивает новую ленту. Поскольку применение различных аппаратных алгоритмов сжатия не позволяет так просто определить длину ленты на основании ее емкости, лучше ориентироваться на сигнал конца ленты (EOT — End Of Таре), если, конечно, его поддерживает устройство и понимает команда dump.

К сожалению, сигнал EOT появился гораздо позже, чем произошло разделение семейств UNIX-систем, поэтому различные версии команды dump работают с лентами по-разному. Одни по умолчанию предполагают, что ленточные накопители сами генерируют сигнал EOT, поэтому никак не ограничивают размер ленты. Другие считают, что лента имеет длину 2300 футов (примерно 70 метров) и плотность записи 1600 bpi (битов на дюйм), что соответствует 9-дорожечным лентам 15-летней давности, но никак не сегодняшним носителям. Эти версии команды обычно понимают сигнал EOT, если он возникает раньше запланированного конца ленты. В таких случаях лучше обмануть команду dump, сообщив ей, что лента гораздо длиннее, чем есть на самом деле.

Все версии команды dump понимают опции d и s, которые задают плотность ленты в байтах на дюйм и длину ленты в футах соответственно. Иногда можно даже указывать размер ленты в килобайтах. Если же такой возможности нет, необходимо выполнить несложные арифметические вычисления и получить нужный размер.

Предположим, например, что требуется создать архив пятого уровня для каталога /work и записать его на устройство DDS-1 (DAT), стандартная емкость носителя которого составляет 1 Гбайт, а в режиме сжатия — 1,5 Гбайт. DAT-устройства выдают сигнал EOT, поэтому нужно сообщить команде dump заведомо больший размер ленты, скажем, 4 Гбайт. Это составит 60000 футов при ппотности записи 6250 bpi.

# dump 5usdf 60000 6250 /dev/rstO /work

DUMP: Date of this level 5 dump: Mon May   8 16:59:45 2000

DUMP: Date of last level 0 dump: the epoch

DUMP: Dumping /dev/hda2  (/work)  to /dev/rstO

DUMP: mapping  (Pass I)   [regular files]

DUMP: mapping  (Pass II)   [directories]

DUMP: estimated 942223 tape blocks on 0.23 tape(s).

...

 

За флагами 5usdf следуют значения аргументов s (размер: 60000), d (плотность: 6250) и f (файл устройства: /dev/rst0). В конце указывается обязательный аргумент: имя файловой системы (/work). Большинство версий команды dump позволяют задавать файловую систему точкой ее монтирования, как в приведенном примере. Некоторые версии этой команды требуют указывать исходный файл устройства.

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

В Solaris команда dump не имеет ничего общего с резервным копированием: она используется для проверки объектных файлов. Когда инженерам компании Sun становится скучно, один из менеджеров рассказывает историю о том, как один "чайник" пытался архивировать диски с помощью команды dump, и все смеются. "Настоящая" команда dump называется /usr/sbin/ufsdump. К счастью, команда ufsdump использует те же флаги и аргументы, что и традиционная версия dump. Например, команда

# ufsdump 0uf /dev/rmt/2 /dev/rdsk/c0t3d0s5

 

создает архив раздела 5 SCSI-диска с целевым номером 3, помещая его на ленточный накопитель с номером 2.

Возможно, в Linux придется явно инсталлировать команды dump и restore, так как по умолчанию они отсутствуют. Имеется модуль rpm (Red Hat Package Manager — менеджер пакетов Red Hat), который упрощает инсталляцию. В Linux файлы не компонуются статически, поэтому необходимо наличие общедоступных библиотек в каталоге /lib. Во FreeBSD, OpenBSD и NetBSD команда restore компонуется статически. В этом случае она являете; совершенно самодостаточной, что упрощает восстановление после сбоев.

 

Схемы создания архивов

 

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

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

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

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

Сложная схема резервного копирования может создаваться по трем причинам:

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

Мы опишем несколько возможных схем и приведем аргументы в пользу  каждой из них.

 

Простая схема

 

Если общий размер дискового пространства меньше емкости ленточного накопителя, можно предложить совершенно тривиальный график резервирования. Архивы нулевого уровня каждой файловой системы нужно создавать ежедневно. Используйте многократно один набор лент, но через каждые N дней (где N определяется потребностями компании или организации) откладывайте ленты навсегда. Стоимость такой схемы составит

(365/N)  *   (цена ленты)

 

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

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

 

Умеренная схема

 

Более приемлемый план — выделить по одной ленте на каждый день недели, каждую неделю месяца (здесь понадобится пять лент) и каждый месяц года. Ежедневно создавайте архив девятого уровня на дневной ленте, еженедельно — архив пятого уровня на недельной ленте, ежемесячно — архив третьего уровня на месячной ленте. Архив нулевого уровня нужно создавать каждый раз, когда инкрементные копии становятся слишком велики для одной ленты. Чаще всего это происходит с месячными лентами. В любом случае архивирование нулевого уровня необходимо выполнять хотя бы раз в год.

Уровни 3, 5 и 9 выбраны произвольно. С таким же успехом можно использовать уровни 1, 2 и 3, но интервалы между уровнями дают некоторую свободу для маневра на случай, если впоследствии потребуется добавить еще один уровень.

Такой график требует наличия двадцати четырех основных лент, а также некоторого количества лент для архивов нулевого уровня. Общее число необходимых лент невелико, но и избыточность невысока.

 



 (голосов: 1)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page