Как сделать копию диска freebsd
Добавил пользователь Евгений Кузнецов Обновлено: 05.10.2024
По роду деятельности часто уезжаю на неделю-две, оставляя имеющиеся подчиненные сервера с FreeBSD в организации (почтовый сервер с днс, шлюз) на свой страх и риск. Думаю, как бы подстраховаться на случай возможного выхода из строя жесткого диска именно в момент моего продолжительного отсутствия, чтобы оставшиеся администраторы сети могли самостоятельно своими силами восстановить работоспособность данного критичного для функционирования всей организации оборудования. Пока видится возможным делать периодический бэкап всего жесткого диска сервера с FreeBSD посредством Acronis True Image, образ которого в последствии можно было раскатать на такой же по характеристикам новый жесткий диск, тем самым приведя сервер в рабочее состояние, пусть и с данными на момент последнего сделанного бэкапа, не дожидаясь моего возвращения.
Сервера из себя представляют обычные стационарные компьютеры, с единичными жесткими дисками в каждом. А диск как раз и является самым уязвимым звеном в комплексе оборудования. Какие будут соображения в свете написанного?
FreeBSDшника видно издалека, да =).
Что мешает просто всю файловую систему в tar закатать?
Что мешает просто всю файловую систему в tar закатать?
Куда проще именно создание образа жёсткого диска, если возникнет проблема, то любой знающий как развернуть образ сможет легко восстановить систему.
Связаться со мной:
Или устанавливаем из пакетов
Для старых версий freebsd:
Для новых версий:
Затем выключаем тачку, подключаем новый диск и загружаемся. Теперь у нас подключено 2 диска:
Перенести все довольно просто одной командой. Правда процесс довольно длительный(у меня он занял около 12 часов) и если работа ведется по ssh, то запускать лучше в screen. Запустим клонирование диска:
Дожидаемся окончания клонирования, затем отсоединяем старый диск и подсоединяем его на его место новый и пробуем загрузится.
У меня все сразу загрузилось с нового диска без лишних телодвижений. А из старого диска я достал себе прикольный неодимовый магнит, больше он ни на что был не пригоден.
В UNIX системах есть одна очень древняя команда, которая называется dd. Она предназначена для того, чтобы что-то куда-то копировать побайтово. На первый взгляд — ничего выдающегося, но если рассмотреть все возможности этого универсального инструмента, то можно выполнять довольно сложные операции без привлечения дополнительного ПО, например: выполнять резервную копию MBR, создавать дампы данных с различных накопителей, зеркалировать носители информации, восстанавливать из резервной копии данные на носители и многое другое, а, при совмещении возможностей dd и поддержке криптографических алгоритмов ядра Linux, можно даже создавать зашифрованные файлы, содержащие в себе целую файловую систему.
Опять же, в заметке я опишу самые часто используемые примеры использования команды, которые очень облегчают работу в UNIX системах.
Начну с небольшого примера, наглядно иллюстрирующего основные параметры команды:
- if: указывает на источник, т.е. на то, откуда копируем. Указывается файл, который может быть как обычным файлом, так и файлом устройства.
- of: указывает на файл назначения. То же самое, писать можем как в обычный файл, так и напрямую в устройство.
- bs: количество байт, которые будут записаны за раз. Можно представлять этот аргумент как размер куска данные, которые будут записаны или прочитаны, а количество кусков регулируется уже следующим параметром.
- count: как раз то число, которое указывает: сколько кусочков будет скопировано.
Создание образа диска:
Команда будет считывать из устройства данные и записывать в файл до тех пор, пока не достигнет окончания устройства. Если диск битый, можно попробовать его прочитать, игнорируя ошибки чтения:
Если что-то не получается, процесс разбивается на 2 уровня:
Если и так не работает, значит файловая система образа полетела.
Работа с носителями информации
Очень простое, хоть и не оптимальное решение клонирования жесткого диска:
Все то же побайтовой копирование с размером буфера 4 Кб. Минус способа в том, что при любой заполненности разделов копироваться будут все биты, что не выгодно при копировании разделов с маленькой заполненностью. Чтобы уменьшить время копирования при манипуляции с большими объемами данных, можно просто перенести MBR на новый носитель (я ниже опишу как), перечитать таблицу разделов ядра (при помощи того же fdisk), создать файловые системы и просто скопировать файлы (не забыв сохранить права доступа к файлам).
Как вариант, можно даже по расписанию делать бекап раздела по сети. Разрулив ключи ssh будет работать такая схема:
Когда-то читал исследование, согласно которому очень большая доля жестких дисков на барахолке подвергается восстановлению данных без привлечения чего-то специализированного, и содержит конфиденциальную информацию. Чтобы на носителе ничего нельзя было восстановить — можно забить его нулями:
Думаю, понятно на что нужно заменить DEVICE. После проведения лекций по Linux, я очень тщательно стал следить за тем, что пишу.
Проверить можно тем же dd, но преобразовав данные в hex:
Должны посыпаться нули.
Операции с MBR
MBR расположена в первых 512 байтах жесткого диска, и состоит из таблицы разделов, загрузчика и пары доп. байт. Иногда, ее приходится бекапить, восстанавливать и т.д. Бекап выполняется так:
Восстановить можно проще:
Причины этих махинаций с MBR могут быть разные, однако хочу рассказать одну особенность, взятую из опыта: после восстановления давней копии MBR, где один из разделов был ext3, а позже стал FAT и использовался Windows, раздел перестал видиться виндой. Причина — ID раздела, который хранится в MBR. Если UNIX монтирует файловые системы согласно суперблоку, то винды ориентируются на ID разделов из MBR. Поэтому всегда нужно проверять ID разделов при помощи fdisk, особенно если на компьютере есть винды.
Генерация файлов
При помощи dd можно генерировать файлы, а затем использовать их как контейнеры других файловых систем даже в зашифрованном виде. Технология следующая:
При помощи dd создается файл, забитый нулями (случайными числами забивать не рационально: долго и бессмысленно):
Создался файл размером почти в гигабайт. Теперь нужно сделать этот файл блочным устройством и, при этом, пропустить его через механизм шифрования ядра linux. Я выберу алгоритм blowfish. Подгрузка модулей:
Ассоциация образа с блочным устройством со включенным шифрованием:
Команда запросит ввести пароль, который и будет ключем к образу. Если ключ введен не правильно, система не смонтируется. Можно будет заново создать данные в образе, используя новый ключ, но к старым данным доступа не будет.
Создаем файловую систему и монтируем:
Образ готов к записи данных. После завершения работы с ним, нужно не забыть его отмонтировать и отключить от блочного loop устройства:
Теперь шифрованный образ готов.
Команда dump, работает с блочными устройствами и деревом inode, умеет создавать, как полную резервную копию данных, так и инкрементные дампы, до 10 уровней, целого диска или любого, отдельно взятого раздела. Dump работает, даже если файловая система, бэкап которой вам необходимо сделать, в данный момент является "живой", то есть, смонтирована и используется ( как правило, так и есть ), перед копирование делается снимок ( snapshot ) файловой системы, что-бы убедится, что в процессе работы утилиты, не было сделано никаких изменений. Кроме того, команда dump умеет сжимать данные. Dump умеет разделять резервную копию на куски указанной длины или по мере заполнения принимающего устройства.
По-умолчанию, если не было явно назначено место хранения резервной копии, dump создает ее в устройстве для хранения на магнитной ленте. Типичный процесс создания резервной копии данных, может выглядеть следующим образом: В данном примере, с помощью команды dump, делается полная резервная копия ( флаг -0 ), файла устройства /dev/da0s1d, смонтированного в /var, в файл /root/backup.dump. Флаг -L сигнализирует, что раздел, подлежащий резервному копированию, находится на живой файловой системе и перед началом нужно сделать снимок данного раздела и уже затем приступать к операции.
Если флаг -L установлен, dump создает снимок в директории .snap, корневого раздела файловой системы. Файл снимка будет удален, как только dump завершит работу. Всегда используйте данную опцию на живой файловой системе. Если dump с опцией -L применяется к разделу, находящемуся в режиме "только чтение" ( read only ), или к не смонтированному разделу, опция -L будет проигнорирована.
Опция -а, означает "auto-size", то есть будет заполнено все cвободное место на носителе Опция -u, указывает сохранить ( обновить ) служебную информацию в файл /etc/dumpdates, она будет использована при следующих бэкапах: Для создания инкрементного архива, вам нужно указать в опциях команды, уровень дампа от 1 до 9 ( 0 - полный архив ), при этом, dump будет использовать данные о времени последнего резервного копирования из файла /etc/dumpdates. Выглядит это следующим образом: В результате, также будет обновлена информация в файл /etc/dumpdates: Создав резервную копию файловой системы, желательно переместить файл дампа в более безопасное место, например на, специально предназначенный для этого, сервер бэкапов, что-бы избежать потери уже сохраненных данных в случае аппаратного сбоя, или можно сразу создать резервную копию с сохранением на удаленный сервер, через безопасное SSH соединение. Делается это следующим образом: В результате будет создана полная резервная копия ( -0 ) устройства da0s1d и отправлена на удаленный сервер backup_server с именем пользователя backup. Для сжатия будет использован bzip2 ( архиватор можно использовать, какой вам больше нравится, gzip, compress ), что-бы уменьшить трафик, далее команда dd примет входной поток и отправит его в файл /root/vds-admin.dump. Полный вывод проделанной операции, выглядит так:
При использовании архиватора compress, значительно снижается нагрузка на сеть, но ценой повышенной нагрузки на процессор.
Команда restore, выполняет восстановление данных, из сохраненных ранее, программой dump, резервных копий. Например можно восстановить из резервной копии данных, удаленный по неосторожности, файл. Как и dump, Restore можно использовать для восстановления файлов по сети. Обычный сценарий для команды restore, восстановление из резервной копии на пустой раздел, отформатированный с помощью утилиты newfs. Сначала восстанавливается полная резервная копия, после чего можно восстанавливать инкрементные архивы, в порядке их создания. Вышеописанная процедура выглядит примерно следующим образом: В данном примере, команда restore восстановит резервную копию данных /usr/dumpfile, в текущую директорию, перейти в нужную директорию можно с помощью команды cd. Еще одна замечательная особенность команды restore, это возможность работы в интерактивном режиме, то есть вы можете просматривать содержимое резервной копии данных, листать файлы и директории, помечать необходимое для восстановления. Эта возможность просто незаменима при восстановлении файлов, удаленных по ошибке. В интерактивной оболочке восстановления, присутствует достаточно команд, обеспечивающих вполне комфортную навигацию по содержимому дампа и выбора нужных файлов для восстановления. Команды ls, cd, pwd, являются эквивалентами команд из обычной оболочки и используются для навигации по резервной копии данных. Используя команды add и delete, можно выделять файлы и директории для последующего восстановления. После того как необходимые данные выделены, можно использовать команду extract, для их восстановления. Выглядит этот процесс примерно следующим образом: Также при использовании интерактивного режима команды restore, для восстановления резервной копии данных из дампа, можно воспользоваться командой what Вот собственно и все. Не забудьте полистать соответствующие страницы man руководства, там все довольно подробно расписано. Удачных бэкапов.
Читайте также: