Типова ситуація — вилітає один з дисків на сервері. Однак ми зберігаємо дані в RAID з рівнем мінімум 1, чи не так 🙂 ?
Якщо так — то все добре! Проте однак постає задача: після заміни фізичного носія (вінчестера, так би мовити) швидко включити його назад в RAID для синхронізації. Тим паче, ящо зазвичай стоять однакові диски, то вихід з ладу одного зазвичай сигналізує, що й іншому гаплик не за горами 🙁 .
Тому швиденько приймаємося за справу! І тут виникає перший марудний момент — слід на новому вінчестері встановити таблицю розділів, таку, яка була на старому диску. Можна піти важким шляхом і зробити це вручну, проте істинний лінивий сисадмін ніколи не опуститься до такого, поки є в запасі тулзи, які зроблять це за нього 🙂 .
В моєму (дуже типовому, до речі) випадку, на сервері хостінгу стояли два ідентичні вінчестери, в яких були однакові таблиці розділів, тому справа була з тривіальних, як описано нижче. Якщо ж у Ваших конфігураціях щось не так, моя порада: зберігайте на бекапах таблицю розділів!
1. Уточнення ситуації.
Для чого потрібно? А тільки для того, щоб випадково не зробити все навпаки — на робочий вінчестер залити дамп з нового 🙂
ls -1 /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sda3 /dev/sdb
Як бачимо, є новий диск sdb і основний вінчестер — sda, на якому є 3 розділи:
#sfdisk -l /dev/sda Disk /dev/sda: 38913 cylinders, 255 heads, 63 sectors/track Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sda1 * 0+ 12 13- 104391 fd Linux raid autodetect /dev/sda2 13 770 758 6088635 82 Linux swap / Solaris /dev/sda3 771 38912 38142 306375615 fd Linux raid autodetect
маємо 1 і 3 розділ диску з типом Software RAID (md0 та md1 — відповідно) та 2 розділ під swap (який наразі уже і не використовується, проте живе з історичних причин).
Нагадую — зазначені тут імена дисків приведені під існуючу конфігурацію! Якщо у Вас інша — змініть, відповідно, назви пристроїв!
2. Зберігаємо таблицю розділів з живого диска
sfdisk -d /dev/sda >/root/sda.sfdisk.dump
3. Відновлюємо таблицю розділів на новий диск
sfdisk /dev/sdb </root/sda.sfdisk.dump
4. АБО п.п. 2 і 3 в одному флаконі!
sfdisk -d /dev/sda | sfdisk /dev/sdb
У відповідь на це маємо щось на кшталт:
sfdisk -d /dev/sda |sfdisk /dev/sdb Checking that no-one is using this disk right now ... OK Disk /dev/sdb: 38913 cylinders, 255 heads, 63 sectors/track sfdisk: ERROR: sector 0 does not have an msdos signature /dev/sdb: unrecognized partition table type Old situation: No partitions found New situation: Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/sdb1 * 63 208844 208782 fd Linux raid autodetect /dev/sdb2 208845 12386114 12177270 82 Linux swap / Solaris /dev/sdb3 12386115 625137344 612751230 fd Linux raid autodetect /dev/sdb4 0 - 0 0 Empty Successfully wrote the new partition table Re-reading the partition table ... If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).)
Хм… Начебто все добре, та щось нас добрий sfdisk попередив про перших 512 байт! Гаразд, відразу перевіримо, чи записалась нова таблиця на новий диск:
fdisk -l /dev/sdb Disk /dev/sdb: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 13 104391 fd Linux raid autodetect /dev/sdb2 14 771 6088635 82 Linux swap / Solaris /dev/sdb3 772 38913 306375615 fd Linux raid autodetec
Як бачимо — все на місці!
Залишилось:
- перезаписати MBR (тих самих 512 байт)
- за потреби створити swap
- включити новосторені розділи нового диску в старий RAID
5.1. Дублюємо MBR:
dd if=/dev/sda of=/dev/sdb bs=512 count=1 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.000411 seconds, 1.2 MB/s
5.2. Створюємо swap в автоматичному режимі:
for i in `fdisk -l /dev/sdb|grep -F swap|cut -f1 -d' '`;\
do echo "Making swap in ${i}"; mkswap ${i};\
done
Making swap in /dev/sdb2
Setting up swapspace version 1, size = 6234755 kB
5.3. Включаємо нові розділи в старий RAID:
Що маємо спочатку:
# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sda1[0] 104320 blocks [2/1] [U_] md1 : active raid1 sda3[0] 306375488 blocks [2/1] [U_] unused devices: <none>
Додаємо відповідні розділи до відповідних масивів:
mdadm --manage --add /dev/md0 /dev/sdb1 mdadm: added /dev/sdb2 mdadm --manage --add /dev/md1 /dev/sdb3 mdadm: added /dev/sdb3
Перевіряємо, чи все нормально в RAID’і:
cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[1] sda1[0] 104320 blocks [2/2] [UU] md1 : active raid1 sdb3[2] sda3[0] 306375488 blocks [2/1] [U_] [>....................] recovery = 0.0% (2240/306375488) finish=2220.0min speed=2240K/sec unused devices: <none>
Як бачимо, RAID-масив md0 вже відновлено (дуже швидко внаслідок малого розміру, а у Вас може бути довше), а масив md1 знаходиться в стані відновлення (синхронізації) recovery.
Після завершення процедури вивід /proc/mdstat буде на зразок:
cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[1] sda1[0] 104320 blocks [2/2] [UU] md1 : active raid1 sdb3[2] sda3[0] 306375488 blocks [2/2] [UU] unused devices: <none>
Додатково (на всяк випадок скорше) перевіряємо, чи стали на нових розділах потрібні UUID (по яких власне і відбувається прив’язка цих розділів до певного RAID-масиву):
blkid /dev/sdb1 /dev/sdb1: UUID="33f6d636-5155-4bf5-81c9-e01bbc6b701a" TYPE="ext3" blkid /dev/sda1 /dev/sda1: UUID="33f6d636-5155-4bf5-81c9-e01bbc6b701a" TYPE="ext3"
Як бачимо, обидва розділи з різних дисків мають однаковий UUID, який відповідає UUID потрібного RAID-масиву (/dev/md0)!
Хай щастить в нелегкій адмінській справі та не губляться дані 🙂 !