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

Программы 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) резервное копирование раздела с важной информацией, что требует ее размещения на одном разделе.

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

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