Всем привет! В последнее время всё чаще сталкиваюсь с тем, что многие админы используют дешёвые СХД (SOHO) для продуктивных сред… При этом редко задумываясь о доступности данных и отказоустойчивости решения… Увы, но не многие также задумываются о резервных копиях и бекапах…
Вот и сегодня ко мне «на лечение» попал интересный экземпляр:

Чудестный экземпляр EMC (ещё даже не Lenovo) iomega storcenter px4 (который дальше 25% не грузится)
О подробностях восстановления читайте под катом.
Итак, приступим.
Задачи у нас две:
1) Восстановить часть данных с дисков
2) Восстановить работоспособность СХД
Сперва нам надо понять с чем мы имеем дело и в этом нам поможет сайт производителя и документашка со спецификацией СХД — PDF дока.
Исходя из PDF-ки выше — можно понять что СХД представляет собой ничто иное как небольшой сервер на интеловом процессоре и, тут уж явно не на винде, каким-то линуксом на борту.
В самой документации нету упоминания о каком-либо RAID контроллере — потому пришлось вскрыть пациента и убедиться что аппаратная начинка не содержит сюрпризов.
Итак, что мы получили от хозяев СХД и документашки:
1) у нас есть СХД с дисками в каком-то RAID (без понимания в какой рейд заказчик собирал диски);
2) в СХД нету аппаратного RAID — так что делаем ставку на программное решение;
3) в СХД используется какой-то из линуксов (так как система не загружается — посмотреть что там не получилось);
4) Есть понимание что мы ищем на дисках (есть пара VMFS разделов которые были отданы для VM под ESXi и пара файловых шар для общего пользования).
План восстановления:
1) ставим ОС и подключаем диски;
2) смотрим что полезного можно вытянуть из информации о дисках;
3) Собираем Raid и пытаемся смонтировать разделы;
4) монтируем VMFS разделы;
5) сливаем всю нужную информацию на другую хранилку;
6) думаем что делать с EMC.
Так как «оживить» СХД не получилось (Если кто знает способы перепрошивки и может поделится утилитами — велкам в комментарии или личку) — подключаем диски к другой системе:

В моём случае под рукой был старенький сервачёк на AMD Phenom… Самое главное было найти материнку куда можно подключить минимум 4-и диска от СХД + 1 диск для установки ОС и прочих утилит.
ОС была выбрана Debian 8, так как она лучше всех дружит и с vmfs-tools и с iscsi target (ubunta ловит глюки).
SDA — диск с ОС, остальные 4и — диска от СХД
Как видим на дисках есть два раздела:
20 Гб — так понимаю под ОС самого СХД
1.8 Тб — под данные пользователя
Все диски имеют идентичную разбивку — с чего можно сделать вывод что они были единым масивом в RAID.
FSTYPE разделов определяется как linux_raid_member так что попробуем посмотреть что мы с них можем собрать.
Собираем массив:
При монтировании массива нам дали подсказу — filesystem type 'LVM2_member'.
Установим LVM2 и просканируем диски:
Как видим, мы нашли volume group. Логично предположить, что вторая часть может быть собрана подобным образом.
Теперь находит 2 LVM physical volumes
Из результата видно, что СХД собирала VG на LVM и дальше дробила на LV необходимых размеров.
Активируем разделы и пробуем их смонтировать:
Как видим, только часть разделов смонтировалось. А всё потому, что на других разделах — VMFS.
Увы, но танцев с бубном избежать не удалось… напрямую VMFS монтировать не захотело (есть подозрение что это связано с новой версией VMFS и старыми vmfs-tools)
Перерыв кучу форумов, решение нашлось.
Создаем loop device:
Немного о kpartx можно почитать ТУТ.
Пробуем смонтировать получившийся маппер:
Смонтировалось удачно! (на ошибки можно забить так как Lun ID mismatch)
Так как слить виртуальные машины из смонтированых датасторов не удалось… Попробуем подключить эти разделы к реальному ESXi и скопировать виртуалки через него (он то должен дружить с VMFS).
Подключим наши разделы к ESXi по средствам iSCSi (процесс опишем коротко):
1) Устанавливаем пакет iscsitarget
2) вносим необходимые параметры в /etc/iet/ietd.conf
3) Стартуем сервис service iscsitarget start
Если всё «ОК» — создаём на ESXi Software iSCSi controller и прописываем в Dynamic discovery наш сервер с примонтироваными разделами
Как видим разделы удачно подтянулись:

Так как LUN ID получившегося раздела не совпадает с тем что прописан в метаданных на самом разделе, для добавления датасторов к хосту — воспользуемся KB от VMware.
Датасторы восстановлены и с них спокойно можно сливать информацию.
P.S. Я сливаю по scp включив на сервере SSH доступ — это гораздо быстрее чем сливать виртуалку через веб или обычный клиент.
Как восстановить саму СХД — ума не приложу. Если у кого-то есть файлы прошивки и информация как подключить консоль — с радостью приму помощь.
Вот и сегодня ко мне «на лечение» попал интересный экземпляр:

Чудестный экземпляр EMC (ещё даже не Lenovo) iomega storcenter px4 (который дальше 25% не грузится)
О подробностях восстановления читайте под катом.
Итак, приступим.
Задачи у нас две:
1) Восстановить часть данных с дисков
2) Восстановить работоспособность СХД
Сперва нам надо понять с чем мы имеем дело и в этом нам поможет сайт производителя и документашка со спецификацией СХД — PDF дока.
Исходя из PDF-ки выше — можно понять что СХД представляет собой ничто иное как небольшой сервер на интеловом процессоре и, тут уж явно не на винде, каким-то линуксом на борту.
В самой документации нету упоминания о каком-либо RAID контроллере — потому пришлось вскрыть пациента и убедиться что аппаратная начинка не содержит сюрпризов.
Итак, что мы получили от хозяев СХД и документашки:
1) у нас есть СХД с дисками в каком-то RAID (без понимания в какой рейд заказчик собирал диски);
2) в СХД нету аппаратного RAID — так что делаем ставку на программное решение;
3) в СХД используется какой-то из линуксов (так как система не загружается — посмотреть что там не получилось);
4) Есть понимание что мы ищем на дисках (есть пара VMFS разделов которые были отданы для VM под ESXi и пара файловых шар для общего пользования).
План восстановления:
1) ставим ОС и подключаем диски;
2) смотрим что полезного можно вытянуть из информации о дисках;
3) Собираем Raid и пытаемся смонтировать разделы;
4) монтируем VMFS разделы;
5) сливаем всю нужную информацию на другую хранилку;
6) думаем что делать с EMC.
Шаг №1
Так как «оживить» СХД не получилось (Если кто знает способы перепрошивки и может поделится утилитами — велкам в комментарии или личку) — подключаем диски к другой системе:

