Есть у компании Western Digital такое сетевое хранилище WD ShareSpace 40000. Оно работает на 4 SATA дисках (по 1ТБ) и неплохо используется как SOHO-решение. Внутри — linux из ПЗУ. Конфигурируется через web, но можно открыть и ssh доступ. Мы на работе использовали несколько таких в качестве хранителей промежуточных данных.
Не так давно, в один “счастливый” день при скачке напряжения одно из хранилищ перестало нормально загружаться — по сети достучаться до него стало невозможно. Потерять данные было не смертельно, но обидно, поэтому стали прикидывать, как можно восстановиться.
Естественно, подключить клавиатуру и монитор к хранилищу и загрузить его в “безопасный режим” невозможно. Все попытки его восстановить с помощью кнопки reset (сброс сетевых параметров, перезагрузка) успеха не принесли. Поскольку сеть недоступна, перепрошить firmware тоже нельзя. Стали думать, как вытянуть данные. Я залез по ssh на такое же хранилище и начал изучать его организацию. Попутно выяснилось, что внутри “железки” — ARM и 128МБ оперативки:
~ $ uname -a
Linux WD-0002 2.6.12.6-arm1 #31 Wed Feb 25 11:58:13 CST 2009 armv5tejl unknown
~ $ cat /proc/cpuinfo
Processor : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS : 499.71
Features : swp half thumb fastmult vfp edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 0
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 32768
I assoc : 1
I line length : 32
I sets : 1024
D size : 32768
D assoc : 4
D line length : 32
D sets : 256
Hardware : Feroceon
Revision : 0000
Serial : 0000000000000000
~ $ free
total used free shared buffers
Mem: 126332 124380 1952 0 38260
Swap: 1044152 12 1044140
Total: 1170484 124392 1046092
Загрузка идёт сначала с FlashROM (cramfs), а потом организуется банальный softraid+LVM2, несколько разделов, на одном из которых хранится “остальная” система+конфигурация, на другом — swap, а на остальном — пользовательские данные:
/etc $ mount /dev/root on /old type cramfs (ro) proc on /old/proc type proc (rw,nodiratime) /dev/md0 on / type ext3 (rw,noatime) proc on /proc type proc (rw,nodiratime) /proc/bus/usb/ on /proc/bus/usb type usbfs (rw) /dev/pts on /dev/pts type devpts (rw) trusteesfs on /trustees type trusteesfs (rw) /dev/vg0/lv0 on /DataVolume type ext3 (rw,noatime) /dev/ram0 on /mnt/ram type tmpfs (rw) /dev/vg0/lv0 on /shares/Download type ext3 (rw,noatime) /dev/vg0/lv0 on /shares/Public type ext3 (rw,noatime) /dev/vg0/lv0 on /shares/TIFF_archive type ext3 (rw,noatime) /dev/vg0/lv0 on /shares/Upload_to_VR type ext3 (rw,noatime) /dev/vg0/lv0 on /shares/used type ext3 (rw,noatime)
Заметили, что на разделе /dev/md0 находится вполне обычная unix-структура каталогов? В ней и расположены конфиги, профили и права пользователей, кое-какие логи. Стал вырисовываться план действий: вытащить диски, вставить их в Linux машину и проверить, что там в рэйдами и разделами. Тут же нашлась машинка с 4 SATA разъёмами, флэшка с riplinux, и работа закипела. После загрузки убеждаемся, что диски определились:
# fdisk -l Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 26 208844+ fd Linux raid autodetect /dev/sda2 27 156 1044225 fd Linux raid autodetect /dev/sda3 157 182 208845 fd Linux raid autodetect /dev/sda4 183 121601 975298117+ fd Linux raid autodetect Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 1 26 208844+ fd Linux raid autodetect /dev/sdb2 27 156 1044225 fd Linux raid autodetect /dev/sdb3 157 182 208845 fd Linux raid autodetect /dev/sdb4 183 121601 975298117+ fd Linux raid autodetect Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdc1 1 26 208844+ fd Linux raid autodetect /dev/sdc2 27 156 1044225 fd Linux raid autodetect /dev/sdc3 157 182 208845 fd Linux raid autodetect /dev/sdc4 183 121601 975298117+ fd Linux raid autodetect Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdd1 1 26 208844+ fd Linux raid autodetect /dev/sdd2 27 156 1044225 fd Linux raid autodetect /dev/sdd3 157 182 208845 fd Linux raid autodetect /dev/sdd4 183 121601 975298117+ fd Linux raid autodetect
Все 4 диска по 1 ТБ видны. Разделы вроде в порядке. Собираем массивы:
# mdadm --assemble --scan mdadm: /dev/md/127_0 has been started with 4 drives. mdadm: /dev/md/1_0 has been started with 4 drives. mdadm: /dev/md/125_0 has been started with 4 drives.
Теперь в дисках появлилась дополнительная информация:
Disk /dev/md127: 2995.5 GB, 2995500810240 bytes 2 heads, 4 sectors/track, 731323440 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md127 doesn't contain a valid partition table Disk /dev/md126: 1069 MB, 1069219840 bytes 2 heads, 4 sectors/track, 261040 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md126 doesn't contain a valid partition table Disk /dev/md125: 213 MB, 213778432 bytes 2 heads, 4 sectors/track, 52192 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk identifier: 0x00000000 Disk /dev/md125 doesn't contain a valid partition table
Ага! /dev/md125 (213MB) — раздел с конфигами, md126 (1GB) — swap, md127 (3TB) — данные. Они хранятся в виде LVM. На всякий случай проверяем:
# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]
md125 : active raid1 sdd1[0] sda1[3] sdc1[2] sdb1[1]
208768 blocks [4/4] [UUUU]
md126 : active raid1 sdd2[0] sda2[3] sdc2[2] sdb2[1]
1044160 blocks [4/4] [UUUU]
md127 : active raid5 sdd4[0] sda4[3] sdc4[2] sdb4[1]
2925293760 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
unused devices:
Ну и зоопарк! Раздел с конфигами — зеркало, swap — страйп, а пользовательские данные RAID5. Впрочем, всё вполне объяснимо. Хорошо, хоть все диски в “U” и ресинхронизация не потребовалась.
У меня была надежда, что сеть на хранилище не поднялась потому, что не смог смонтироваться раздел с конфигами. Вначале я попробовал смонтировать /dev/md125 (конфиги), нарвался на сообщение об ошибке и запустил проверку файловой системы:
fsck /dev/md125
Не буду писать всю процедуру лечения, так как там всё более-менее рутинно. После того, как раздел отремонтировали, я потащил диски обратно в хранилище. Но не тут-то было! Злосчастная железка всё равно не захотела подниматься! Но на этот случай был предусмотрен запасной вариант. Снова подключаем диски к компьютеру, снова грузим RIPLinux, собираем массивы. Теперь будем работать с пользовательским разделом:
Пподключаем LVM:
# pvscan PV /dev/md127 VG vg0 lvm2 [2.72 TB / 0 free] Total: 1 [741.77 GB] / in use: 1 [741.77 GB] / in no VG: 0 [0 ] # vgscan Reading all physical volumes. This may take a while... Found volume group "vg0" using metadata type lvm2 # lvscan inactive '/dev/vg0/lv0' [2.72 TB] inherit # vgchange -ay 1 logical volume(s) in volume group "vg0" now active
Пытаемся смонтировать:
# mount /dev/vg0/lv0 /mnt
Снова ошибки на FS, снова fsck. В конце концов, и этот раздел смонтировался:
# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 947M 149M 798M 16% / /dev/mapper/vg0-lv0 2.7T 2.1T 652G 77% /mnt
ОПА! Заработало. Теперь можно сливать информацию. Монтируем по самбе доступный сервер, и копируем всё туда. Пока идёт копирование, можно написать отчёт в блог 🙂
Наверное, можно было взять /dev/md0 с рабочего хранилища, например, стащив его по ssh:
ssh root@wd-0002.msk.rian "dd if=/dev/md0" >wd-ss-40000-md0.img
А потом сделать изменения в конфигурации. Но возиться времени не было, поэтому следующий шаг был такой: на каждом из дисков запускался
cfdisk -z /dev/sda
который обнулял таблицу разделов. После этого 4 обновлённых диска снова отправились в хранилище. За этим последовала инициализация массива, переразбивка дисков и опять ввод хранилища в строй. Даже перепрошивки firmware не потребовалось.
Перевести тебе на английский? =)
Отличная статья. 🙂
Сам неделю назад восстанавливал данные с NAS’а (Thecus n1200), там слетела reiserfs. Но на этом NAS’е тайванские инженеры очень интересно сделали: софтовый raid1 из swap’а и другого раздела, причём, естественно, всё это на одном диске 🙂
Восстанавливал следующем образом:
1. Бэкап 1Т средствами ddrescue
2. Натравил reiserfsck на sdb2.img
3. 17 corruption ошибок и соответственно reiserfs –rebuild-tree sdb2.img
4. И в завершении photorec на весь диск.
После этого NAS таки загрузился, но raid не захотел поднимать. Пришлось форматировать диск и сливать инфу из сделанного бекапа.