---
title: Система резервного копирования и быстрого развёртывания ОС - Clonezilla
tags: software
---
Clonezilla - проект по созданию свободной системы резервного копирования, клонирования, восстановления и массового развертывания операционных систем и данных. Позиционируется как аналог и замена для Norton Ghost (упомянуто на оффсайте). Также, многие её возможности повторяют, а кое-в чем и обгоняют аналогичные проприетарные решения от Paragon и Acronis.
Изначально, эта статья планировалась как обзор, где подробно разбирались бы возможности, отличия от конкурентов, но, поскольку это невыразимо скучно, я решил углубиться в общие принципы работы самой идеи развертывания систем вместо их установки заново.
---
Возможности
-----------
Поддержка файловых систем:
* FAT,
* NTFS,
* ext{2,3,4},
* reiserfs{3,4},
* XFS,
* JFS,
* VMFS (VMWare ESX)
* UFS, (*BSD)
* HFS+, (Mac)
* все остальные (посекторно, с помощью dd)
Сравнение с аналогами
---------------------
^ Основные параметры ^ Clonezilla ^ Paragon ^ Acronis ^
^ требования к памяти | 128-256m | 512 | 160m |
^ графический интерфейс | нет | да | да |
^ интеграция в другие продукты | да | нет | нет |
^ live-система основана | linux | vista | linux |
^ изменяемость live-системы | да | нет | нет |
^ Поддерживается загрузка с ^ Clonezilla ^ Paragon ^ Acronis ^
^ * cd/dvd | да | да | да |
^ * usb | да | нет | да (хак) |
^ * pxe (по сети) | да | нет | да (хак) |
^ Сохранение образов дисков ^ Clonezilla ^ Paragon ^ Acronis ^
^ локальное устройство | + | + | + |
^ smb (cifs) | + | + | + |
^ nfs | + | - | ?? |
^ ssh | + | - | - |
^ ftp | ~ | ?? | + |
^ (unix-supported) | ~ | - | - |
^ Дополнительные "возможности" ^ Clonezilla ^ Paragon ^ Acronis ^
^ головняк с версиями лицензий | нет | ?? | да |
^ красивый сайт с тонной рекламных лозунгов | нет | да | да |
Ограничения
-----------
Ограничений достаточно много, большая часть - из-за недостаточной гибкости интерфейса. Там описаны только типовые операции, для нестандартных случаев - готовьтесь принять управление на себя и использовать консоль.
Чисто технические ограничения:
* поддержка восстановления только на раздел, больший или равный исходному. (это всё равно можно переопределить, но правильность восстановления в этом случае - не гарантируется)
* нет возможности работать с данными внутри образа, даже несжатого[^fn1]
Всё остальное - ограничения чисто интерфейса, например:
* нет возможности отдельно настроить опции бэкапа для отдельных разделов, приходится полагаться на автоматику
* начальная поддержка LVM, опять же, нет возможности бэкапить отдельные тома
* разделение на «образы дисков» и «образы разделов». (отличие - в одном файле)
* программа "видит" образы только в корневой директории примонтированного хранилища
* и т.д.
Применимость
------------
Смысл в изучении и использовании системы появляется при:
* частом выполнении операции развертывания системы
* большом парке обслуживаемой техники
* неприемлемости/невозможности использования платных аналогов
* необходимости гарантии максимально полного восстановления данных из бэкапа даже при его повреждении
Для типичного win-эникейщика с руками достаточной кучерявости - вещь практически неподъёмная или очень ограниченная в возможностях, поскольку с консолью он работать не умеет, а интерфейс позволяет только типовые операции. Тем не менее, при желании учиться, освоение системы займет от 3 дней (базовый уровень) - до месяца (поскольку потребуется объяснять, что на самом-то деле нет такого понятия как "буквы дисков").
Для линуксоида с хотя бы полугодовым опытом и базовыми навыками работы в консоли, обучение займет от одного до 5и дней до появления т.н. «чувства системы». После прочтения данного материала - смею надеяться - ещё меньше.
Необходимый уровень знаний - на уровне
* записать N байт из заданного смещения многогигабайтного файла по заданному смещению на диске,
* настроить сеть из консоли,
* редактирование mbr fdisk'ом и понимание отличия между сектором и цилиндром диска
* не промахнуться мимо нужного диска/раздела
Особенности клонирования
------------------------
Вещи, на которые стоит обратить внимание при массовом развертывании систем.
**nix**:
* ssh-ключи
* ip-адрес и настройки сети (неактуально для dhcp)
* hostname
* UUID дисков
* имена и uid пользователей, если используется авторизация на локальной машине
* имена групп lvm
* имена сетевых интерфейсов (для случая, когда их больше одного)
Первые 3 - рекомендованы к изменению, остальные - по желанию.
**win**:
* SID машины и пользователей
* netbios-имя
* настройки сети
SID, судя по статье Руссиновича, менять необязательно, но рекомендовано. NB-имя - менять обязательно, если машины будут работать в одной сети, иначе получите гарантированные глюки и медленную работу win-сети.
Подготовка систем к развертыванию
---------------------------------
Иначе говоря - создание образов установленных и настроенных систем.
Общий принцип - старайтесь всегда отделять пользовательские данные от системных, это значительно сэкономит время на бэкапы и упростит развертывание ОС и замену комплектующих.
Также, старайтесь делать образы дисков минимального размера - это автоматически обходит ограничения clonezilla на невозможность развертывания образа на меньший по размеру раздел диска и экономит время на развертывание за счет передачи меньшего объема данных.
Разметка дисков
---------------
**nix**:
Здесь всё просто - выделяется 100Мб раздел под «/boot», выделяется второй раздел под всё остальное (рекомендуемый объем для работы системы).
Первый раздел нужен, чтобы использовать lvm на втором, поскольку поддержку его в самом загрузчике имеет только grub2. Кроме того, так проще будет проводить исправление проблем с загрузчиком и редактирование его конфигурации. Рекомендуемый размер - 70-150Мб
Второй раздел полностью отводится под физический том lvm и уже в нём динамически выделяется место под различные нужды. Рекомендуемый размер - 4-8 Гб, в зависимости от ДЕ, дистрибутива и количества софта. Этот раздел должен использоваться для работы системы, хранение на нем пользовательских данных - крайне нежелательно.
Для себя я определил такую схему логических томов:
* tmp - 256-512 Мб, noexec,nodev,nosuid. Этот раздел можно впоследствии выделить целиком в оперативной памяти, а логический том - удалить.
* home - 512Мб, relatime, по желанию - noexec
* swap - 256-1024Мб
* root - всё остальное
Почему именно так: конечно, будучи бывалым гуру, вы бы выделили /var/log и /var/run в память, возможно разбили бы /usr ещё на несколько разделов. Но здесь основная задача - чтобы система проработала максимально долго без внешнего вмешательства. И чтобы когда её принесли с диагнозом "не работает, хз почему" - можно было бы максимально быстро установить по логам что именно случилось. Ситуации «в разделе с логами кончилось место, поэтому всё поотваливалось» - недопустимы.
Небольшой раздел с «/home» - это своего рода заглушка, для демонстрации работы системы, в дальнейшем этот раздел переносится на другой, более вместительный, а место - возвращается под системные нужды. В случае, когда *nix используется второй системой - он не удаляется, но в домашнюю директорию монтируется раздел с данными (не поверх, а отдельно и на видном месте).
Итоговая разбивка диска будет такой:
[boot][XXXXXXXXXXXXXX LVM XXXXXXXXXXXXXXXX]
^ ^
[[tmp][swap][ root ][home]]
На реальный диск это может быть развернуто так:
[boot][XXX LVM XXX][ data ]
или так:
[system1][ data ][boot][XXX LVM XXX]
или даже так:
[XXX LVM XXX][ data ][boot]
В последних 2х случаях есть вероятность того, что система не сможет загрузиться, поскольку нужный раздел может находится за пределами пространства на диске, которое может адресовать BIOS.
**win**:
Здесь всё проще и одновременно - сложнее.
Поскольку путь к профилям пользователя привязывается к абстрактной «букве диска», которые после развертывания назначаются для остальных разделов произвольно, таких фокусов как с /home - выше - мы позволить себе не можем. Поэтому оставляем всё как есть, после развертывания вручную переносим особо «злачные» места на раздел с данными, обычно это «рабочий стол» и «документы». Кроме того, не существует очевидного способа перенести их так, чтобы сохранились все права на файлы. (да, я знаю про переназначение путей, проблему с файлами это не снимает). монтирование раздела с данными в папку профиля вызывает засорение его настройками, кроме того, это порочная практика для win*.
В новых версиях, начиная с Vista, система при установке норовит выделить себе отдельный раздел под файлы загрузки[^fn2], так вот - не давайте ей это делать, иначе после перестановки разделов она не загрузится, поскольку определение раздела с системой происходит старым добрым способом - по номеру в mbr[^fn3].
Операции внутри системы
-----------------------
**nix**:
Как правило необходимы только для данных, идентифицирующих систему - те же ssh-ключи и необходимость убедиться, что initrd собран со всеми возможными драйверами.
Для данных можно написать скриптик, делающий всю работу при первой загрузке и прописать его куда-нибудь в «/etc/rc.local». Важно, чтобы потом он себя оттуда удалил.
**win**:
Здесь потребуется намного больше действий[^fn4].
Как минимум нужно убедиться в следующем:
* используются «стандартные» драйвера для дисковых контроллеров ide.
* установлен как минимум один sata-контроллер со «стандартными» драйверами ahci-sata
* отключена вся периферия и оставлено минимум устройств
* отключены все «сетевые» диски, и очищены все записи в реестре и ссылки, могущие ссылаться на них
* файловая система раздела не содержит ошибок
Создание эталонного образа
--------------------------
После выполнения всех указанных выше действий можно приступать к сохранению образа системы. Можно довериться автоматике, можно всё сделать вручную. В случае, если вы этот образ планируете разворачивать мультикастом сразу на несколько машин - делайте «автоматически».
В первом случае - выбираем режим сохранения разделов, выбираем нужные, жмем «сохранить» и идем пить чай с доширакой. На выходе получим директорию с десятком файлов, или жуткое сообщение об ошибке.
Во втором случае - придется потратить 5 минут на введение команд. Для случая ``linux/sdb(sdb1(ext3) sdb2(lvm) <del>sdb3</del>)`` они будут следующими:
T="/path/to/save/image"
mount "$T" /mnt
fdisk -u -l /dev/sdb >> "$T"
# чтобы впоследствии смотреть геометрию диска и размеры разделов
partclone.ext3 -c -s /dev/sdb1 -o "$T/sda1.ptcl.ext3.uncomp"
# имя может быть любое, но предложенная разработчиками схема достаточно неплоха
partclone.dd -c -s /dev/sdb2 | gzip -5 - > "$T/sda2.ptcl.lvm-raw.gz"
# в отличие от предыдущей команды - здесь используется несильное сжатие
dd if=/dev/sdb of="$T/mbr.bin" bs=446 count=1
# сохраняем начальный загрузчик
dd if=/dev/sdb of="$T/data-arfer-mbr.bin" bs=512 count=2047 skip=1
# сохраняем данные за mbr.
# 2047 - количество секторов до начала первого раздела
# 512 - размер сектора в байтах
# skip=1 - значит, что мы пропускаем один сектор (т.к. это mbr)
Образ, сделанный "вручную" придется разворачивать так же - вручную. Из плюсов - ничего лишнего.
Развертывание образа / исправление загрузки
-------------------------------------------
По умолчанию - поддерживается только grub (обе ветки) и ntldr, остальные - настраиваются и исправляются вручную.
Теоретическое отступление. Загрузка типового IBM-PC-совместимого компьютера происходит в несколько этапов:
* BIOS определяет порядок устройств для загрузки, считывает первый сектор с первого доступного устройства в очереди загрузки и передает ему управление.
* Загруженный сектор (mbr) ищет у себя запись о разделе диска с пометкой 0x80 (загрузочный), опять читает с него один сектор и передает управление ему. Это - вторичный загрузчик.
* Вторичный загрузчик уже производит необходимые действия для загрузки. Как правило - выводит меню выбора вариантов загрузки, ищет по необходимому смещению на разделе ядро операционной системы, загружает код для обеспечения работы ядра на начальном этапе (тот самый initrd) проводит модификацию флагов разделов в загруженной mbr и т.д..
Всё вышесказанное относится к типовому IBM-PC-совместимому компьютеру с BIOS. На машинах с [U]EFI, думаю всё будет немного по другому.
Специфичные шаги для загрузчиков:
**grub**:
Внимание! grub хранит часть своих данных в области непосредственно за mbr и до начала первого раздела, обычно это - 62 сектора (т.е. 32кб), первый раздел же начинается с 63го.
Во второй ветке grub'а - 62х секторов ему уже мало, так что выделяйте 2048 - это рекомендуется по умолчанию большинством дистрибутивов перешедших на него.
При необходимости - редактируется конфиг загрузчика (например - при указании корневого устройства как /dev/hda1, а систему развернули на sda2). Это можно выполнить и в самом меню загрузки, главное - до него добраться.
Коды ошибок: stage1 - первый сектор раздела, stage1.5 - данные за mbr, stage2 - данные и конфигурация основного загрузчика на загрузочном разделе.
**ext/syslinux**:
Исправляются элементарно:
Для syslinux'а:
syslinux -i -t <offset> [-d dir/] /dev/sdX
syslinux [-d dir/] -i /dev/sdXY
Где <offset> - смещение начала загрузочного раздела в байтах, sdX - устройство, с которого будем грузится. (Обратите внимание - в этом случае - не раздел, а само устройство). Во втором случае - offset - не нужен. Обе команды выше - делают то же самое. Важно! если конфиг лежит не в корне ФС раздела, а в поддиректории - мы должны указать её с помощью параметра «-d» при установке загрузчика.
Для extlinux'а:
extlinux -i /boot/[dir/]
Здесь важно указать правильный путь до директории, где лежит конфиг загрузчика. Символические ссылки поддерживаются. Обратите внимание, что все пути в конфигах пишутся относительно директории с первичным конфигом загрузчика.
Для syslinux загрузочный раздел должен быть отформатирован в ФС FAT, для extlinux, соответственно, - в ext2/3/4/btrfs
Дальнейшие действия загрузчика описываются в конфиг-файле, это уже понятно. Если мы получили работающий загрузчик, читающий конфиг - можно сказать мы победили, осталось поправить этот самый конфиг до работающего.
**lilo**:
Самый вредный и непредсказуемый из описываемых загрузчиков.
Для установки и изменения параметров требует подобия загруженной системы: как минимум корень с конфигом в /etc/, /boot/ с ядрами и initrd (если он на отдельном разделе), /dev/ для доступа к устройствам и /proc/ для чтения разделов.
Чинится так:
mount /dev/sda2 /mnt/new_root
mount /dev/sda1 /mnt/new_root/boot
mount --bind /dev /mnt/new_root/dev
chroot /mnt/new_root
mount -t proc none /proc
{vi, nano, ed, ...} /etc/lilo.conf
lilo
exit
reboot
Если промахнулись в опциях ядра - вспоминаем, дописываем в приглашении, иначе - вышеуказанное - повторить.
Грабли возможны с параметрами:
* bigmem - если размер initrd достаточно велик - он перепишет часть кода ядра со всеми вытекающими
* lba32 - если режим адресации на диске отличается от указанного - longjump промахнется мимо ядра
**ntldr**:
Второй по вредности и непредсказуемости.
Зависит от 3х файлов в корне раздела - ntldr, ntdetect и boot.ini. Первый читается с раздела напрямую по заранее заданному смещению, исправить его можно так:
partclone.ntfsfixboot -w /dev/sdXY
Также, в boot.ini должен быть прописан правильный номер раздела (partition(X), счет начинается с единицы).
**ntldr в системах Vista и выше**:
Терминальный звиздец, руками из под доса исправлению не поддается, настройки хранит в отдельной ветке реестра. С вероятностью 70% исправляется загрузочным диском/встроенной графической утилиткой. В остальных 30% - в морг^W^W только переустанавливать снова.
[^fn1]: наработки [[http://www.idealworldinc.com/partclone-utils/|есть]], но это ещё глубокая альфа
[^fn2]: что-то мне это напоминает
[^fn3]: что линуксу - хорошо, то венде - смерть :-)
[^fn4]: Фактически, подготовка к клонированию здесь начинается с создания своего установочного образа и интеграции драйверов в него. Т.е. поставив систему с «официального» диска, добится нормальной переносимости системы мы не сможем