ВНИМАНИЕ!!!! Предложенное вашему вниманию руководство - все-го лишь инструкция как решить одну конкретную задачу (описанную в начале документа). Если ваша задача хоть чуточку отличается от постановки, то пользуйтесь этой инструкцией не бездумно копируя команды, а адаптируя их под свои реалии.
Будьте осторожны, в этой инструкции вы работаете с системным разделом и ошибки могут привести к полному краху системы. Обязательно сделайте бекап системы прежде чем приступать к подобным действиям. А кроме того, крайне рекомендуется протестировать ваши манипуляции сначала на виртуальной машине, а уже выработав свой вариант точных инструкций и команд, приступать к конвертации системного раздела вашей реальной системы.

Задача

Есть ОС с корнем на разделе диска, и нужно перенести корень на программный RAID, при этом процесс переноса нужно сократить максимально во времени. Допустим это у нас сервер и его даже перегрузить - сложность. В наличии один диск на котором раздел с корнем, и второй диск эквивалентного(или большего) объема - пустой.

Условия

На оригинальном диске расположен корень и своп, новый диск чист. Мы будем делать программный RAID1. Используется Ubuntu Server 11.10

Порядок действий

Порядок действий достаточно важен, и выработан в процессе нескольких попыток решить эту задачу с использованием виртуальной машины.

1. Подключаем второй диск к компьютеру. 1)
2. Форматируем новый диск 2) -

# fdisk /dev/sdb
n
p
1
<enter>
<enter>
w

3. Создаем на нем массив:

# mdadm --create /dev/md0 --level=1 --raid-devices=2 missing /dev/sdb1 
Массив создается с пропущенным диском и поэтому работает в degrade режиме. ВНИМАНИЕ Массив делается не на диске, а на разделе - зачем - смотрите комментарий №1

4. Далее создаем на массиве разделы под будущую систему. Создаем такие же разделы под корень и своп как на оригинальном диске3).

# fdisk /dev/md0
....

5. Создаем файловые системы на разделах зеркала

# mkfs.ext4 /dev/md0p1
# mkswap /dev/md0p2

6. Монтируем будущий корень и копируем в него текущий корень

# mount /dev/md0p1 /mnt
# rsync -axu / /mnt/

7. После этого прицепляем системные каталоги к новому корню, что бы потом сделать chroot в новый корень (это важно - зачем объеснено в комментарии №2). И собственно делаем chroot в новый корень.

# mount --bind /proc /mnt/proc
# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys
# mount --bind /run /mnt/run
# chroot /mnt
Вот мы в будущем окружении (с корнем на раиде), но пока в нем только копия оригинального корня. Приступим…

8. Для начала смотрим UUID-ы разделов на раиде и прописываем их в fstab. 4) По редактированию fstab лучше сверится с этой статьей.

#/ls -l /dev/disk/by-uuid |grep md >> /etc/fstab
#/nano /etc/fstab 
(там комментируем старые корень и своп и используя скопированные туда uuid-ы прописываем новый корень и своп по образу и подобию старых, но с uuid-ами раидных разделов)

9. Создаем новую конфигурацию GRUB и проверяем, что в его конфиг прописан раидный uuid для корня.

#/update-grub
#/cat /boot/grub/grub.cfg

10. Ставим первую стадию GRUB на второй диск (который несет на себе часть зеркала).

#/grub-install /dev/sdb

11. Очень важный шаг! Нужно прописать (хотя бы на время) конфигурацию mdadm, которая позволит загрузится с деградированного массива (а у нас пока он именно такой)

#/dpkg-reconfigure mdadm (там со всем соглашаемся, включаяя последний шаг, где спрашивают - позволять ли грузится системе на деградированном массиве)
dpkg-reconfigure вызовет перестройку initrd, но так как мы в chroot, то он его перезапишет только в раидном корне (на реальном корне initrd сохранится таким как он был)
Ну собственно и все - система на раиде готова.

12. Можно перегружаться и выбрать в BIOS загрузочным второй диск5), или можно вернутся в реальную систему и обновить GRUB - он найдет вторую систему установленную на раиде и включит ее свое меню.
Тут полезно еще раз запустить rsync, что бы он обновил данные на раиде тем, что успело изменится на реальном корне за время настройки раида 6). Но сделать это стоит перед перестройкой конфига GRUB, что бы его новый конфиг не был записан на раид.

#/exit  --- выходим из chroot
# rsync -axu / /mnt/
# update-grub
# reboot
Тут важная точка в процессе.
Если при перезагрузке что-то пошло не так и новая система на раиде не поднимается, то откат назад делается перегрузкой с первого диска - там у нас сохранилось все как было до начала процедуры.

13. Перегрузившись в новую систему остается только навесить в RAID первый диск и обновить на нем первую стадию груба.

# fdisk /dev/sda
(там убиваем старые разделы и создаем один новый - на весь объем)
# mdadm --manage /dev/md0 --add /dev/sda1
# grub-install /dev/sda

