Это будет просто история. История о том, как у меня рассыпался RAID на сервере, и как я, в попытке его восстановить, "потерял" все данные на нем. Казалось бы, у меня довольно большой опыт работы в -nix системах, в голове достаточно много знаний, есть понимание, что надо внимательно читать и документацию и выхлоп консоли, но все же иногда случаются досадные промахи, по типу этого. Так что не буду стесняться и напишу все, как было (по крайней мере то, что могу вспомнить, так как это было полтора месяца назад, как летит время).
Несмотря на то, что я написал "потерял", данные у меня все же сохранились, так как я все же оказался достаточно сообразительным, и перед тем, как делать манипуляции с дисками, сделал полный бэкап. Да, неудачное восстановление уничтожило данные на самом массиве, но это не была безвозвратная потеря. Так что, из ущерба у меня лишь удар по самооценке и несколько часов времени. Из приобретений — некоторое количество опыта, по крайней мере из разряда "как не надо делать".
Началось все с того, что я заглянул в dmesg и увидел, что один из дисков, входящих в мой RAID1C перестал подавать признаки жизни. Система, конечно, выезжала на втором, но ежу понятно, надежность стала на уровне "авось". Так сложилось, что это все совпало с моментом, когда я собрался менять процессор (для того, чтобы наконец то запустить на сервере виртуалку в vmd), поэтому удалось обойтись без лишней операции сборки-разборки. Но, если замена CPU прошла удачно, в случае с дисками все пошло наперекосяк.
Вообще, процедура должна была быть достаточно простой - нужно всего лишь поменять диск, добавить его в имеющийся RAID и скомандовать "восстанавливайся", но тут то я и накосячил. Диск я вставил (такой же, как помер, кстати), сделал на нем такую же таблицу разделов (более того, перенес ее с рабочего диска, благо с помощью disklabel это сделать легко), но почему-то восстановление работать отказывалось.
Не могу сказать, что именно пошло не так. По итогу я каким-то пинком (а именно, подсунув на второй диск десять мегабайт первого) сумел запустить восстановление, но, похоже что восстановил не с первого диска на второй, а наоборот. Как я писал выше, данные я потерял. Возможно, из-за того, что профукал уникальность DUID-ов. EPIC, что называется, FAIL.
Что ж. я был к этому готов, бэкап был сделан заранее, так что никто не умер, кроме зря потраченного времени. Но, желая все же понять, "как надо", я повторил операцию восстановления RAID1C на виртуальной машине. Получилось успешно, так что вся методика будет приведена ниже.
Смотрим подключенные к машине диски. Перед этим я собрал RAID1C, после чего заменил один из дисков таким же, но неинициализированным. В данном случае, это wd2.
test# sysctl hw.disknames
hw.disknames=wd0:bc846e561d7b8583,wd1:b3f8bc68a542ab20,wd2:,sd0:d45877e226540ec5,fd0:
Так как на этой машине я не заморачивался скриптом, поднимающим RAID1C, я поднял его вручную, с одним диском:
test# bioctl -c 1C -l wd1a softraid0
softraid0: trying to bring up sd1 degraded
Passphrase:
softraid0: trying to bring up sd1 degraded
softraid0: RAID 1C volume attached as sd1
Теперь копируем disklabel с живого диска в файл, после чего применяем полученный файл к новому диску, создавая там симметричную таблицу разделов. Выводить команду disklabel не обязательно, тут я сделал это для наглядности.
test# disklabel wd1 > file.txt
test# cat file.txt
# /dev/rwd1c:
type: ESDI
disk: ESDI/IDE disk
label: QEMU HARDDISK
duid: b3f8bc68a542ab20
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 64
sectors/cylinder: 4032
cylinders: 520
total sectors: 2097152
boundstart: 64
boundend: 2097119
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2097055 64 RAID
c: 2097152 0 unused
test# fdisk -gy wd2
Writing GPT.
test# disklabel -R wd2 file.txt
test# disklabel wd1
# /dev/rwd1c:
type: ESDI
disk: ESDI/IDE disk
label: QEMU HARDDISK
duid: b3f8bc68a542ab20
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 64
sectors/cylinder: 4032
cylinders: 520
total sectors: 2097152
boundstart: 64
boundend: 2097119
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2097055 64 RAID
c: 2097152 0 unused
test# disklabel wd2
# /dev/rwd2c:
type: ESDI
disk: ESDI/IDE disk
label: QEMU HARDDISK
duid: a8086627332ad705
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 32
sectors/cylinder: 2016
cylinders: 1040
total sectors: 2097152
boundstart: 64
boundend: 2097119
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 2097055 64 RAID
c: 2097152 0 unused
Смотрим статус нашего RAID1C. Видим,ч то он degraded.
test# bioctl -iv softraid0
Volume Status Size Device
softraid0 0 Online 10737115136 sd0 CRYPTO
0 Online 10737115136 0:0.0 noencl <wd0a>
'unknown serial'
softraid0 1 Degraded 1073421824 sd1 RAID1C
0 Online 1073421824 1:0.0 noencl <wd1a>
'unknown serial'
1 Offline key disk 1:1.0 noencl <>
'unknown serial'
Запускаем восстановление командой bioctl. В параметры она принимает новый диск и имя устройства RAID.
test# bioctl -R /dev/wd2a sd1
softraid0: rebuild of sd1 started on wd2a
test# bioctl -iv softraid0
Volume Status Size Device
softraid0 0 Online 10737115136 sd0 CRYPTO
0 Online 10737115136 0:0.0 noencl <wd0a>
'unknown serial'
softraid0 1 Degraded 1073421824 sd1 RAID1C
0 Online 1073421824 1:0.0 noencl <wd1a>
'unknown serial'
1 Offline key disk 1:1.0 noencl <>
'unknown serial'
И, как видим, массив снова online. Файлы не потерялись
test# bioctl -iv softraid0
Volume Status Size Device
softraid0 0 Online 10737115136 sd0 CRYPTO
0 Online 10737115136 0:0.0 noencl <wd0a>
'unknown serial'
softraid0 1 Online 1073421824 sd1 RAID1C
0 Online 1073421824 1:0.0 noencl <wd1a>
'unknown serial'
1 Online 1073421824 1:1.0 noencl <wd2a>
'unknown serial'
Короче говоря, не все так страшно, как казалось. Но накосячить можно, и мой опыт тому пример.
Кстати, OpenBSD 7.9, вышедшая недавно, теперь позволяет прямо в инсталляторе, без какого-либо бубна поставить систему на шифрованный раздел. Удобно, теперь не нужно совершать лишние телодвижения.