Библиотека Интернет Индустрии I2R.ru

Не шутите с данными – эти шутки глупы и неприличны
Козьма Прутков-эникейщик

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

Тем более, что во все века процесс этот был связан с некоторыми неудобствами. Универсальнейший носитель всех времен и народов (трехдюймовая дискета – вызывает ассоциацию с трехлинейной винтовкой, не правда ли?) очень быстро перестал гармонировать с объемами винчестеров (а вот их – не путать с изобретением оружейника Генри). Всякого рода магнитооптика была (и остается) дорогой абсолютно и относительно (объема). Предельно дешевые по носителям стриммеры – не комфортны в работе (а доступные по цене – еще и малы). Оставалось уповать на развитие техники записи CD-носителей (вернее, удешевление приводов – помните, сколько они стоили в момент появления?).

Года три назад я по случаю написал статью под названием вроде «О причинах, по коим CD-R должны стать стандартным компонентом компьютеров» (кажется, до сих пор лежит на http://www.kulichki.com/~anykey). И вот, кажется, такой момент наступил – по крайней мере, приводы CD-R/RW с вышесредними (мягко говоря) характеристиками стали более чем доступны по цене (во всяком случае, дешевле, чем связка читающего CD и привода Zip, например). Так что же мешает нам ныне стать аккуратистами и завершать день сохранением созданной нетленки так же, как начинаем мы его умыванием?

Да уж больно велики нынче ставки. Диска объемом меньше 20 Гбайт найти трудно, а всякого рода мультимедия с легкостью заполняет его под завязку – не говоря уже о том, что мы ведь иногда и работаем. И для начала ведь придется сохранить всю эту гору нажитого непосильным трудом – о записи ее на CD, пусть даже суперскоростной, нельзя подумать без содрогания: ибо прежде нужно в некоем разумном порядке побить ее на части, кратные объему болванки.

Проблема эта озаботила меня после бесславного крушения двух подряд дисков, использовавшихся как резервные (от того производителя, изделиями коего нынче забиты все гарантийки Москвы и сопредельных стран). Это было не летально – вся текущая работа сохранялась мной на века с появления первого доступного (не по цене – физически, это был внешний односкоростной SCSI Plextor стоимостью то ли 2, то ли 3 штуки ихних денег). Однако перелопатить всю эту груду дисков (суммарный объем сохраненной информации приближался к кубометру) – занятие, повторения которого не пожелаешь собаке классового врага. Результаты размышлений, как избежать этого в дальнейшем, я и предлагаю вашему вниманию.

Итак, стоит задача: в разумные сроки записать на CD около 10 Гбайт разнообразных данных, разместив там в разумном же порядке, дабы время восстановления архива не приняло астрономических масштабов. Имеется: Gentoo Linux, CD-R/RW ASUS 24x10x40, технологическая (100 шт.) упаковка болванок неопределенного генезиса. Ну и прочие мелочи, вроде компьютера с двумя жесткими дисками (один – в 40 Гбайт имени мадам Барракуды IV, и второй, 30-гигабайтный, – той самой фирмы, о которой в связи с винчестерами я больше не хочу говорить).

О подготовке системы к записи говорить не буду – об этом очень хорошо писали (CD-R/RW HOWTO), пишут (например, Федор Сорекс – примеры из его статьи можно прямо тащить мышью в свою командную строку) и будут писать (Алексей Коротков – вскорости в Домашнем компьютере). Скажу только, что я собираю ядро со встроенной (не модульной) поддержкой эмуляции IDE-SCSI, SCSI-устройств вообще, generic SCSI и SCSI CD ROM, а поддержку IDE CD ROM, напротив, искореняю как класс. В итоге (если использовать devfs, при отсутствии оной – за результат не ручаюсь, не пробовал) не требуется ни передавать параметры ядру, ни подгружать модули, нет также и риска потерять после записи CD как читало.

Теперь подготовим данные, подлежащие записи. Самое простое – тупо, в лоб сархивировать их командой tar. Причем, если мультимедия составляет больше половины объема (а обычно так оно и есть), лучше обойтись без сжатия (gzip'ом там или bzip2): поскольку всякие mpeg'и и avi'шки уже сжаты, выигрыш в объеме будет ничтожным, а вот потери времени…

Вторая задача – нарезать получившийся десятигигабайтный тарбалл на куски. Для чего вспоминаем о замечательной команде:

$ split --split --bytes=635m filename.tar [PREFIX]

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

В результате этого мы получим кучу файлов (штук 15-16 на 10 Гбайт) вида [PREFIX]aa, [PREFIX]ab и далее по алфавиту, из которых следует наштамповать образов. Причем, поскольку процесс расщепления 10-гигабайтного файла весьма длителен, ничто не мешает перейти в другую виртуальную консоль и делать это параллельно.

Образы готовятся обычным образом (пардон за каламбур) – командой mkisofs, как описано Федором. Единственно – нет необходимости в опции -J (не под Windows мы все это будем разворачивать), а опция -R, напротив, необходима (по понятным причинам). Ну и никакой мультисессионности, разумеется, не требуется.

Наготовив несколько образов про запас, можно еще в одной консоли запустить и третий процесс – собственно записи. На достаточно мощной машине (и с современным приводом CD-R/RW) никаким опустошением буфера это не грозит, проверено на собственном опыте.

Так что запускаем cdrecord (с опцией -eject), указанием параметров SCSI-устройства и именем файла образа (за подробностями – опять же к Федору). Скорость записи (опция speed) можно смело выставлять максимально доступную для привода: если болванка ее не потянет, процесс записи замедлится автоматически. Так, мои беспородные болванки (судя по цене, не высшего качества) четко писались на скорости x16, каковая время от времени (когда параллельные процессы отъедали много ресурсов – ведь еще даже split не закончился, не говоря уже о создании образов) до x2-x3. Ну а наполнение буфера обычно держалось в диапазоне 70-100% (максимальное падение – 3%).

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

Возникает вопрос: как проверить результаты своей работы? Двояким образом. На этапе созданиям образа диска – его монтирования как loopback-устройства (к Федору). А после записи – обычным образом:

$ mount /mnt/cdrom
$ tar tvf [PREFIX]??

Правда, вслед за этой командой будем получать сообщения об ошибках – что не удивительно, учитывая отсутствие начала и конца tar-файла. Но проследить, что все файлы-каталоги диапазона записаны – более-менее можно. Однако окончательный критерий – практика. То есть: переписываем все содержимое CD-комплекта обратно на диск, сливаем воедино:

$ cat [PREFIX]aa ... [PREFIX]?? > archive.tar

разворачиваем возрожденный тарбалл командой tar и сравниваем его с прародителем (например, через Midnight Commander). С благоприятным (надеюсь) результатом. Времени это также потребует не очень мало – ведь именно это нам придется проделать в случае, если придется восстанавливать данные после краха (от чего – Господь борони). Так что – считаем это отработкой действий в аварийной ситуации…

Вот и все. А дальше жизнь становится прекрасной и удивительной. С должной периодичностью (в гармонии между ленью и необходимостью) командой find (о ней – в серии переводов Станислава Лапшанского) вытаскиваем из нашего дерева каталогов все новые или измененные файлы, командой tar отправляем их в новый архив (можно, при наличии места, дублировать их и в исходный тарбалл), который и записываем на CD по достижении нужного объема. И так – до тех пор, пока изменения не превысят некоего критического размера. После чего – дешевле сделать очередной слепок рабочих файлов, чем разбираться с изменениями…