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

Надежное хранение данных

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

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

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

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

Здесь уместно заметить, что системному администратору или проектировщику системы следует полагаться только на проверенные решения. Следующие несколько абзацев предназначены тем, кто планирует эксплуатировать Solaris на платформе x86, поскольку платформа Sun SPARC представляет собой более чем проверенное решение, за качество которого единственный его производитель, Sun Microsystems, ручается головой. Случаев жалоб на фирменное оборудование Sun в России мне слышать не приходилось. Коллеги из московского представительства: поправьте меня, если я не прав!

Следите за состоянием оборудования - версия x86

Итак, если перед вами стоит задача проектирования системы на платформе x86, постарайтесь учесть опыт (в том числе и печальный!) автора этих строк.

Во-первых, используйте ту аппаратуру, которая точно находится в HCL Solaris вашей версии. Описание сложностей, которые связаны с пренебрежением этим правилом, содержится в лекции 3, например.

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

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

В-четвертых, НИКОГДА не пробуйте самые последние новинки на том оборудовании, которое должно выполнять какие-то жизненно важные функции. Если душа просит экспериментов, проведите их на том компьютере, крах которого никому не принесет слез или потерянных данных.

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

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

Самодельные устройства, регулирующие напряжение в сети, оголенные провода, плохие контакты в розетках и старая проводка приводят (как ни странно!) к пожарам. Автор был свидетелем нескольких пожаров, вызванных именно такими тривиальными причинами - поверьте, качеству проводки и электрооборудования надо уделить самое пристальное внимание при монтаже любой компьютерной системы.

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

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

Планируйте замену оборудования заранее! Сервер на платформе x86 не должен работать как часы в течение десятилетий; такое оборудование потребует полной замены через пять лет, более того, уже через год-два оно потеряет в цене половину. Если вы заботитесь не только о надежности работы системы, но и об экономической эффективности, следует планировать замену оборудования с продажей старого не реже, чем раз в два года.

Аппаратные средства хранения данных

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

Для долговременного хранения и создания архивов по-прежнему применяют ленточные накопители (кассеты DLT могут содержать до 70 Гбайт данных, а SDLT - до 160 Гбайт, при аппаратном сжатии производитель - компания Hewlett-Packard обещает емкость 320 ГбайтНа момент выхода книги (середина 2005 года). ), оптические диски (CD-R, CD-RW, DVD), Jaz- и ZIP-накопители. В некоторых случаях используют дискеты.

Для повышения надежности систем хранения, основанных на жестких дисках, применяют RAID-массивы, аппаратуру, которая позволяет сохранять данные с той или иной степенью избыточности. Solaris поддерживает аппаратуру RAID, подробное ее описание приводится в фирменной документации производителей (StorEdge и многие другие) или в доступных источниках в Интернете.

С точки зрения операционной системы, RAID-массив представляет собой просто один жесткий диск. То, что фактически такой массив состоит из многих (обычно пяти-семи) дисков и может обеспечивать возможность замены дисков "на лету", без выключения или перенастройки оборудования, скрыто от операционной системы и гарантируется аппаратурой самого RAID-массива. Такие массивы обычно присоединяются к шине SCSI и стоят достаточно дорого по сравнению с обычными дисками.

Программные средства хранения с избыточностью

Для экономии средств вы можете отказаться от приобретения аппаратуры RAID. Solaris предоставляет возможность организовать полноценный RAID-массив программно, с использованием нескольких жестких дисков и программы Solstice Disksuite. Эта программа дает возможность выполнять зеркалирование (RAID уровня 1), также как и расслоение с избыточностью (запись блоков данных и блоков четности на разные диски - RAID уровня 5).

В Solaris, начиная с версии 8, Disksuite включен в состав системы. Ранее его надо было устанавливать как отдельный пакет. Этот пакет - не единственный, позволяющий реализовать программный RAID в Solaris, но он пользуется популярностью у администраторов Solaris.

Solstice Disksuite был переименован в Solaris Volume Manager при переходе от Solaris 8 к Solaris 9 и стал еще более тесно интегрирован в систему. Вызвать графическую оболочку Solaris Volume Manager можно из Solaris Management Console. Самостоятельно она не вызывается.

