трудных путей не ищем! резервное копирование Linux- системы с помощью dd

О пользе резервного копирования, равно как и о конкретных методах его выполнения написано уже столько, что не дошло, наверное, только до полного... нет, я даже не знаю, как его назвать ;)
Однако, заметьте, что пишут чаще всего о бэкапе пользовательских данных (сюда же можно отнести корпоративные базы данных и прочие бизнес-решения) или некоторых критических частей системы (например, каталога пользователей). Но что делать, если сама система (здесь и далее под «системой» я понимаю собсвенно ОС + необходимый софт) по каким-то причинам «дошла до ручки», причем в такой жестокой степени, что найти и устранить проблему настолько же сложно, как и тупо переставить все заново.

background

...Вообще-то при желании я могу достаточно быстро переставить систему, но ключевые слова здесь – «достаточно» и «желание» :))
Что значит «достаточно быстро»? Даже с учетом минимального набора софта (например, на Linux-маршрутизаторе) займет это ну никак не меньше 15 минут, это при условии, что операция пройдет совсем без глюков, на могучем железе и выполнена будет абсолютно ровными руками. Но вы сами понимаете, что даже 15-минутный даунтайм допустим далеко не во всех информационных системах: что SOHO хорошо, то банку смерть! – перефразируем мы известную поговорку.
Что касается «желаний», то у хорошего админа вообще редко возникает желание работать, а я имею наглость считать себя именно таким админом :)
Не стоит упускать из виду и опасность забыть что-то с виду малозначимое (ротацию логов учета трафика или скрипт поднятия dialin-сервера в ночное время), затем получить по этому поводу нагоняй от начальства и в мрачном настроении приступать к внеурочной работе по устранению глюков.
К чему это я клоню? А к тому, что на мой взгляд идеальная бэкап-система для бекапа системы (какая знатная тавтология, huh? :) должна отвечать следующим требованиям:
1. Быстрота развертывания системы из копий: чем быстрее, тем лучше.
2. Полнота: чем меньше доработок нам придется сделать после развертывания системы из копии, тем лучше.
3. Трудоемкость процесса копирования: чем проще, тем лучше.
Пошарившись немного по бескрайним просторам Googl’а, я составила представление о том, как ЭТО приспособились делать другие люди. Самый курьезный документ, который мне попался на глаза, содержал пошаговую инструкцию из 15 (пятнадцати) шагов! Как мне показалось, степень трудоемкости описанного солюшна превышала процесс чистовой установки раза в три. Не буду перечислять все описанные там ходы, любопытствующие могут ознакомиться с докой вот по этому адресу:http://gennadi.dyn.ee/modules.php?name=Forums&file=viewtopic&t=12.
В защиту автора этого эпохального документа можно сказать только то, что его метод предполагает возможность развертывания системы на новом железе. Впрочем, метод, который я предлагаю в этой статье как оптимальный, сработает и при апгрейде (если вы только не планируете совсем уж радикальный апгрейд, скажем с Intel-платформы на ATARI ST :) Причем траблшутинг (пересборка ядра и/или подключение нужных модулей) займет намного меньше времени, чем выполнение описанных 15 шагов.
ОК, закончим напокамест с лирикой и перейдем к практической части повествования.
Итак, по моему скромному, но упертому мнению, наилучший способ резервного копирования Linux-системы (и не только, кстати, Linux) – это копирование содержимого диска с установленной системой (один в один) на другой диск. И при возникновении внештатной ситуации подключение диска с резервной копией вместо проблемного.
Делать это (в смысле копирование, а не восстановление ;) можно достаточно редко: после каждого серьезного изменения в системе (я так понимаю, что вы – хороший админ, и не мучаете ваши серверы и маршрутизаторы ежедневными апдейтами?).
Естественно, это не освобождает вас от необходимости регулярно делать резервные копии пользовательских данных или других более-менее ценных файлов, но это уже совсем другой разговор, а наша задача сегодня – научиться быстро развернуть систему после аварии.

solution

В Linux есть чудесный инструмент, способный помочь нам в решении поставленной задачи. Это – утилита dd, входящая в состав большинства (если не всех) современных дистрибутивов, поскольку является частью набора утилит GNU coreutils. И во всех этих дистрибутивах coreutils устанавливаются чуть ли не насильно, так что 99% вероятности, что в вашей системе эта утилита есть. Если вдруг вы умудрились ее не установить, то дело всегда можно исправить: идите наhttp://ftp.gnu.org/pub/gnu/coreutils/, качайте и устанавливайте.
dd – это программа низкоуровневого копирования данных - блок за блоком. Вот выдержка из manpage по этой программе: «dd копирует файл (по умолчанию из стандартного ввода на стандартный вывод), используя заданные размеры блоков для ввода и вывода, и в то же время, возможно, выполняя его преобразование.»
Упоминание в man слова «файл» несколько сбивает с толка начинающих пользователей и администраторов Linux, однако, как верно заметил в своей статье по сокетному программированию в *nix mend0za, все есть файл. Файл может быть физическим устройством, сокетом, каналом, каталогом, текстовым файлом...
И именно этим замечательным свойством *nix вообще, и утилиты dd в частности, мы и воспользуемся, чтобы копировать диск с нашей системой один в один на другой диск.
Итак, помимо прочих, dd принимает два ключа-параметра: if=<file> и of=<file>, где первый обозначает файл, из которого читают (if = input file), а второй – файл, в который пишут (of = output file). Например, команда

dd if=a.img of=/dev/floppy