После чего сморим через cat /proc/mdstat как перестраивается наш деградированный массив в полноценно рабочий.

Результат: Система на раиде. :-D

Проверка

Т.к. в процессе написания этой инструкции использовалась виртуалка то можно поиграть с потерей дисков. Гасим виртуалку, отсоединяем первый диск, грузимся - норма (массив деградированный на втором диске, груб стартанул со второго диска). Снова гасим - подцепляем обнуленный второй диск, создаем на нем MBR, раздел, и добавляем его в массив (как выше добавлялся sda1) - система перестраивает массив и переходит в нормальный режим.
Повторяем то-же, но отключая и обнуляя второй диск - все работает.

ПРОФИТ!! :-D

Комментарии:

№1: Если вы создадите массив на весь диск - то на диске может быть занят первый трек - и грубу некуда будет поставить свою первую стадию. А кроме того GRUB вообще не понимает? что на диске творится когда на нем расположен раидный раздел без MBR и не может встать туда. Другой (не совсем правильный) вариант - создавать на каждый раздел - свой массив. Идеологически - массив это диск, а не раздел, и если вы, имея массив, запустите fdisk -l то он вам на каждый RAID массив выдаст информацию именно как о диске и будет на каждом массиве искать таблицу разделов.

№2: chroot в новый корень на этапе настройки позволяет сделать все настройки в новом корне(который на RAID) и не трогать текущий (который на простом диске), что позволит организовать загрузку как с корнем в RAID-е, так и с корнем на диске. Это может потребоваться, если мы что-то намудрим в настройке нового раидного корня и не сможем загрузится в раидную версию нашей системы. Тогда остается шанс откатится полностью назад еще одной перезагрузкой.

ВАЖНЫЙ КОММЕНТАРИЙ КО ВСЕЙ РАБОТЕ: Работа проводилась на витруалке и на сервере без какой-либо нагрузки (ни ПО никакого серверного не стояло, ни каких сервисов сервер не предоставлял и не использовался кем-либо со стороны). Поэтому в момент копирования корня и после перезагрузки в раидую версию системы - ничего криминального не произошло. При наличии рабочих серверов это копирование (6-й шаг инструкции) может стать проблемой - т.к. данные в реальном корне «уйдут» по времени от данных на раидном, и перезагрузка «отбросит» сервисы на сервере в момент времени, когда была сделана копия. А кроме того - такое копирование может вообще разрушить целостность данных севисов т.к. разные файлы будут копироваться в разное время - тут надо копать либо в сторону FS, которые могут делать снепшоты? Либо корень системы копировать, а данные приложений переносить другими средствами 7)
Чуть улучшает состояние дел вызов rsync повторно перед пеезагрузкой (шаг 12). Но и он не может ничего гарантирововать.

Важные примечания

update-grub берет данные о корне (откуда грузить ядро и initrd) из fstab и совершенно замечателно составляет конфиг для загрузки с раидного кроня (или /boot).
mdadm совсем не критичен к типам разделов которые он подцепляет в RAID. Но, правильным будет поменять их тип на тип FD (Linux raid auto), что бы они корректно показывались в дисковых утилитах.
По этой процедуре можно сделать и другие версии RAID, важно только что бы загрузчик умел грузится с такого типа RAID что вы делаете.
При наличии полного комплекта новых дисков для RAID массива помимо существующего в системе, процедуру можно проделать с созданием полноценного массива (не деградированного), а оставшийся после переноса диск повесить в массив как горячий резерв.

Ссылки

1)
В случае с сервером, что-бы не перегружать, это может быть hot-swap диск или даже диск в USB-коробке. На время настройки и USB2 интерфейса хватит, хотя конечно копироваться данные на него будут медленно, а внутрь сервера мы его переставим во время едиснственной перегрузки, позже.
2)
Тут и далее приглашение шелла # говорит о том, что мы работаем из под рута, чтобы перейти в такой режим выполните sudo -i и введите свой пароль
3)
sfdisk -d /dev/sda | sfdisk /dev/md0 - в нашем случае может не прокатить т.к. диск массива - это раздел на диске, а значит в нем минимум на один трек меньше объем
4)
Автору было лень мудрить с оснасткой на виртуальном сервере и он просто дописал вывод ls в fstab, а потом отредактировал его.
5)
Если на время настройки второй диск стоял в USB коробке, то во время единственной перегрузки его можно перевесить на нормальный интерфейс нашего сервера
6)
опция u не даст затереть более новые конфиги mdadm и initrd на раиде
7)
Например для базы данных можно сделать реплику на раидном диске, и тогда сервис будет недоступен только на время перезагрузки, но важно настроить реплику так, что бы она нормально поднялась на новом корне, при недоступной той части, которая останется на оригинальном разделе, который при перезагрузке в «раидную систему» просто не будет смонтирован… Хотя и это можно предусмотреть, если старый раздел с данными монтировать на место где во время настройки был смонтирован раидный раздел с данными во время настройки