Linux: резервное копирование Заметки архивариуса

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

🕛 29.09.2005, 02:33

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

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

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

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

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

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

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

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

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

В качестве префикса при желании можно указать какое-либо мнемоническое имя - дату создания архива, например.

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

Образы готовятся обычным образом (пардон за каламбур) - командой mkisofs, как это многократно описано.

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

Так что запускаем cdrecord (с опцией -eject), указанием параметров записывающего устройства и именем файла образа. Скорость записи (опция 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 по достижении нужного объема. И так - до тех пор, пока изменения не превысят некоего критического размера. После чего - дешевле сделать очередной слепок рабочих файлов, чем разбираться с изменениями...

Все сказанное выше подразумевало запись на обычные CD-R/RW. Однако та же методика применима и для архивирования данных на DVD любого формата. Что, конечно, займет несколько больше времени - но и данных позволит уместить больше.

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