Для создания зеркала или программного массива RAID 5 используйте команду metainit. Для проверки - metastat.

Подробное описание работы с SVM можно найти, например, по адресу .

Кроме SVM есть еще широко известный продукт Veritas Volume Manager (от компании Veritas Software), c ним можно познакомиться по адресу .

Система контроля версий

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

В разных системах UNIX могут использоваться разные системы контроля версий. Очень широко распространена CVS, применяющаяся, в частности, для обновлений FreeBSD. В Solaris такая система носит название SCCS (Source Code Control System). Общим для всех систем такого типа является наличие репозитория, т.е. каталога, в котором хранятся копии документов (файлов) и их описания.

Система контроля версий может быть использована и как средство отслеживания изменений, что очень полезно при модификации файлов конфигурации, и как средство резервного копирования. В последнем случае репозиторий надо регулярно копировать на какие-либо независимые носители. Сама по себе система контроля версий не обеспечивает ни создания резервных копий, ни ведения жесткого контроля версий: и то, и другое требует организационной культуры сотрудников! Помните: система контроля версий - это только инструмент, и только его постоянное и корректное использование поможет вам организовать работу удобно и надежно.

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

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

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

Как начать работу с SCCS

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

Основные команды программы sccs перечислены в табл. 23.1:

Итак, начнем. Предположим, мы создаем репозиторий для файлов из каталога /usr/develop (пример c каталогом /etc так часто рассматривается в литературе, что мы сочли его банальным, если вы желаете сделать репозиторий для каталога /etc, просто замените все /usr/develop в нашем примере на /etc).

cd /usr/develop
mkdir SCCS

теперь создаем файл истории проекта для файлов q и q1:

/usr/ccs/bin/sccs create q q1

q:
No id keywords (cm7)
q1:
No id keywords (cm7)
1.1
2 lines
No id keywords (cm7)
1.1
40 lines
No id keywords (cm7)

Файлы оригиналов (т.е. того, что было до помещения файлов в репозиторий) сохраняются с именами, идентичными именам оригиналов, но с добавленной в начале запятой. Файлы истории предваряются префиксом s.:

ls -l SCCS
total 6
-r--r--r-- 1 root other 155 Июн 26 16:01 s.q
-r--r--r-- 1 root other 1877 Июн 26 16:01 s.q1

ls -l
-rw-r--r-- 1 root other 7 Май 5 20:15 ,q
-r--r--r-- 1 root other 7 Июн 26 16:01 q
-rw-r--r-- 1 root other 1729 Июн 20 23:32 ,q1
-r--r--r-- 1 root other 1729 Июн 26 16:01 q1

Посмотрим содержимое файла q и попробуем его изменить.

Для редактирования файла следует его извлечь из репозитория; это делается командой sccs edit:

bash-2.05# /usr/ccs/bin/sccs edit q
1.1
new delta 1.2
2 lines

Посмотрим, как выглядит файл:

bash-2.05# cat q
test

Отлично, выглядит по-прежнему. Если его изменить, а затем дать команду извлечения из репозитория, сделанные изменения пропадут, файл будет прежним. Изменения в файл следует вносить только после того, как файл извлечен из репозитория для модификации. Добавим строку в конец файла:

bash-2.05# cat >> q
test1

Теперь внесем изменения в файл истории в репозитории:

bash-2.05# /usr/ccs/bin/sccs delta q
comments? new line added
No id keywords (cm7)
1.2
1 inserted
0 deleted
2 unchanged

Если после внесения изменений в файл истории снова требуется изменить сам файл (в нашем случае - файл q), то вместо delta следует указать подкоманду deledit, что эквивалентно последовательности команд

/usr/ccs/bin/sccs delta q
/usr/ccs/bin/sccs edit q

Файл истории файла q в каталоге SCCS выглядит так:

h13611
s 00001/00000/00002
d D 1.2 04/06/26 16:12:03 root 2 1
c new line added
e
s 00002/00000/00000
d D 1.1 04/06/26 16:01:16 root 1 0
c date and time created 04/06/26 16:01:16 by root
e
u
U
f e 0
t
T
I 1
test

I 2
test1
E 2
E 1

Как видим, в файле истории сохраняется информация о самих изменениях, а также о времени и авторе этих изменений.

