Восстановите раздел JFS с дублирующимися ссылками на блоки

После неприятного сбоя сервера я не смог смонтировать раздел JFS в Linux. jfs_fsck возврат инструмента

Duplicate block references have been detected in Metadata.  CANNOT CONTINUE.
processing terminated:  <date> <time>  with return code: 10060  exit code: 4.

Раздел 12TB содержит результаты научных расчетов, которые могут быть воспроизведены в течение нескольких недель и не подлежат резервному копированию. Хотя я не могу исключить возможность того, что некоторые невоспроизводимые данные могут остаться без внимания из-за халатности пользователя.

Мой план восстановления раздела был следующим:

  1. Воспроизведите журнал и смонтируйте раздел только для чтения.
  2. Скопируйте файлы, которые можно прочитать в другую файловую систему
  3. Определите блок с дубликатами ссылок, используя jfs_fsck -v
  4. Идентифицируйте inode, соответствующие этим блокам: jfs_debugfs
  5. Найдите объекты файловой системы, соответствующие inode, используя find -inum
  6. Отсоедините объекты в целом, используя jfs_debugfs
  7. Бежать jfs_fsck снова и надеюсь, что это будет завершено без ошибок

Этот план сработал только на этапах (1) - (4). Сначала это не удалось на этапе (5), где find похоже, что после нескольких часов работы он не получил ни одного инода и мог работать вечно. При копировании файлов я обнаружил, что в некоторых каталогах их деревья B+ превратились в графы с циклами, поэтому было невозможно, чтобы обратный путь в каталогах не заканчивался.

Я перешел прямо к шагу (6) и сначала отсоединил каталоги, где мог найти поврежденные структуры. Но это не помогло сделать jfs_fsck бежать до завершения. Затем я удалил все каталоги, кроме записи корневого каталога. Еще jfs_fsck все еще не удалось завершить.

Думаю, мне нужно редактировать не только структуру каталогов, но и карты размещения блоков. Однако я не мог найти способ сделать это с jfs_debugfs,

Существуют ли инструменты, которые могут помочь сделать раздел с дублирующимися ссылками на блоки пригодными для восстановления?

1 ответ

Если вы вообще можете смонтировать диск R/O, вы, вероятно, можете попытаться скопировать данные, которые сможете. Если журнал поврежден, возможно, потеряны только несколько последних изменений файла. Таким образом, вы можете попытаться получить файлы.

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

Конечно, повреждение журнала также может скрывать более серьезную проблему с диском.

На данный момент, я думаю, что для обеспечения целостности данных вам, вероятно, придется повторно запустить симуляции.

Другие вопросы по тегам