Резервное копирование
Архивы, как правило, создаются для целей резервного копирования - то есть записи их на какой-либо внешний носитель. В качестве последних в настоящее время практически могут рассматриваться только внешние винчестеры и оптические диски (CD-R/RW и записываемые DVD разных форматов). И потому способы обращения с ними резонно рассмотреть тут же, в интермедии о файловых операциях.
Можно выделить два основных способа резервного копирования - создание точных слепков файловой системы или отдельных ее фрагментов, и запись архивов. Первый способ применяется, например, при переносе системы с одного носителя на другой, второй же - для сохранения данных на внешних носителях.
Обычный способ переноса файловых систем - классическая утилита dd, описанная в одном из предыдущих параграфов. Для использования ее в этом качестве достаточно указать файл устройства - источника и файл целевого устройства. Например, директива
$ dd if=/dev/ad0s1a of=/dev/ar0s1a
воспроизведет корневую файловую систему дискового раздела, указанного в качестве первого аргумента, на разделе второго диска. При этом нужно учитывать, что каталоги корневой файловой системы, представляющие точки монтирования самостоятельных файловых систем на отдельных разделах (такими обычно являются /usr, var, /home и так далее), затронуты не будут: для их реплицирования на другом носителе команду dd придется повторить с указанием соответствующих источников и целевых устройств.
Важно также, что команда dd не требует ни предварительного создания файловой системы на целевом носителе, ни его монтирования. Ибо механизм ее работы - поблочный перенос всего содержимого устройства-источника на устройство-цель.
В BSD-системах та же задача может быть решена с помощью команды cpdup, также упоминавшейся ранее. Правда, она требует предварительного создания разделов на целевом носителе, файловых систем на разделах и их монтирования в структуру текущей коревой файловой системы. Вот как используется cpdup при ручной установке ОС DragonFlyBSD (без помощи программы BSD Installer, описанной в соответствующей статье цикла об этой ОС):
$ cpdup / /mnt $ cpdup /var /mnt/var $ cpdup /etc /mnt/etc $ cpdup /dev /mnt/dev $ cpdup /usr /mnt/usr
Здесь каталоги /, /var и так далее - точки монтирования корня и отдельных его ветвей файловой системы установочного LiveCD, а /mnt, /mnt/var - заблаговременно созданные, отформатированные и смонтированные разделы на винчестере, на который инсталлируется DragonFlyBSD.
Если потребность в точном реплицировании файловых систем возникает не так уж и часто, то сохранение архивов данных - процедура достаточно регулярная (по крайней мере, должна ею быть). И наиболее распространенными носителями для архивов ныне являются CD-R/RW диски, процедуру записи которых я и рассмотрю далее. Конечно, записывающие DVD-устройства приобретают все большую популярность, однако этот вопрос я оставляю для изучения любопытными читателями, ибо у меня таких устройств нет и опыта общения с ними я не имею.
Мне известно два инструмента для записи CD-дисков: кросс-платформенный комплект cdrtools и утилита burncd, используемая только в BSD-системах. Первый к настоящему времени не описал только ленивый. А вот утилита burncd известна относительно мало, и по причинам, которые станут ясными несколько позже, заслуживает подробного рассмотрения.
Подобно большинству исконных BSD-инструментов, использование burncd для записи дисков - дело не простое, а очень простое. И требует оно только наличия записывающего привода с ATAPI-интерфейсом. При этом нет необходимости ни в каких специфических настройках типа включения эмуляции SCSI через IDE (без чего до недавнего времени было не обойтись в Linux при использовании cdrtools).
Правда, обычно запись CD-диска начинается с создания его образа. Для чего требуется программа mkisofs из все того же пакета cdrtools. Хотя во FreeBSD и DragonFlyBSD она доступна в качестве самостоятельного порта или автономного бинарника, не требующего установки прочих компонентов оригинального пакета. Собственно создание образа происходит так:
$ mkisofs -R -J -o name.iso path2data
Здесь опция -R обеспечивает поддержку расширения стандарта ISO9660 - Rock Ridge для Unix-систем (длинные имена, множественные точки в именах файлов, сохранение атрибутов доступа и принадлежности файлов и каталогов).
Опция -J - это поддержка расширения Jouliet для систем семейства Windows (то есть длинные имена файлов будут видны и там). Опция -o имеет своим значением имя файла создаваемого iso-образа. Ну а path2data - путь к каталогу, из содержимого которого будет создаваться образ.
Непосредственно запись диска выполняется BSD-утилитой burncd. Например, это можно сделать такой командой:
$ burncd -e -s max -f /dev/acd0 data iso_name fixate
Значения опций - следующие:
Команда fixate указывает на фиксирование сессии (подразумевается односессионная запись). Ну а data предписывает запись диска с данными (а не аудиоCD) с образа name.iso.
У burncd есть еще несколько опций, с которыми можно ознакомиться посредством
$ man 8 burncd
В частности, полезной может быть опция -v, выводящая информацию о ходе записи. А опция -t осуществит имитацию записи, что позволяет в случае ошибки избежать порчи "болванки".
Для стирания CD-RW в burncd предусмотрены команды blank (быстрая очистка оглавления диска) и erase (полная очистка диска): $ burncd -e -f /dev/acd0 blank
или $ burncd -e -f /dev/acd0 erase
соответственно. Нужно только помнить, что вторая операция может занять много времени - столько же, сколько и запись).
Если для целей чисто резервного копирования (например, архива вида *.tar.gz) не требуется запись дисков, доступных из других операционок, burncd можно использовать и без предварительного создания iso-образа (и, соответственно, без пакета mkisofs). Все, что для этого нужно (помимо заблаговременно созданного архива подходящего размера) - директива примерно такого вида:
$ burncd -f /dev/acd1c -s max data archive.tar.gz fixate
Правда, записанный таким образом диск не может быть ни прочитан в каких-либо других операционках, ни смонтирован как обычный CD - доступ к нему потребует прямого обращения к файлу соответствующего устройства, например:
$ tar xzvf /dev/acd1c
Однако выполнить запись такого рода гораздо быстрее. Особенно значителен выигрыш во времени при записи очень большого массива данных. В этом случае их можно собрать в единый тарбалл, утилитой split разбить на фрагменты подходящего размера:
$ split --split --bytes=650m archive.tar.gz [PREFIX]
где в качестве префикса можно указать какое-либо мнемонически полезное значение (дату создания архива, например), после чего последовательно записать кучу образовавшихся файлов (имеющих вид [PREFIX]aa, [PREFIX]ab, и так далее) почти так же, как было сказано выше:
$ burncd -f /dev/acd1c -s max data [PREFIX]?? fixate
Восстановление данных из такого архива выполняется следующим образом. Сначала содержимое полученной стопки дисков последовательно копируется в файлы на винчестере:
$ cp /dev/acd1c path2/file#
Затем они сливаются утилитой cat в единый архив:
$ cat file1 ... file# > archive.tar.gz
который и разворачивается обычным образом.
Возможность применения burncd для резервного копирования без предварительного создания iso-образов определяет, по моему мнению, ее предпочтительность перед cdrecord. Однако на ее использование накладывается несколько ограничений. Во-первых, как я уже сказал, она существует только в BSD-системах - и это, конечно, главное. Во-вторых, она работает только с ATAPI-приводами. И если вероятностью наличия в пользовательской машине CD-R/RW со SCSI-интерфейсом можно пренебречь, то записывающие USB-устройства получают все большее распространение - а перед POSIX-системой последние предстанут в виде SCSI CD ROM. И наконец, с некоторыми моделями даже ATAPI CD ROM burncd отказывается работать категорически (правда, мне встречался один-единственный такой привод, и то уже давно).
Тем не менее, любое из вышеприведенных ограничений может быть причиной обращения к утилите cdrecord из пакета cdrtools. Как уже говорилось, это - кросс-платформенный инструмент, который может быть собран в любом Unix.
До недавнего времени cdrecord напрямую мог работать только со SCSI-приводами, практически не встречающимися в пользовательских машинах.
Что при наличии обычного ATAPI CD-R/RW требовало некоторых ухищрений - включения эмуляции SCSI через IDE в Linux или использования модуля ATAPI/CAM в BSD. Разумеется, это не возбраняется и поныне, однако проще воспользоваться возможностью последних версий cdrecord общаться с ATAPI-приводами напрямую, что и будет предметом последующего рассказа (тем более что, повторяю, работа с cdrecord при эмуляции SCSI через IDE была многократно описана ранее).
Дополнительный плюс отказа от эмуляции SCSI для CD-привода (особенно если он выступает как "читало" и "писало" в одном лице) - возможность включения для него DMA-режима, что существенно ускоряет скорость как записи, так и (особенно) чтения компакт-дисков.
Запись дисков посредством cdrecord, в отличие от burncd, требует обязательного создания iso-образа. Благо, соответствующая утилита - mkisofs, - входит в состав пакета, а сам процесс выполняется точно так же, как было описано выше.
Далее, cdrecord сохранила некоторые реликты своего SCSI-происхождения. И ATAPI-устройство, на которое она записывает, все равно должно иметь номер SCSI-облика (вида dev=#,#,#). Он определяется командой
$ cdrecord -scanbus dev=ATAPI:
вывод которой должен выглядеть примерно так:
Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 JЖrg Schilling scsidev: 'ATAPI:' devname: 'ATAPI' scsibus: -1 target: -1 lun: -1 Warning: Using ATA Packet interface. Warning: The related libscg interface code is in pre alpha. Warning: There may be fatal problems. Using libscg version 'schily-0.7' scsibus0: 0,0,0 0) 'TEAC ' 'CD-W540E ' '1.0C' Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) *
Обращаем внимание на цифры 0,0,0 в первой строке (понятно, что они, как и фирменное погоняло привода, могут варьировать) - именно они будут фигурировать далее в опциях cdrecord наряду с именем протокола (в виде dev=ATAPI:0,0,0). Логики в этом немного - особенно если задуматься над смыслов трех сакраментальных цифр, которые определяют положение устройства на SCSI-шине (!).
Но пакет cdrtools вообще не в ладах с достижениями мысли товарища Аристотеля, поэтому просто запоминаем их.
Дальше все просто. Легко догадаться, что для записи диска программа cdrecord потребует минимум двух аргументов: имени устройства и имени файла iso-образа:
$ cdrecord dev=ATAPI:0,0,0 name.iso
Как обычно, в дополнительных опциях нас никто не ограничивает. В частности, можно задать опцию -speed=#, где в качестве значения # выступит желаемая скорость записи. Но можно этого и не делать: без явного указания скорости cdrecord будет писать максимально быстро - насколько это возможно для данных привода и "болванки". Так что интересней будет дать опцию -v (от обычного verbose), которая обеспечит нас подробной информацией о ходе записи (в том числе о таких параметрах, как максимальная, минимальная и средняя скорость записи, процент заполнения буфера, и т.д.).
Еще одна невредная опция - -eject, она предписывает выдвигать лоток с болванкой по окончании записи. В финале команда для записи созданного образа приобретает такой вид:
$ cdrecord -v -eject [-speed=12] dev=ATAPI:0,0,0 name.iso
Отступление по поводу опции speed (или ее отсутствия). Как-то мне пришлось иметь дело с пачкой технологических болванок производства всемирно известной фирмы noname, теоретическая скорость записи на которые на упаковке была обозначена как x12. И поначалу я честно указывал эту цифру в качестве значения опции speed. А потом мне это надоело, и я решил проверить, что же будет без нее. Оказалось, что соседние болванки из пачки отличаются по своим характеристикам на пол-порядка: они с равной вероятностью записывались как на 4-х так и на 24-х скоростях (причем и в последнем случае - без ошибок!).
Особенно же интересно оказалось с перезаписываемыми дисками (CD-RW). Причем уже - коробочными, и от именитых производителей, на которых я не буду указывать пальцем (дабы других не обидеть - наверняка у тех то же самое): скорость записи, обозначенная на этикетке бокса, выдерживалась только при первой записи.
Уже при второй перезаписи она падал обычно в полтора-два раза, а при последующих - в арифметической как минимум прогрессии.
Раз уж речь зашла о перезаписи, не лишне вспомнить, как к ней подготовиться (то есть - ослобонить болванку от записанного ранее). Делается это той же командой cdrecord, но с опцией blank=значение, каковое может быть fast (быстрая очистка, при которой стирается оглавление без физического уничтожения данных) или all (полная очистка диска, которая занимает ровно столько же времени, сколько и его запись на всю катушку).
До сих пор речь шла о записи диска "в один присест". Однако никто этого делать не заставляет - мы ведь знаем, что бывает т.н. мультисессионая запись - это если данных на полный CD сразу не накопилось. В этом случае создаем образ диска, как описано выше (объемом хоть в 10 Мбайт - только помним, что на каждую сессию, вне зависимости от количества записанной информации, этого самого объема некоторое количество теряется), и записываем точно также, добавив лишь опцию -multi:
$ cdrecord -v -eject -multi [-speed=#] dev=ATAPI:0,0,0 name1.iso
А вот со следующими сессиями нужно быть повнимательней. Во-первых, команда mkisofs в этом случае потребует опции -C (очевидно, от continue). Очевидно, что уже на стадии создания образа для второй сессии (и всех последующих) требуется информация, а где же завершилась предыдущая? Правда, получить ее просто - заранее вставив бывшую в употреблении недописанную болванку, даем команду
$ cdrecord -msinfo dev=ATAPI:0,0,0
которая выдаст нам последний использованный в прошлой сессии трэк - некое число ###, которое и подставим в командную строку в качестве значения опции -C.
Далее, команде mkisofs требуется сообщить еще и имя устройства, на котором этот трэк был записан. Для чего предназначена опция -M. А вот значением ее будет (внимание!) не трехзначный номер устройства, полученный при выводе команды cdrecord -scanbus, как можно было бы ожидать, а просто имя файла устройства (где ты, дяденька Аристотель?) - типа /dev/cdroms/cdrom (или как он точно обозначается в данной системе).
В итоге команда mkisofs для создания образа второй и последующих сессий приобретет вид:
$ mkisofs -R -J -C ### -M /dev/cdroms/cdrom -o name2.iso /path2data
А вот записывается этот образ самым обычным образом:
$ cdrecord -v -eject [-multi] [-speed=#] dev=ATAPI:0,0,0 name2.iso
Причем, насколько я понял, даже опция -multi в этом случае не обязательна.
К слову сказать, любой - и односессионный, и мультисессионный, - образ диска может быть проверен. В Linux для этого он должен быть подмонтирован как loopback-устройство (что требует соответствующей поддержке в ядре - но таковая обычно, в виде модуля, в прекомпилированных ядрах большинства дистрибутивов имеется):
$ mount -o loop name.iso /mnt_point
После чего содержимое каталога /mnt_point просматривается обычным образом.
Как я говорил, программа cdrecord не позволяет обойтись без создания iso-образа. Однако, если нет намерения оный проверять (ведь POSIX'ивист, как и сапер, не ошибается), никто не обязывает его записывать на диск: те, кто числит себя среди "инженерных Её Величества войск, с содержаньем и в чине сапера", могут перенаправить вывод команды mkisofs по конвейеру прямо на ввод cdrecord:
$ mkisofs -R -J /path2data | cdrecord dev=ATAPI:0,1,0 -
И, наконец, последнее о cdrtools: этот пакет позволяет использовать многочисленные его фронт-энды для графического режима, из которых самым удобным мне представляется пакет k3b для интегрированной среды KDE.
