Восстановите раздел 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 содержит результаты научных расчетов, которые могут быть воспроизведены в течение нескольких недель и не подлежат резервному копированию. Хотя я не могу исключить возможность того, что некоторые невоспроизводимые данные могут остаться без внимания из-за халатности пользователя.
Мой план восстановления раздела был следующим:
- Воспроизведите журнал и смонтируйте раздел только для чтения.
- Скопируйте файлы, которые можно прочитать в другую файловую систему
- Определите блок с дубликатами ссылок, используя
jfs_fsck -v
- Идентифицируйте inode, соответствующие этим блокам:
jfs_debugfs
- Найдите объекты файловой системы, соответствующие inode, используя
find -inum
- Отсоедините объекты в целом, используя
jfs_debugfs
- Бежать
jfs_fsck
снова и надеюсь, что это будет завершено без ошибок
Этот план сработал только на этапах (1) - (4). Сначала это не удалось на этапе (5), где find
похоже, что после нескольких часов работы он не получил ни одного инода и мог работать вечно. При копировании файлов я обнаружил, что в некоторых каталогах их деревья B+ превратились в графы с циклами, поэтому было невозможно, чтобы обратный путь в каталогах не заканчивался.
Я перешел прямо к шагу (6) и сначала отсоединил каталоги, где мог найти поврежденные структуры. Но это не помогло сделать jfs_fsck
бежать до завершения. Затем я удалил все каталоги, кроме записи корневого каталога. Еще jfs_fsck
все еще не удалось завершить.
Думаю, мне нужно редактировать не только структуру каталогов, но и карты размещения блоков. Однако я не мог найти способ сделать это с jfs_debugfs
,
Существуют ли инструменты, которые могут помочь сделать раздел с дублирующимися ссылками на блоки пригодными для восстановления?
1 ответ
Если вы вообще можете смонтировать диск R/O, вы, вероятно, можете попытаться скопировать данные, которые сможете. Если журнал поврежден, возможно, потеряны только несколько последних изменений файла. Таким образом, вы можете попытаться получить файлы.
Однако, если файл представляет собой данные, как вы узнаете, если он вообще правильный или не был поврежден сам.
Конечно, повреждение журнала также может скрывать более серьезную проблему с диском.
На данный момент, я думаю, что для обеспечения целостности данных вам, вероятно, придется повторно запустить симуляции.