Восстановление информации с Linux-хранилища WD ShareSpace 40000

Восстановление информации с WD ShareSpace 40000 в LinuxЕсть у компании 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 не потребовалось.

Восстановление информации с Linux-хранилища WD ShareSpace 40000: 2 комментария

  1. Отличная статья. 🙂

    Сам неделю назад восстанавливал данные с 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 не захотел поднимать. Пришлось форматировать диск и сливать инфу из сделанного бекапа.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *