Назад | Перейти на главную страницу

MD, частично увеличенный с RAID1 до RAID5, но был прерван, диски удалены, и теперь файловая система FUBAR

Я знаю, что сделал несколько глупых шагов, чтобы попасть в эту ситуацию, пожалуйста, не напоминайте мне и не спрашивайте, почему: - /

У меня есть Synology DS1515 + с 2 дисками по 6 ТБ в SHR, что означает MD RAID1 с LVM сверху.

После запуска преобразования RAID1 в RAID5, его прерывания и возни с диском моя файловая система ext4 не может быть подключена.

Возможно ли, что система просто была «сбита с толку» из-за множества перезагрузок и извлечения дисков и теперь обрабатывает все дисковое пространство как том RAID5, даже если преобразование из RAID1 в RAID5 было завершено только на 10%? Если да, то как вы думаете, у меня есть шанс исправить файловую систему, если я добавлю третий диск и позволю восстановить массив RAID? Или он просто будет перекомпонован на логический том с теми же данными, что и сейчас, то есть с поврежденной файловой системой?

Мне немного любопытно, как происходит фактический процесс преобразования, поскольку MD и / или LVM должны знать, какие части блочных устройств следует рассматривать как RAID5 или RAID1, пока все пространство не будет преобразовано в RAID5. Кто-нибудь знает об этом больше?

Заранее благодарю за любую помощь :-)

Вот что я сделал. (Мои попытки восстановления и записи журнала перечислены ниже)

  1. Подключил к NAS в горячем режиме новый диск емкостью 6 ТБ.

  2. Сказал пользовательскому интерфейсу Synology добавить диск в мой существующий том и увеличить его до 12 ТБ (превращая его в RAID5 размером 3x6 ТБ)

  3. Выключите NAS (shutdown -P now) несколько ваших в процессе роста и удалите новый диск. NAS загрузился хорошо, но сообщил, что мой том снизился. Он по-прежнему сообщил о файловой системе 6 ТБ, и все было по-прежнему доступно.

  4. Снова подключил диск 3 в горячем режиме, протер его и сделал на нем еще один том.

  5. Выключите NAS, извлеките диск 2 (это была ошибка!) И включите его. Он начал пищать и сказал мне, что мой том разбился.

  6. Снова выключите NAS и снова вставьте отсутствующий disk2. Но Synology по-прежнему сообщала о том, что том сломался, и не предлагала вариантов ремонта.

Итак, все мои данные теперь недоступны!

Я начал исследовать проблему. Вроде как MD собирает массив как надо:

 State : clean, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : DiskStation:2  (local to host DiskStation)
           UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
         Events : 31429

    Number   Major   Minor   RaidDevice State
       0       8        5        0      active sync   /dev/sda5
       1       8       21        1      active sync   /dev/sdb5
       2       0        0        2      removed

И метаданные на двух исходных дисках тоже выглядят нормально:

Device Role : Active device 0
Array State : AA. ('A' == active, '.' == missing)

Device Role : Active device 1
Array State : AA. ('A' == active, '.' == missing)

LVM также распознает том RAID5 и раскрывает его устройство:

--- Logical volume ---
LV Path                /dev/vg1000/lv
LV Name                lv
VG Name                vg1000

Но файловая система на / dev / vg1000 / lv кажется поврежденной, когда я пытаюсь смонтировать ее только для чтения:

mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program)  
In some cases useful info is found in syslog - try dmesg | tail or so.

Итак, у меня сломанная файловая система, которую, как мне кажется, невозможно восстановить (см. Список моих попыток ниже).

Вот шаги, которые я пробовал до сих пор:

Клонировал / dev / vg1000 / lv в раздел на пустом жестком диске и запустил e2fsck У меня этот процесс работал неделю, прежде чем я его прервал. Он обнаружил миллион неисправных индексных дескрипторов, блоков с множественными запросами и т. Д., И с таким количеством ошибок FS я считаю, что он не вернет никаких полезных данных, даже если он когда-нибудь завершится.

Переместил два жестких диска с данными в док-станцию ​​USB, подключил его к виртуальной машине Ubuntu и сделал оверлейные устройства для перехвата всех записей (с помощью dmsetup)

Сначала я попытался воссоздать массив рейдов. Я начал с поиска команды, которая создала массив с теми же параметрами и mdadm -E, уже предоставленными мне, а затем я попытался изменить порядок, чтобы увидеть, отличаются ли результаты (т.е. sda, missing, sdb, sda, sdb, missing , отсутствует, sdb, sda). В 4 из 6 комбинаций LVM обнаружил группу томов, но файловая система все еще была сломана.

Использовал R-Studio для сборки массива и поиска файловых систем

Это на самом деле дало несколько результатов - он смог просканировать и найти файловую систему EXT4 на томе RAID, который я собрал, и я мог просматривать файлы, но только часть (например, 10) моих фактических файлов была представлена ​​в файле зритель. Я попытался изменить порядок устройства, и хотя 4 комбинации заставили R-Studio обнаруживать файловую систему ext4 (как указано выше), только исходная настройка (sda, sdb, missing) позволила R-studio обнаруживать любые файлы. из корня диска.

Пробовал монтировать с -o sb = XXXXX, указывая на альтернативный суперблок

Это дало мне те же ошибки, что и не указание позиции суперблока.

Пробовал debugfs

Когда я набирал "ls", у меня возникали ошибки ввода-вывода.

Вот сообщения журнала для операций, описанных выше, которые вызвали проблемы.

Выключение системы, которая работала как деградированный RAID5, но файловая система все еще работала.

2017-02-25T18:13:27+01:00 DiskStation umount: kill the process "synoreport" [pid = 15855] using /volume1/@appstore/StorageAnalyzer/usr/syno/synoreport/synoreport
2017-02-25T18:13:28+01:00 DiskStation umount: can't umount /volume1: Device or resource busy
2017-02-25T18:13:28+01:00 DiskStation umount: can't umount /volume1: Device or resource busy
2017-02-25T18:13:28+01:00 DiskStation umount: SYSTEM:   Last message 'can't umount /volume' repeated 1 times, suppressed by syslog-ng on DiskStation
2017-02-25T18:13:28+01:00 DiskStation syno_poweroff_task: lvm_poweroff.c:49 Failed to /bin/umount -f -k /volume1
2017-02-25T18:13:29+01:00 DiskStation syno_poweroff_task: lvm_poweroff.c:58 Failed to /sbin/vgchange -an
2017-02-25T18:13:29+01:00 DiskStation syno_poweroff_task: raid_stop.c:28 Failed to mdadm stop '/dev/md2'
2017-02-25T18:13:29+01:00 DiskStation syno_poweroff_task: syno_poweroff_task.c:331 Failed to stop RAID [/dev/md2]

Отметьте «не удалось остановить RAID» - это возможная причина проблем?

Первая загрузка после удаления disk2 (sdb) 

2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.467975] set group disks wakeup number to 5, spinup time deno 1
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.500561] synobios: unload
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.572388] md: invalid raid superblock magic on sda5
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.578043] md: sda5 does not have a valid v0.90 superblock, not importing!
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.627381] md: invalid raid superblock magic on sdc5
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.633034] md: sdc5 does not have a valid v0.90 superblock, not importing!
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.663832] md: sda2 has different UUID to sda1
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.672513] md: sdc2 has different UUID to sda1
2017-02-25T18:15:27+01:00 DiskStation kernel: [   10.784571] Got empty serial number. Generate serial number from product.


2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md3
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.339243] md/raid:md2: not enough operational devices (2/3 failed)
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.346371] md/raid:md2: raid level 5 active with 1 out of 3 devices, algorithm 2
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.355295] md: md2: set sda5 to auto_remap [1]
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.355299] md: reshape of RAID array md2
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: spacetool.c:1223 Try to force assemble RAID [/dev/md2]. [0x2000 file_get_key_value.c:81]
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.414839] md: md2: reshape done.
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.433218] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.494964] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.549962] md/raid:md2: not enough operational devices (2/3 failed)
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.557093] md/raid:md2: raid level 5 active with 1 out of 3 devices, algorithm 2
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.566069] md: md2: set sda5 to auto_remap [1]
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.566073] md: reshape of RAID array md2
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md2
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.633774] md: md2: reshape done.
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.645025] md: md2: change number of threads from 0 to 1
2017-02-25T18:15:41+01:00 DiskStation kernel: [   31.645033] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [Fund9t-vUVR-3yln-QYVk-8gtv-z8Wo-zz1bnF]
2017-02-25T18:15:41+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1001], New vg path: [/dev/vg1001], UUID: [FHbUVK-5Rxk-k6y9-4PId-cSMf-ztmU-DfXYoL]

2017-02-25T18:22:50+01:00 DiskStation umount: can't umount /volume2: Invalid argument
2017-02-25T18:22:50+01:00 DiskStation syno_poweroff_task: lvm_poweroff.c:49 Failed to /bin/umount -f -k /volume2
2017-02-25T18:22:50+01:00 DiskStation kernel: [  460.374192] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:22:50+01:00 DiskStation kernel: [  460.404747] md: md3: set sdc5 to auto_remap [0]
2017-02-25T18:28:01+01:00 DiskStation umount: can't umount /initrd: Invalid argument

Снова загрузка, снова присутствует disk2 (sdb)

2017-02-25T18:28:17+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md3
2017-02-25T18:28:17+01:00 DiskStation kernel: [   32.442352] md: kicking non-fresh sdb5 from array!
2017-02-25T18:28:17+01:00 DiskStation kernel: [   32.478415] md/raid:md2: not enough operational devices (2/3 failed)
2017-02-25T18:28:17+01:00 DiskStation kernel: [   32.485547] md/raid:md2: raid level 5 active with 1 out of 3 devices, algorithm 2
2017-02-25T18:28:17+01:00 DiskStation spacetool.shared: spacetool.c:1223 Try to force assemble RAID [/dev/md2]. [0x2000 file_get_key_value.c:81]
2017-02-25T18:28:17+01:00 DiskStation kernel: [   32.515567] md: md2: set sda5 to auto_remap [0]
2017-02-25T18:28:18+01:00 DiskStation kernel: [   32.602256] md/raid:md2: raid level 5 active with 2 out of 3 devices, algorithm 2
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md2
2017-02-25T18:28:18+01:00 DiskStation kernel: [   32.654279] md: md2: change number of threads from 0 to 1
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [Fund9t-vUVR-3yln-QYVk-8gtv-z8Wo-zz1bnF]
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1001], New vg path: [/dev/vg1001], UUID: [FHbUVK-5Rxk-k6y9-4PId-cSMf-ztmU-DfXYoL]
2017-02-25T18:28:18+01:00 DiskStation spacetool.shared: spacetool.c:3030 [Info] Activate all VG

2017-02-25T18:28:18+01:00 DiskStation synovspace: virtual_space_conf_check.c:78 [INFO] "PASS" checking configuration of virtual space [FCACHE], app: [1]
2017-02-25T18:28:18+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [HA]
2017-02-25T18:28:18+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [SNAPSHOT_ORG]
2017-02-25T18:28:18+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume2] / [/dev/vg1001/lv]
2017-02-25T18:28:18+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume1] / [/dev/vg1000/lv]
2017-02-25T18:28:19+01:00 DiskStation kernel: [   33.792601] BTRFS: has skinny extents
2017-02-25T18:28:19+01:00 DiskStation kernel: [   34.009184] JBD2: no valid journal superblock found
2017-02-25T18:28:19+01:00 DiskStation kernel: [   34.014673] EXT4-fs (dm-0): error loading journal
mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
quotacheck: Mountpoint (or device) /volume1 not found or has no quota enabled.
quotacheck: Cannot find filesystem to check or filesystem not mounted with quota option.
quotaon: Mountpoint (or device) /volume1 not found or has no quota enabled.
2017-02-25T18:28:19+01:00 DiskStation synocheckhotspare: synocheckhotspare.c:149 [INFO] No hotspare config, skip hotspare config check. [0x2000 virtual_space_layer_get.c:98]
2017-02-25T18:28:19+01:00 DiskStation synopkgctl: pkgtool.cpp:3035 package AudioStation is not installed or not operable

Заметьте, как сначала говорится, что присутствует 1 из 3 устройств, но потом происходит принудительная сборка, так что RAID-массив собирается, а затем пытается смонтировать его, но выдает ошибки монтирования EXT4.

Пытался перезагрузиться после этого опыта, не помогло

2017-02-25T18:36:45+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md3
2017-02-25T18:36:45+01:00 DiskStation kernel: [   29.579136] md/raid:md2: raid level 5 active with 2 out of 3 devices, algorithm 2
2017-02-25T18:36:45+01:00 DiskStation spacetool.shared: raid_allow_rmw_check.c:48 fopen failed: /usr/syno/etc/.rmw.md2
2017-02-25T18:36:45+01:00 DiskStation kernel: [   29.629837] md: md2: change number of threads from 0 to 1
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1000], New vg path: [/dev/vg1000], UUID: [Fund9t-vUVR-3yln-QYVk-8gtv-z8Wo-zz1bnF]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3023 [Info] Old vg path: [/dev/vg1001], New vg path: [/dev/vg1001], UUID: [FHbUVK-5Rxk-k6y9-4PId-cSMf-ztmU-DfXYoL]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3030 [Info] Activate all VG
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3041 Activate LVM [/dev/vg1000]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3041 Activate LVM [/dev/vg1001]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3084 space: [/dev/vg1000]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3084 space: [/dev/vg1001]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3110 space: [/dev/vg1000], ndisk: [2]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: spacetool.c:3110 space: [/dev/vg1001], ndisk: [1]
2017-02-25T18:36:46+01:00 DiskStation spacetool.shared: hotspare_repair_config_set.c:36 Failed to hup synostoraged
2017-02-25T18:36:46+01:00 DiskStation synovspace: virtual_space_conf_check.c:78 [INFO] "PASS" checking configuration of virtual space [FCACHE], app: [1]
2017-02-25T18:36:46+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [HA]
2017-02-25T18:36:46+01:00 DiskStation synovspace: virtual_space_conf_check.c:74 [INFO] No implementation, skip checking configuration of virtual space [SNAPSHOT_ORG]
2017-02-25T18:36:46+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume2] / [/dev/vg1001/lv]
2017-02-25T18:36:46+01:00 DiskStation synovspace: vspace_wrapper_load_all.c:76 [INFO] No virtual layer above space: [/volume1] / [/dev/vg1000/lv]
2017-02-25T18:36:47+01:00 DiskStation kernel: [   30.799110] BTRFS: has skinny extents
2017-02-25T18:36:47+01:00 DiskStation kernel: [   30.956115] JBD2: no valid journal superblock found
2017-02-25T18:36:47+01:00 DiskStation kernel: [   30.961585] EXT4-fs (dm-0): error loading journal
mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
quotacheck: Mountpoint (or device) /volume1 not found or has no quota enabled.
quo

Как я сохранил свои данные после полного взлома растущего RAID5!

У меня есть 3-дисковый массив RAID5 с отсутствующим устройством номер 3 и данными, которые кажутся поврежденными.

/ dev / sdd5: (5,45 ТиБ) 6 ТБ, устройство 1 массива

/ dev / sdd5: (5,45 ТиБ) 6 ТБ, устройство 2 массива

Массив находится в процессе преобразования из RAID1 в RAID5, когда операция была прервана и устройство 3 было удалено. Массив все еще работал, пока не было удалено устройство 2. Когда устройство 2 было возвращено, файловая система не могла быть смонтирована. Было клонировано устройство / dev / md2, и на клонированном разделе была запущена команда fsck, которая обнаружила миллионы ошибок.

Очевидно, MD не обрабатывал данные RAID должным образом после прерванного преобразования и удаления дисков. Я пошел расследовать случившееся:

Сначала я взглянул на /var/log/space_operation_error.log и он сказал мне, что именно произошло. RAID изменил свой статус на сломанный, как только Диск 2 был удален, так как RAID5 с 3 дисками не может работать с 1 диском. Но это также заставило RAID забыть о его продолжающемся преобразовании с RAID1 на RAID5.

Поэтому я подумал, что повреждение данных может быть вызвано тем, что MD обрабатывает все данные как закодированные в RAID5, в то время как их часть все еще находится в исходном состоянии.

Изучение данных RAID устройств мне не помогло, все выглядело нормально:

# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md124 : active raid5 sda5[0] sdb5[1]
      11711575296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/2] [UU_]

# mdadm -E /dev/sda5
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
           Name : DiskStation:2
  Creation Time : Thu Nov 27 11:35:34 2014
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 11711575680 (5584.51 GiB 5996.33 GB)
     Array Size : 23423150592 (11169.03 GiB 11992.65 GB)
  Used Dev Size : 11711575296 (5584.51 GiB 5996.33 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 1a222812:ac39920b:4cec73c4:81aa9b63

    Update Time : Fri Mar 17 23:14:25 2017
       Checksum : cb34324c - correct
         Events : 31468

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AA. ('A' == active, '.' == missing)

Но я подумал, что у него ДОЛЖЕН быть какой-то счетчик, чтобы отслеживать его прогресс во время преобразования. Я изучал формат суперблока MD, описанный здесь: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats

Я взял копию первых 10 MiB одного из разделов RAID (mdadm -E не работал на меньших копиях):

# dd if=/dev/sda5 of=/volume1/homes/sda5_10M.img bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0622844 s, 168 MB/s

Я открыл его в HEX-редакторе и изменил данные в байте 4104 с 0x00 на 0x04, чтобы указать, что происходит изменение формы.

Я также отметил значение 8 байтов, начиная с 4200. Оно читается как 3856372992.

Сохранив изменение, я изучил копию:

# mdadm -E /volume1/homes/sda5_10M.img
/volume1/homes/sda5_10M.img:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x4
     Array UUID : 58290cba:75757ee2:86fe074c:ada2e6d2
           Name : DiskStation:2
  Creation Time : Thu Nov 27 11:35:34 2014
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 11711575680 (5584.51 GiB 5996.33 GB)
     Array Size : 23423150592 (11169.03 GiB 11992.65 GB)
  Used Dev Size : 11711575296 (5584.51 GiB 5996.33 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 1a222812:ac39920b:4cec73c4:81aa9b63

  Reshape pos'n : 1928186496 (1838.86 GiB 1974.46 GB)
  Delta Devices : 1 (2->3)

    Update Time : Fri Mar 17 23:14:25 2017
       Checksum : cb34324c - expected cb343250
         Events : 31468

         Layout : left-symmetric
     Chunk Size : 64K

   Device Role : Active device 0
   Array State : AA. ('A' == active, '.' == missing)

Как вы можете видеть, он сообщил о точном положении процесса изменения формы - что также говорит мне, что число, которое я получил ранее, было числом 512-байтовых секторов.

Теперь, зная, что первые 1838,86 ГиБ были перезаписаны во время преобразования, я предположил, что остальные разделы остались нетронутыми.

Поэтому я решил собрать блочное устройство из новой части RAID5 и нетронутой части, вырезав ее в указанной позиции respape (прочтите примечания ниже о принятии позиции). Поскольку смещение данных составляет 2048 секторов, мне нужно добавить 1024 КБ к размеру, чтобы получить смещение необработанной части раздела: 

#losetup -f --show /dev/md124 --sizelimit=1928186496K
/dev/loop0

#losetup -f --show /dev/sda5 --offset=1928187520K 
/dev/loop1

Для сборки деталей я создал устройство JBOD без метаданных:

# mdadm --build --raid-devices=2 --level=linear /dev/md9 /dev/loop0 /dev/loop1
mdadm: array /dev/md9 built and started.

Затем я проверил содержимое нового устройства / dev / md9

# file -s /dev/md9
/dev/md9: LVM2 PV (Linux Logical Volume Manager), UUID: xmhBdx-uED6-hN53-HOeU-ONy1-29Yc-VfIDQt, size: 5996326551552

Поскольку RAID содержал том LVM, мне нужно было пропустить первые 576 КБ, чтобы перейти к файловой системе ext4:

# losetup -f --show /dev/md9 --offset=576K
/dev/loop2

# file -s /dev/loop2
/dev/loop2: Linux rev 1.0 ext4 filesystem data, UUID=8e240e88-4d2b-4de8-bcaa-0836f9b70bb5, volume name "1.42.6-5004" (errors) (extents) (64bit) (large files) (huge files)

Теперь я смонтировал файловую систему в общую папку на моем NAS:

# mount -o ro,noload /dev/loop2 /volume1/homes/fixraid/

И мои файлы были доступны!

Прежде чем я определился с размером позиции / смещениями, использованными выше, я попробовал несколько значений. Моя первая идея заключалась в том, что, поскольку 1838,86 ГиБ каждого устройства были изменены, часть RAID5 будет содержать ~ 3,6 ТиБ допустимых данных, и я использовал позицию, которая была двойной позиции изменения формы. Он смонтирован нормально, но некоторые из моих файлов, похоже, содержат недопустимые данные, некоторые файлы выдают ошибки ввода-вывода при чтении, а некоторые папки отсутствуют.

Поскольку у меня было много фотографий RAW в формате NEF (Nikon), я решил протестировать некоторые из них с помощью файлового инструмента.

Ожидаемый результат:

# file DSC_7421.NEF
DSC_7421.NEF: TIFF image data, little-endian, direntries=28, height=120, bps=352, compression=none, PhotometricIntepretation=RGB, manufacturer=NIKON CORPORATION, model=NIKON D750, orientation=upper-left, width=160

Результат при повреждении данных:

# file DSC_9974.NEF
DSC_9974.NEF: data

У меня также было несколько ошибок ввода-вывода, когда я писал ls в определенных папках.

Я решил перейти к некоторым из моих больших коллекций фотографий и проверить их целостность - сначала перечислив файлы и посчитав количество строк в выводе. Все ошибки чтения должны быть записаны на экран. Затем, проверяя, не был ли какой-либо из файлов NEF нераспознан, указываются поврежденные данные. Я отфильтровал вывод из файла и подсчитал отфильтрованные строки.

# ls *.NEF -1 | wc -l
3641
# file *.NEF | grep "NEF: data" | wc -l
0

Я сделал это для многих папок с фотографиями, чтобы все файлы были доступны для чтения и их содержимое распознавалось.

Используя размер 3856372992K и смещение 3856374016K, я получил много недопустимых данных и отсутствующих файлов / папок, и я попробовал несколько других значений.

Я обнаружил, что смещение и размер, упомянутые выше, прошли мои небольшие тесты.!

Как видно выше, файловая система сообщает о некоторых ошибках. Поскольку я не хочу записывать какие-либо данные на свои устройства до того, как все будет восстановлено, я решил сделать наложение записи моментального снимка, чтобы все записи, сделанные fsck.ext4, вместо этого записывались в этот файл.

Создайте разреженный файл размером 50 ГБ

# truncate /volume1/overlay.img -s50G

Сделайте виртуальное устройство

#losetup -f --show /volume1/overlay.img 
/dev/loop3

Получите размер устройства с данными:

# blockdev --getsz /dev/loop2
11711574528

Создайте оверлейное устройство (перед этим я отключил файловую систему в / dev / loop2)

# dmsetup create overlay --table "0 11711574528 snapshot /dev/loop2 /dev/loop3 P 8"

И устройство было доступно в /dev/mapper/overlay

Наконец-то я смог проверить и исправить ошибки:

# fsck.ext4 -y -C 0 /dev/mapper/overlay

Обратите внимание, что исправления записываются только в файл оверлея и должны быть зафиксированы на физических дисках, если они должны быть постоянными.