В моём случае под рукой был старенький сервачёк на AMD Phenom… Самое главное было найти материнку куда можно подключить минимум 4-и диска от СХД + 1 диск для установки ОС и прочих утилит.
ОС была выбрана Debian 8, так как она лучше всех дружит и с vmfs-tools и с iscsi target (ubunta ловит глюки).
Шаг №2
root@mephistos-GA-880GA-UD3H:~# fdisk -l Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x000c0a96 Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1920251903 1920249856 915.7G 83 Linux /dev/sda2 1920253950 1953523711 33269762 15.9G 5 Extended /dev/sda5 1920253952 1953523711 33269760 15.9G 82 Linux swap / Solaris Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BFAE2033-B502-4C5B-9959-82E50F8E9920 Device Start End Sectors Size Type /dev/sdb1 72 41961848 41961777 20G Microsoft basic data /dev/sdb2 41961856 3907029106 3865067251 1.8T Microsoft basic data Disk /dev/sdc: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: B6515182-BF5B-4DED-AAB1-5AE489BF23B0 Device Start End Sectors Size Type /dev/sdc1 72 41961848 41961777 20G Microsoft basic data /dev/sdc2 41961856 3907029106 3865067251 1.8T Microsoft basic data Disk /dev/sdd: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 378627A1-2696-4DAC-88D1-B90AFD2B1A98 Device Start End Sectors Size Type /dev/sdd1 72 41961848 41961777 20G Microsoft basic data /dev/sdd2 41961856 3907029106 3865067251 1.8T Microsoft basic data Disk /dev/sde: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BA871E29-DB67-4266-A8ED-E5A33D6C24D2 Device Start End Sectors Size Type /dev/sde1 72 41961848 41961777 20G Microsoft basic data /dev/sde2 41961856 3907029106 3865067251 1.8T Microsoft basic data
SDA — диск с ОС, остальные 4и — диска от СХД
Как видим на дисках есть два раздела:
20 Гб — так понимаю под ОС самого СХД
1.8 Тб — под данные пользователя
Все диски имеют идентичную разбивку — с чего можно сделать вывод что они были единым масивом в RAID.
root@mephistos-GA-880GA-UD3H:~# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sdd |-sdd2 linux_raid_member px4-300r-THXLON:1 27b7ba6d-6a41-dd56-ad4b-7652f461a3b6 `-sdd1 linux_raid_member px4-300r-THXLON:0 b8b8526a-37ef-2a9b-e9e7-c249645dacb0 sdb |-sdb2 linux_raid_member px4-300r-THXLON:1 27b7ba6d-6a41-dd56-ad4b-7652f461a3b6 `-sdb1 linux_raid_member px4-300r-THXLON:0 b8b8526a-37ef-2a9b-e9e7-c249645dacb0 sde |-sde2 linux_raid_member px4-300r-THXLON:1 27b7ba6d-6a41-dd56-ad4b-7652f461a3b6 `-sde1 linux_raid_member px4-300r-THXLON:0 b8b8526a-37ef-2a9b-e9e7-c249645dacb0 sdc |-sdc2 linux_raid_member px4-300r-THXLON:1 27b7ba6d-6a41-dd56-ad4b-7652f461a3b6 `-sdc1 linux_raid_member px4-300r-THXLON:0 b8b8526a-37ef-2a9b-e9e7-c249645dacb0 sda |-sda2 |-sda5 swap 451578bf-ed6d-4ee7-ba91-0c176c433ac9 [SWAP] `-sda1 ext4 fdd535f2-4350-4227-bb5e-27e402c64f04 /
Шаг №3
FSTYPE разделов определяется как linux_raid_member так что попробуем посмотреть что мы с них можем собрать.
root@mephistos-GA-880GA-UD3H:~# apt-get install mdadm
Собираем массив:
root@mephistos-GA-880GA-UD3H:~# mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 mdadm: /dev/md0 has been started with 4 drives. root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/md0 root@mephistos-GA-880GA-UD3H:~# mount /dev/md0 /mnt/md0/ mount: unknown filesystem type 'LVM2_member'
При монтировании массива нам дали подсказу — filesystem type 'LVM2_member'.
Установим LVM2 и просканируем диски:
root@mephistos-GA-880GA-UD3H:~# apt-get install lvm2
root@mephistos-GA-880GA-UD3H:~# lvmdiskscan /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. /dev/ram0 [ 64.00 MiB] /dev/md0 [ 20.01 GiB] LVM physical volume /dev/ram1 [ 64.00 MiB] /dev/sda1 [ 915.65 GiB] /dev/ram2 [ 64.00 MiB] /dev/ram3 [ 64.00 MiB] /dev/ram4 [ 64.00 MiB] /dev/ram5 [ 64.00 MiB] /dev/sda5 [ 15.86 GiB] /dev/ram6 [ 64.00 MiB] /dev/ram7 [ 64.00 MiB] /dev/ram8 [ 64.00 MiB] /dev/ram9 [ 64.00 MiB] /dev/ram10 [ 64.00 MiB] /dev/ram11 [ 64.00 MiB] /dev/ram12 [ 64.00 MiB] /dev/ram13 [ 64.00 MiB] /dev/ram14 [ 64.00 MiB] /dev/ram15 [ 64.00 MiB] 0 disks 18 partitions 0 LVM physical volume whole disks 1 LVM physical volume
root@mephistos-GA-880GA-UD3H:~# lvdisplay /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. --- Logical volume --- LV Path /dev/66e7945b_vg/vol1 LV Name vol1 VG Name 66e7945b_vg LV UUID No8Pga-YZaE-7ubV-NQ05-7fMh-DEa8-p1nP4c LV Write Access read/write LV Creation host, time , LV Status NOT available LV Size 20.01 GiB Current LE 5122 Segments 1 Allocation inherit Read ahead sectors auto
Как видим, мы нашли volume group. Логично предположить, что вторая часть может быть собрана подобным образом.
root@mephistos-GA-880GA-UD3H:~# mdadm --assemble /dev/md1 /dev/sdb2 /dev/sdc2 /dev/sdd2 /dev/sde2 mdadm: /dev/md1 has been started with 4 drives.
root@mephistos-GA-880GA-UD3H:~# lvmdiskscan /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. /dev/ram0 [ 64.00 MiB] /dev/md0 [ 20.01 GiB] LVM physical volume /dev/ram1 [ 64.00 MiB] /dev/sda1 [ 915.65 GiB] /dev/md1 [ 5.40 TiB] LVM physical volume /dev/ram2 [ 64.00 MiB] /dev/ram3 [ 64.00 MiB] /dev/ram4 [ 64.00 MiB] /dev/ram5 [ 64.00 MiB] /dev/sda5 [ 15.86 GiB] /dev/ram6 [ 64.00 MiB] /dev/ram7 [ 64.00 MiB] /dev/ram8 [ 64.00 MiB] /dev/ram9 [ 64.00 MiB] /dev/ram10 [ 64.00 MiB] /dev/ram11 [ 64.00 MiB] /dev/ram12 [ 64.00 MiB] /dev/ram13 [ 64.00 MiB] /dev/ram14 [ 64.00 MiB] /dev/ram15 [ 64.00 MiB] 0 disks 18 partitions 0 LVM physical volume whole disks 2 LVM physical volumes
Теперь находит 2 LVM physical volumes
root@mephistos-GA-880GA-UD3H:~# lvdisplay /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. --- Logical volume --- LV Path /dev/3b9b96bf_vg/lv6231c27b LV Name lv6231c27b VG Name 3b9b96bf_vg LV UUID wwRwuz-TjVh-aT6G-r5iR-7MpJ-tZ0P-wjbb6g LV Write Access read/write LV Creation host, time , LV Status NOT available LV Size 2.00 TiB Current LE 524288 Segments 2 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/3b9b96bf_vg/lv22a5c399 LV Name lv22a5c399 VG Name 3b9b96bf_vg LV UUID GHAUtd-qvjL-n8Fa-OuCo-sqtD-CBzg-M46Y9o LV Write Access read/write LV Creation host, time , LV Status NOT available LV Size 3.00 GiB Current LE 768 Segments 1 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/3b9b96bf_vg/lv13ed5d5e LV Name lv13ed5d5e VG Name 3b9b96bf_vg LV UUID iMQZFw-Xrmj-cTkq-E1NT-VwUa-X0E0-MpbCps LV Write Access read/write LV Creation host, time , LV Status NOT available LV Size 10.00 GiB Current LE 2560 Segments 2 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/3b9b96bf_vg/lv7a6430c7 LV Name lv7a6430c7 VG Name 3b9b96bf_vg LV UUID UlFd4y-huNe-Z501-EylQ-mOd6-kAGt-jmvlqa LV Write Access read/write LV Creation host, time , LV Status NOT available LV Size 1.00 TiB Current LE 262144 Segments 1 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/3b9b96bf_vg/lv47d612ce LV Name lv47d612ce VG Name 3b9b96bf_vg LV UUID pzlrpE-dikm-6Rtn-GU6O-SeEx-3QJJ-cK3cdR LV Write Access read/write LV Creation host, time s-mars-stor-1, 2017-02-04 16:14:49 +0200 LV Status NOT available LV Size 1.32 TiB Current LE 345600 Segments 2 Allocation inherit Read ahead sectors auto --- Logical volume --- LV Path /dev/66e7945b_vg/vol1 LV Name vol1 VG Name 66e7945b_vg LV UUID No8Pga-YZaE-7ubV-NQ05-7fMh-DEa8-p1nP4c LV Write Access read/write LV Creation host, time , LV Status NOT available LV Size 20.01 GiB Current LE 5122 Segments 1 Allocation inherit Read ahead sectors auto
Из результата видно, что СХД собирала VG на LVM и дальше дробила на LV необходимых размеров.
root@mephistos-GA-880GA-UD3H:~# vgdisplay /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. --- Volume group --- VG Name 3b9b96bf_vg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 49 VG Access read/write VG Status resizable MAX LV 0 Cur LV 5 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 5.40 TiB PE Size 4.00 MiB Total PE 1415429 Alloc PE / Size 1135360 / 4.33 TiB Free PE / Size 280069 / 1.07 TiB VG UUID Qg8rb2-rQpK-zMRL-qVzm-RU5n-YNv8-qOV6yZ --- Volume group --- VG Name 66e7945b_vg System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 20.01 GiB PE Size 4.00 MiB Total PE 5122 Alloc PE / Size 5122 / 20.01 GiB Free PE / Size 0 / 0 VG UUID Sy2RsX-h51a-vgKt-n1Sb-u1CA-HBUf-C9sUNT
root@mephistos-GA-880GA-UD3H:~# lvscan /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. inactive '/dev/3b9b96bf_vg/lv6231c27b' [2.00 TiB] inherit inactive '/dev/3b9b96bf_vg/lv22a5c399' [3.00 GiB] inherit inactive '/dev/3b9b96bf_vg/lv13ed5d5e' [10.00 GiB] inherit inactive '/dev/3b9b96bf_vg/lv7a6430c7' [1.00 TiB] inherit inactive '/dev/3b9b96bf_vg/lv47d612ce' [1.32 TiB] inherit inactive '/dev/66e7945b_vg/vol1' [20.01 GiB] inherit
Активируем разделы и пробуем их смонтировать:
root@mephistos-GA-880GA-UD3H:~# modprobe dm-mod
root@mephistos-GA-880GA-UD3H:~# vgchange -ay /run/lvm/lvmetad.socket: connect failed: No such file or directory WARNING: Failed to connect to lvmetad. Falling back to internal scanning. 5 logical volume(s) in volume group "3b9b96bf_vg" now active 1 logical volume(s) in volume group "66e7945b_vg" now active
root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/1 root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/2 root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/3 root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/4 root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/5 root@mephistos-GA-880GA-UD3H:~# mkdir /mnt/6 root@mephistos-GA-880GA-UD3H:~# mount /dev/3b9b96bf_vg/lv6231c27b /mnt/1 root@mephistos-GA-880GA-UD3H:~# mount /dev/3b9b96bf_vg/lv22a5c399 /mnt/2 NTFS signature is missing. Failed to mount '/dev/mapper/3b9b96bf_vg-lv22a5c399': Invalid argument The device '/dev/mapper/3b9b96bf_vg-lv22a5c399' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? root@mephistos-GA-880GA-UD3H:~# mount /dev/3b9b96bf_vg/lv13ed5d5e /mnt/3 root@mephistos-GA-880GA-UD3H:~# mount /dev/3b9b96bf_vg/lv7a6430c7 /mnt/4 NTFS signature is missing. Failed to mount '/dev/mapper/3b9b96bf_vg-lv7a6430c7': Invalid argument The device '/dev/mapper/3b9b96bf_vg-lv7a6430c7' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? root@mephistos-GA-880GA-UD3H:~# mount /dev/3b9b96bf_vg/lv7a6430c7 /mnt/5 NTFS signature is missing. Failed to mount '/dev/mapper/3b9b96bf_vg-lv7a6430c7': Invalid argument The device '/dev/mapper/3b9b96bf_vg-lv7a6430c7' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? root@mephistos-GA-880GA-UD3H:~# mount /dev/3b9b96bf_vg/lv47d612ce /mnt/5 NTFS signature is missing. Failed to mount '/dev/mapper/3b9b96bf_vg-lv47d612ce': Invalid argument The device '/dev/mapper/3b9b96bf_vg-lv47d612ce' doesn't seem to have a valid NTFS. Maybe the wrong device is used? Or the whole disk instead of a partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around? root@mephistos-GA-880GA-UD3H:~# mount /dev/66e7945b_vg/vol1 /mnt/6
Как видим, только часть разделов смонтировалось. А всё потому, что на других разделах — VMFS.
Шаг №4
root@mephistos-GA-880GA-UD3H:/mnt/3# apt-get install vmfs-tools
Увы, но танцев с бубном избежать не удалось… напрямую VMFS монтировать не захотело (есть подозрение что это связано с новой версией VMFS и старыми vmfs-tools)
root@mephistos-GA-880GA-UD3H:/mnt/3# vmfs-fuse /dev/3b9b96bf_vg/lv7a6430c7 /mnt/4 VMFS VolInfo: invalid magic number 0x00000000 VMFS: Unable to read volume information Trying to find partitions Unable to open device/file "/dev/3b9b96bf_vg/lv7a6430c7". Unable to open filesystem
Перерыв кучу форумов, решение нашлось.
Создаем loop device:
losetup -r /dev/loop0 /dev/mapper/3b9b96bf_vg-lv47d612ce
Немного о kpartx можно почитать ТУТ.
root@triplesxi:~# apt-get install kpartx
root@triplesxi:~# kpartx -a -v /dev/loop0 add map loop0p1 (253:6): 0 2831153119 linear /dev/loop0 2048
Пробуем смонтировать получившийся маппер:
root@triplesxi:~# vmfs-fuse /dev/mapper/loop0p1 /mnt/vmfs/ VMFS: Warning: Lun ID mismatch on /dev/mapper/loop0p1 ioctl: Invalid argument ioctl: Invalid argument
Смонтировалось удачно! (на ошибки можно забить так как Lun ID mismatch)
Тут мы пропустим череду неудачных попыток скопировать, из смонтированного датастора, сами виртуальные машины.
Как оказалось, файлы размером в пару сотен гигабайт — скопировать нельзя:
root@triplesxi:~# cp /mnt/vmfs/tstst/tstst_1-flat.vmdk /root/ cp: error reading '/mnt/vmfs/tstst/tstst_1-flat.vmdk': Input/output error cp: failed to extend '/root/tstst_1-flat.vmdk': Input/output error
Шаг №5
Так как слить виртуальные машины из смонтированых датасторов не удалось… Попробуем подключить эти разделы к реальному ESXi и скопировать виртуалки через него (он то должен дружить с VMFS).
Подключим наши разделы к ESXi по средствам iSCSi (процесс опишем коротко):
1) Устанавливаем пакет iscsitarget
2) вносим необходимые параметры в /etc/iet/ietd.conf
3) Стартуем сервис service iscsitarget start
Если всё «ОК» — создаём на ESXi Software iSCSi controller и прописываем в Dynamic discovery наш сервер с примонтироваными разделами
Как видим разделы удачно подтянулись:

Так как LUN ID получившегося раздела не совпадает с тем что прописан в метаданных на самом разделе, для добавления датасторов к хосту — воспользуемся KB от VMware.
Датасторы восстановлены и с них спокойно можно сливать информацию.
P.S. Я сливаю по scp включив на сервере SSH доступ — это гораздо быстрее чем сливать виртуалку через веб или обычный клиент.
Шаг №6
Как восстановить саму СХД — ума не приложу. Если у кого-то есть файлы прошивки и информация как подключить консоль — с радостью приму помощь.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Используете ли вы резервное копирование?
28.4%Использую только для ряда сервисов23
4.94%Нет, не использую4
29.63%Использую для 100% сервисов24
27.16%Использую, но не проверяю целостность копий22
9.88%Я не боюсь падений СХД8
Проголосовал 81 пользователь. Воздержались 25 пользователей.