Где сохранить резервную копию

Рассмотрим несколько возможных носителей для хранения копий данных. Они отличаются емкостью, скоростью записи и чтения, стоимостью, чувствительностью к внешним воздействиям.

Ленты (кассеты). Требуют использования накопителей на магнитной ленте. Емкость кассет обычно невелика, хотя современный формат DLT позволяет сохранять до 70 Гбайт на одной кассете. К сожалению, объем и скорость работы лент и кассет растет медленнее, чем объем и скорость жестких дисков, и поэтому ценность ленточных накопителей падает день за днем: невыгодно сохранять один раздел жесткого диска на нескольких кассетах - это очень замедляет и запись, и чтение данных. По традиции ленточные накопители остаются стандартом резервного копирования в больших системах, требующих регулярного сохранения данных в архивах. Долговременное хранение кассет достаточно удобно, хотя они подвержены воздействию электромагнитных полей и должны храниться вдали от сильных источников тепла и электромагнитов. Дополнительной проблемой является то, что емкие кассеты и быстрые накопители на магнитной ленте стоят довольно дорого: SDLT-стример на 160 Гбайт от компании Hewlett-Packard стоит примерно 3500-4000 долларов. Картридж к нему - 80 долларов.

Идеальным носителем могли бы быть оптические компакт-диски (CD-R или DVD): скорость их записи заметно выше, чем скорость записи лент, скорость чтения сравнима со скоростью жестких дисков, они практически не подвержены внешним воздействиям (конечно, их не следует поджаривать или колотить, как и прочие носители, но зато электромагнитные поля им нипочем), хранить диски можно в штабелях, в конвертах, коробках и т.п., более того, их можно прочесть в любой операционной системе - от Windows до Mac, включая все разновидности UNIX. Одно плохо: пока на такие диски не научились записывать более 700 Мбайт (CD-R) или 4,7 Гбайт (DVD) - а это слишком мало для сохранения копий больших разделов.

Jaz- и ZIP-диски. Обладают комбинацией недостатков лент и компакт-дисков, большого смысла рассматривать их как промышленное средство сохранения данных в настоящее время нет. Объем Jaz-диска - 2 Гбайт, ZIP-диска - 100 или 250 Мбайт.

Дискеты. Очень маленький полезный объем (1,44 Мбайта) компенсируется универсальностью: читаются повсюду, где есть дисковод. Чрезвычайно чувствительны к внешним магнитным полям - не рекомендуется, например, носить дискеты в портфеле рядом с мобильным телефоном. Качество современных дискет подстать их цене - из коробки ценой три доллара четыре дискеты из десяти легко окажутся бракованными еще до начала использования. Как средство хранения копий важных файлов лучше не рассматривать.

Флэш-память. Начиная с версии 8, Solaris стандартно поддерживает такой вид накопителей, хотя в некоторых случаях требуется установить обновление системы от Sun. Современные недорогие модели флэш-модулей, подключаемых к компьютеру по USB, имеют объем до 128 Мбайт, а более дорогие - до 1 Гбайт. Можно использовать как хорошую замену дискетам и даже компакт-дискам. Этот носитель следует беречь от воздействия сильных магнитных полей и высокой температуры.

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

Средства резервного копирования

tar

Для сжатия больших файлов в UNIX изначально использовалась программа compress. Она сжимала файл, после сжатия добавляла к имени файла .Z. Программа compress до сих пор поставляется практически со всеми диалектами UNIX. В IRIX и некоторых других системах она является стандартной утилитой сжатия. Чтобы вернуть файл, сжатый compress, к прежнему, несжатому состоянию используется uncompress.

В Linux и FreeBSD, а также во многих других диалектах для сжатия применяют gzip. Он использует тот же алгоритм сжатия LZW, что и WinZip или pkzip, известные вам по системам Microsoft, однако не совместим с ними по формату файлов. Программа WinZip for Windows понимает форматы gzip, а gzip ее форматы не понимает. Для распаковки файлов, сжатых gzip, используют gunzip. Большинство версий gzip не умеют сжимать каталоги с их содержимым - только файлы.

Есть еще утилиты zip и unzip, которые работают с теми же форматами файлов, что и pkzip, WinZip и другие архиваторы в Microsoft-системах. Они редко используются в UNIX, только если нужно обеспечить совместимость с Windows-системами.

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

Затем удобно сжать получившийся файл с помощью gzip, чтобы он занимал меньше места. Многие дистрибутивы программных пакетов в UNIX упакованы tar и gzip. У команды tar даже есть ключ z. Он говорит tar, что после упаковки файлов в архив нужно вызвать gzip для сжатия. Такой же ключ используется и для распаковки - когда tar перед тем, как начать свою работу, вызывает gunzip.

Например, мне нужно упаковать дистрибутив apache, который лежит в /home/apache:

cd /home
tar cvzf apache.tar.gz apache/*

Всего три команды в UNIX принимают (и в некоторых версиях - требуют) ключи без знака "минус" перед ними. Это ps, dump и tar. Мы использовали для создания архива следующие ключи:

# так делать не надо
cd /home/apache
tar cvzf apache.tar.gz *

Архив так тоже можно создать, но при распаковке он "рухнет" всеми своими сотнями файлов и подкаталогов в тот каталог, где он будет распаковываться. Это неудобно, да и не принято - это считается дурным тоном. Намного грамотнее и красивее упаковать сразу целый каталог, как в предыдущем примере. Тогда по команде

tar xzvf apache.tar.gz

в том каталоге, где лежит архив, создастся подкаталог apache (помните, там было сказано "apache/*"?). И уже в него будут распакованы все файлы и подкаталоги архива. В этой команде tar мы использовали один незнакомый ключ - x. Он требует распаковать архив.

compress, gzip, zip

Для сжатия архивов можно применять как gzip, так и compress - более старую утилиту из первых систем UNIX. Результатом выполнения команды сжатия файла data.txt

compress data.txt

будет файл data.txt.Z. При применении gzip результат будет в среднем лучше, так как этот архиватор обычно сжимает файлы сильнее. При этом он дописывает к имени сжатого файла суффикс .gz. В обоих случаях исходный (несжатый) файл исчезает, остается только сжатый файл. Надо помнить, что при нехватке места на диске архив не может быть создан, если свободного места осталось впритык, так как несжатый исходный файл удаляется только после его успешного сжатия и переименования временного сжатого файла в окончательный результат.

Для декомпрессии файлов, сжатых утилитами compress и gzip, используйте uncompress и gunzip соответственно. В некоторых версиях UNIX используется еще более новый архиватор bzip2 (и декомпрессор bunzip2 ), но в Solaris он пока еще не портирован.

dd

Для копирования носителей целиком в их образы (например, дискет или компакт-дисков) и обратно служит программа dd. С ее помощью также можно копировать целые разделы дисков. Обычный формат вызова этой программы таков:

dd if=/dev/fd0 of=/usr/home/admin/diskettes/image1

Фактически, dd расценивает то, что она копирует, как блоки произвольных данных указанной длины (используется разумное умолчание в 512 байт). Использовать dd можно тогда, когда следует иметь две или более резервных копий: первую копию на ленту записывают с помощью программы ufsdump, а остальные копии создают копированием с ленты на ленту программой dd:

dd if=/dev/rmt/0h of=/dev/rmt/2h

Нельзя использовать эту программу для копирования файлов с одной файловой системы на другую, если размер блоков этих файловых систем - разный.

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

cpio

Команда cpio служит для копирования файлов в архив и из архива и умеет работать в трех режимах: входящего копирования, исходящего копирования и пассивного копирования. Режим исходящего копирования (копирования в архив, Copy Out Mode) используется для создания архива из файлов, подходящих по маске. Так, для архивации файлов, чьи имена начинаются с q, можно использовать такую последовательность команд:

ls q* | cpio -oc >Q/sccs.backup
16 blocks
cd Q
ls
sccs.backup

Файл результата состоит из заголовка и записанного вслед за ним имен и содержимого архивируемых файлов. Сжатия информации не производится. Так выглядит начало получившегося файла sccs.backup:

head sccs.backup
070701000020fc0000812400000000000000010000000140dd6ab70000
0012000000660000000700000000000000000000000200000005q

test1

Применим входящее копирование (т.е. копирование из архива, Copy In Mode) для извлечения из архива определенных файлов, в нашем примере - файла q:

ls
sccs.backup
cat sccs.backup | cpio -i q
4 blocks
ls
q sccs.backup

Пассивное копирование (Pass Mode)Здесь был бы уместнее термин "сквозное копирование", но "пассивное" - это термин, введенный в переводе книги Пола Уотерса "Solaris 8. Руководство администратора". Поскольку эту книгу смело можно порекомендовать для изучения, а многие ее уже знают, я сохраняю терминологию, пусть немного в ущерб понятности термина. Смотрите детали в man cpio (прим. авт.). служит для копирования файлов между файловыми системами, когда не применима команда mv. В этом режиме cpio читает список файлов со стандартного ввода и копирует эти файлы в указанный каталог (дерево каталогов).

Фактически, cpio всегда принимает список файлов со стандартного ввода (кроме случая входящего копирования). Ключи, которые описаны в man cpio, предписывают программе особенности поведения, такие как создание подкаталогов по необходимости и т.п.

Программы ufsdump и ufsrestore

Общие соображения

В большинстве систем UNIX для резервного копирования файловых систем на ленту и восстановления файлов с ленты применяются программы dump и restore. В Solaris для этой же цели используют собственные программы ufsdump и ufsrestore. Принципиальной разницы между общепринятым вариантом и специфичным для Solaris нет, программы dump, ufsdump занимаются резервным копированием данных, а restore и ufsrestore - восстановлением данных (т.е. переписыванием файлов с ленты на диск). Программы, применяющиеся в Solaris, обладают несколько большей функциональностью, например, позволяют выполнять копирование файлов на дискету (ключ D ), в то время как dump / restore работают только с ленточными накопителями.

В данном разделе мы рассмотрим только общие особенности этих программ, поэтому материал раздела применим не только к системе Solaris, но и к другим системам UNIX.

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

Программа ufsdump выполняет копирование файловой системы целиком, ее можно (но не следует) применять для копирования отдельных каталогов.

Она может выполнять копирование не только на ленту, но и в файл на диске, а также на дискету. При копировании информации на жесткий диск более разумно использовать обычные утилиты копирования типа cp или специализированные типа tar или rsync (если нужно выполнить копирование на удаленный компьютер).

Следует обязательно указывать уровень копирования при копировании на ленту. Программа ufsdump позволяет задать 10 уровней с 0 до 9. Уровень 0 - это копирование всей файловой системы целиком.

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

Уровни копирования введены для того, чтобы инкрементное копирование, т.е. копирование только измененных файлов, было легче организовать. Оно экономит место на ленте и время, затрачиваемое на резервное копирование. Обратной стороной медали в данном случае является большее время восстановления данных, так как если файловая система была сохранена полностью три дня назад, а вчера и позавчера выполнялось инкрементное копирование, при восстановлении придется задействовать три кассеты - чтобы восстановить файловую систему по состоянию на момент последнего резервного копирования. Если время позволяет, а свободное место на ленте заведомо превышает объем копируемых данных, удобнее всегда делать полное копирование выбранной файловой системы. В таком случае, когда бы ни произошел сбой, всегда хватит одной единственной кассеты - самой свежей - чтобы полностью восстановить файловую систему.

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

При нехватке места на ленте или диске, на которые производится резервное копирование, ufsdump предупредит об этом и попросит вставить в используемое для копирования устройство новый носитель (кассету с лентой). Конец ленты вызывает передачу сигнала от накопителя системе. Если стример не умеет выдавать этот сигнал, следует указать команде ufsdump размер носителя в килобайтах явным образом.

Программа ufsdump позволяет задавать плотность записи на ленту. Плотность записи зависит только от типа и модели стримера и указана в его описании. Используйте только те кассеты, что указаны в руководстве к стримеру! Вообще, это неплохая идея - почитать руководство к устройству, от правильной работы которого всецело зависит надежность резервирования данных всей сети.

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

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

Однозначно НЕ СЛЕДУЕТ выполнять резервное копирование разделов, где расположены временные файлы, файлы протоколов (если только протоколы не представляют ценности для вашей организации), дистрибутив системы или файлы приложений, которые легко установить из дистрибутива.

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