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

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
070701000020fc0000812400000000000000010000000140dd6ab7000000120000
00660000000700000000000000000000000200000005q
test1

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

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

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

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

rsync

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

Можно применять rsync для работы поверх ssh или для самостоятельной работы в режиме клиент-сервер. В последнем случае потребуется на одной из сторон копирования запустить сервер rsync, который запускается командой rsync с ключом --daemon. Для запуска rsync в режиме сервера следует вначале создать и наполнить осмысленным содержанием файл /etc/rsyncd.conf, в котором указывается, какие каталоги и с какими правами доступа к ним сервер rsync позволит видеть снаружи.

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

Для копирования файлов с компьютера remote из каталога src/bar на локальный комптютер в каталог /data/tmp дать команду

rsync -avz remote:src/bar /data/tmp

А для того, чтобы передать с компьтера remote из каталога /data/important все файлы в каталог /data/remote/backup на локальном компьтютере с использованием ssh (фактически, поверх ssh ) следует дать команду

rsync -e ssh -avz remote:/data/important   /data/remote/backup

При этом на компьютере remote должен быть доступен для запуска ssh и вы должны будете корректно аутентифицировать себя (ввести пароль) для выполнения команды.

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

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

В большинстве систем UNIX для резервного копирования файловых систем на ленту и восстановления файлов с ленты применяются программы dump и restore. В Solaris для этой же цели для файловых систем UFS используют собственные программы 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) резервное копирование раздела с важной информацией, что требует размещения важной информации на одном разделе.

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

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

Как правильно запустить ufsdump

Синтаксис команды ufsdump отличается от синтаксиса большинства команд UNIX:

ufsdump [[ключи] [аргументы]] файловая_система

Сначала в командной строке друг за другом без пробелов указываются все ключи подряд, БЕЗ знака "минус" перед ними. Затем, через пробел, в том же порядке, что и ключи, указываются аргументы, относящиеся к этим ключам, например:

/usr/sbin/ufsdump 0ufBds /dev/rmt/0n 4194304 62000 1500 /var

Это означает дамп уровня 0 (ключ 0), с обновлением файла /etc/dumpdates (u), на устройство ( f, файл) /dev/rmt/0n, размер тома (т.е. картриджа, кассеты, – В) – 4 194 304 килобайта (т.е 4 гигабайта), плотность записи (d) 62000 бит на дюйм (bit per inch – BPI), длина ленты (s) – 1500 футов. Аргумент файловая_система обязателен, в то время как все остальные аргументы могут быть приняты по умолчанию, а какую именно файловую систему копировать, надо решать Вам. Полагаться на умолчание не рекомендуется: указывайте параметры явно – так надежнее.

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

Если вы настраиваете сеть, в которой работают несколько разных систем UNIX, не забывайте о некоторых отличиях Solaris и других систем. В частности, в версиях FreeBSD 4.х и выше программа dump принимает и вышеописанные ключи, и более стандартную форму ключей (со знаком "минус" и указанием значения параметра сразу после ключа). Таблица 11.2 описывает конвенцию именования файлов устройств стримеров в разных системах UNIX.

В любой системе UNIX каждый ленточный накопитель представлен двумя файлами устройств – с перемоткой ленты в конце записи и без перемотки. Вы можете записать на одну кассету несколько разных файловых систем или несколько последовательных резервных копий одной системы. Для этого надо в качестве устройства для записи указывать файл устройства без перемотки ленты в конце записи. Используйте эту возможность осторожно и всегда записывайте, какие именно файловые системы, в каком порядке и когда были сохранены. Обратите внимание: по умолчанию dump/ufsdum p выбирает устройство с перемоткой.

Названия устройств могут быть другими, в зависимости от типа стримера и его интерфейса (обычно SCSI). Знак решетки ( # ) обозначает номер стримера, начиная с нуля. Вместо решетки в большинстве систем стоит ноль, так как обычно в компьютере устанавливают только один стример.

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

Запись нескольких копий на одну ленту "от бедности" ведет к снижению надежности в несколько раз. Перед восстановлением данных вы можете забыть перемотать ленту и в результате сотрете нужные и еще целые данные вместо потерянных!

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

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

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

Восстановление данных, записанных программой ufsdump, производится командой ufsrestore. Ей можно указать, в какой каталог восстанавливать данные. Это сделано для того, чтобы при необходимости указать новый каталог вместо прежнего, например, при крахе файловой системы.

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

При записи нескольких файловых систем на одну кассету (помните: это не рекомендуется!) на кассете образуется несколько томов (volumes). Так как ни ufsdump, ни restore не умеют искать нужный том, важно знать, как самостоятельно отыскать требуемый том. На кассете должно быть написано вашей рукой (рука вашего ассистента или предшественника тоже подойдет), в каком порядке и что именно на ней записано. Для перемотки ленты до нужного тома надо использовать команду mt.

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

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