Контекст / оборудование:
Микросервер HP Gen8
1x1TB - автономный, 2x4TB Raid
1x16 ГБ iLO SDCARD с Debian + OpenMediaVault
Мероприятие:
Ошибка SDCARD
перезапустил сервер и установил Ubuntu на диск емкостью 1 ТБ
Последствия:
ZFS больше не доступен
root@fremen:~# sudo lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME FSTYPE SIZE MOUNTPOINT LABEL
sda zfs_member 931,5G
└─sda1 ext4 931,5G /
sdb zfs_member 3,7T
└─sdb1 zfs_member 3,7T
sdc zfs_member 3,7T
└─sdc1 zfs_member 3,7T
sdd 5,7G
root@fremen:~# zpool import -D -f
no pools available to import
root@fremen:~# file -s /dev/sd?1
/dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=9c46f52c-b529-4c39-a23b-819726f79146 (needs journal recovery) (extents) (64bit) (large files) (huge files)
/dev/sdb1: data
/dev/sdc1: data
Кажется, что диски все еще находятся в пуле ZFS, но данные недоступны.
Что делать в этой ситуации? Это установка друга, и я могу удаленно подключиться к машине. Я не хочу создавать новый пул, так как он уничтожит данные на томах ZFS. Поскольку я не могу найти пулы на дисках, zdb использовать нельзя.
Комментарии Майкла Хэмптона были решением этой проблемы.
Оказывается, OMV на самом деле вообще не использовала ZFS, а просто пометила диски как члены ZFS.
У меня есть dd-ed один из дисков и на образе я запустил testdisk. Оказалось, что на диске есть раздел 0x0700. Написал новую таблицу разделов с помощью testdisk и смонтировал ее в цикле. Оказалось, что это раздел ext4 с поврежденным журналом. После исправления ошибок мне удалось спасти все данные. Следовательно, я сделал то же самое с физическими дисками, вернул данные.