Усеченный файл в файловой системе XFS с использованием dd — как восстановить

Разметка диска Мой рейдовый массив жестких дисков подходит к концу, и я купил для него несколько новых дисков. Старый жесткий диск, который я использовал в качестве хранилища необработанных образов дисков для виртуальных машин kvm/qemu. Массив Raid был построен с использованием mdadm. На устройстве md у меня есть физический том для LVM. На физическом томе у меня есть файловая система XFS, в которой хранятся необработанные образы дисков. Каждый необработанный образ диска был создан qemu-img и содержит физический том для LVM. Один PV = один LV = один VG внутри необработанного образа диска.

Действие Когда я попытался использовать cp для перемещения данных, я столкнулся с плохими блоками и проблемами ввода-вывода в моем массиве рейдов, поэтому я переключился с cp на dd без ошибок, флаги синхронизации я написал dd if=/mnt/old/file.img of=/mnt/**old**/file.img bs=4k conv=noerror,sync

Проблема Теперь файл /mnt/old/file.img имеет нулевой размер в файловой системе XFS. Есть ли простое решение для его восстановления?


truncate recover dd xfs
person Andrey Ivanov    schedule 04.06.2020    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я чувствую, что ваш RAID-массив вышел из строя. Вы можете увидеть состояние RAID с помощью...

 cat /proc/mdstat

Поскольку вы видите ошибки ввода-вывода, это, вероятно, является источником вашей проблемы. Наилучшим путем вперед будет создание копий на уровне секторов каждого члена RAID (или, как минимум, элементов, которые выдают ошибки ввода-вывода). См. Linux ddrescue. Он предназначен для копирования неисправных жестких дисков. Затем выполните восстановление из копий.

person S.Haran    schedule 06.06.2020
comment
Мой статус RAID не имеет смысла для проблемы, потому что данные повреждены на уровне файловой системы - файл был усечен командой dd с if == of. Вероятно, я нашел способ восстановить файл с помощью журнала транзакций XFS и низкоуровневых модификаций файловой системы с помощью xfs_db. Моя идея состоит в том, чтобы восстановить запись inode из журнала в предположении, что никакие данные не изменены, кроме основной записи inode. Если я смогу правильно восстановить свой файл, я напишу свою историю успеха. - person Andrey Ivanov; 08.06.2020

arrow_upward
0
arrow_downward

Наконец-то я нашел решение, но оно не очень простое.

Xfs_undelete не решил мою проблему, потому что не поддерживает формат хранения экстентов B+Tree (V3) для очень больших файлов.

Успешная полуручная процедура, которая успешно решила мою проблему, состоит из следующих основных шагов:

  1. Немедленно размонтируйте файловую систему и сделайте полную резервную копию раздела, используя dd в файл
  2. Изучите записи журнала XFS об усеченном файле
  3. Вернуть вручную заголовок ядра inode с помощью xfs_db в экспертном режиме MB. Восстановление ядра индексного дескриптора не приведет к удалению экстентов как несвободных, и при попытке скопировать некоторые данные обычным способом из файла с восстановленным заголовком индексного дескриптора вы получите ошибку ввода-вывода. Это послужило причиной для разработки скрипта Python.
  4. Используйте скрипт, который извлекает данные экстентов из дерева B+Tree для inode и записывает их на диск

Я опубликовал сценарий восстановления под лицензией LGPL на GitHub.

P.S. Некоторые данные были потеряны из-за поврежденных записей экстента inode b+tree, но для меня они не имеют смысла.

person Andrey Ivanov    schedule 08.06.2020