переписывает образ дискеты на, собственно говоря, дискету. Так создаются, например, загрузочные дискеты.
В нашем случае «образом» будет файл устройства, обозначающий наш рабочий диск с системой, а пунктом назначения – файл устройства диска для бэкапов. Например:

dd if=/dev/hda of=/dev/hdb

Разъяснения, думаю, излишни :)
В народе ходят упорные слухи, что для корректного выполнения такой операции винчестеры с/на которых/е копируются данные, должны быть полностью идентичны, или, по крайней мере, иметь одинаковый размер. Не верьте слухам: ничего фатального не случится, если вы возьмете /dev/hdb большего, чем /dev/hda, размера. Единственное, что вообще случится – на винчестере-копии в конце останется пустой «хвост», который можно оставить как есть. Наверное, на нем даже можно будет создать еще один раздел, только вот не совсем понятно зачем?
Конечно, вы можете подойти к процессу творчески: скажем, копировать не диск целиком, а каждый раздел по отдельности, но в таком случае на бэкап-диске придется создать все нужные разделы. Имеет это смысл только в одном случае: если на том же физическом диске, что и система, расположен большой раздел с пользовательскими данными, которые вы приспособились бэкапить другим, наверняка более подходящим, чем низкоуровневое копирование, способом.

pro et contra

О достоинствах вышеописанного метода вскользь было упомянуто в самом начале статьи (приметы хорошей бэкап-системы), но для тех, кто еще не вылез из бронетехники или наоборот, от написанного мной в ужасе в нее залез, позволю себе повториться. Итак, достоинства:
1. Быстрота развертывания системы из бэкапа:ограничена только ловкостью рук обслуживающего персонала. Все, что нужно сделать (по максимуму) – это залезть в серверный шкаф, открыть корпус сервера, подцепить диск с бэкапом на нужный IDE/SCSII-канал и запустить сервер.
Диск с бэкапом, кстати, можно не доставать из сервера вовсе (это еще больше убыстрит процесс развертывания), но желательно его отключать по окончании процесса копирования – зачем нам лишний источник тепловой энергии? Последнее замечание справедливо только в том случае, если вы планируете запускать бэкап вручную (подробнее см. пункт 3).
2. Полнота резервной копии:вы имеете на 100% полную копию вашей системы.
3. Простота процедуры копирования:вам нужно выполнить только одну комманду (см. выше). Можно даже повесить ее в cron для регулярного выполнения, хотя тут есть свои подводные камни. Я лично предпочитаю произвести бэкап вручную, дабы быть уверенной, что полученная копия содержит образ системы «в ее лучшие времена»: мало ли что может произойти в системе за пару минут до выполнения бэкапа по расписанию! Всякое бывает, не мне вам рассказывать...
Теперь честно перечислю некоторые недостатки оисанного метода:
1. Скорость процесса копирования:откровенно говоря, очень низкая. Также не забывайте, что мы копируем весь диск, а не только файлы системы, так что чем больше размер физического диска, тем дольше dd будет «колбасить», исправно переписывая как данные, так и пустоту с одного диска на другой. И именно с этим недостатком связана моя рекомендация предпочесть копирование разделов в случае, если система – это только небольшая часть хранящихся на физическом диске данных.
2. Вероятность повреждения некоторой части информации.В идеале процесс dd-бэкапа должен проходить при отсутствии какой-бы то ни было посторонней дисковой активности. Если же в процессе бэкапа на исходный диск что-то пишется (в случае с маршрутизатором/шлюзом это могут быть логи, файлы кэша squid), то есть шанс, что целостность данных может нарушиться. Однако не пугайтесь, ничего фатального, с чем не мог бы справиться банальный fsck, произойти не должно. В конце концов, никто не мешает вам проверить «на вшивость» ваш свежесозданный бэкап.
Если совсем паранойя заела: проводите копирование на «обездвиженной» системе: остановите все склонные к дисковой активности сервисы и вперед, но помните, даже на скромненьких на сегодняшний день 30 Гигабайтных винчестерах dd будет отрабатывать минут 40-60 (зависит от скорости чтения-записи конкретных моделей HDD). В таком случае единственная возможность избежать позора в виде внеплановго часового простоя – приурочить процесс резервного копирования к плановым профилактическим работам, где время не играет такую уж большую роль.
Итого:два чахлых минуса против трех жирных, весомых плюсов ;)
Впрочем, не стоит забывать, что окончательное решение о том, использовать или нет ту или иную технологию, мы всегда принимаем исходя из реалий нашей конкретной ситуации. Может быть то, что не важно для меня и многих других моих коллег, вдруг окажется критичным для какого-то конкретного окружения. Скажем, для кого-то скорость копирования является решающим фактором, и тут уж ничего не поделаешь. Так что я вам свое IMHO высказала, а решать, как, что и куда бэкапить, ясное дело, вам придется самим :)
Но то, что бэкапить надо – в этом уж у вас никаких сомнений быть не должно!

Alice D. Saemon, sr [at] nestormedia [dot] com.

P.S.:существует в природе и windows-версия dd, причем даже в нескольких лицах: мне удалось найти три порта dd под win32, два из которых – native windows apps и один под cygwin.
Если кто-то из вас уже имел дело с одним из портов dd под Windows, и в частности – использовал его для бэкапа системы, напишите, пожалуйста, пару слов о том, как ЭТО было, и мы с удовольствием опубликуем вашу заметку в СР.
P.P.S.:другие замечания, дополнения, примечания, комментарии и.т.п. также приветствуются.