После внезапного выключения мой домашний каталог, который является разделом XFS, не может быть смонтирован, и я могу войти в систему со своей учетной записью. Но я могу войти в систему с учетной записью root (поскольку корневой и домашний каталоги разделены). Моя ОС - это OpenSuse thumbleweed.
Я попробовал следующие шаги, чтобы восстановить свой домашний раздел:
1- Попытка смонтировать раздел вручную:
# mount /dev/sda4 /home
и я вижу эту ошибку: can't read superblock.
2- Попытка отремонтировать xfs_repair:
# xfs_repair /dev/sda4
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair. If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
После этого я запускаю команду с -L вариант:
# xfs_repair -L /dev/sda4
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
agi unlinked bucket 3 is 247427 in ag 0 (inode=247427)
agi unlinked bucket 51 is 115 in ag 0 (inode=115)
agi unlinked bucket 27 is 105361179 in ag 2 (inode=1179103003)
agi unlinked bucket 53 is 147510965 in ag 2 (inode=1221252789)
sb_icount 9534016, counted 9534272
sb_ifree 1508, counted 2201
sb_fdblocks 12934900, counted 13126723
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
imap claims a free inode 407153 is in use, correcting imap and clearing inode
cleared inode 407153
data fork in ino 14927433 claims free block 1865944
correcting imap
- agno = 1
data fork in regular inode 540301004 claims used block 75087592
correcting nextents for inode 540301004
bad data fork in inode 540301004
cleared inode 540301004
correcting imap
- agno = 2
- agno = 3
xfs_repair: read failed: Input/output error
cannot read inode 1900567232, disk block 1512628928, cnt 32
Aborted (core dumped)
Я пробовал эту команду более 3 раз (без опции -L) и каждый раз вижу одну и ту же ошибку.
4- Использование xfs_metadump скопировать мета раздела и использовать его для восстановления данных (на основе этой статьи: https://www.suse.com/support/kb/doc/?id=000018858):
# xfs_metadump -aowg /dev/sda4 /tmp/dump_xfs_meta
Copied 2011648 of 9534272 inodes (1 of 4 AGs) Unknown directory buffer type!
Unknown directory buffer type!
Copied 9243200 of 9534272 inodes (3 of 4 AGs) xfs_metadump: read failed: Input/output error
xfs_metadump: cannot read inode block 3/36244312
Copied 9246656 of 9534272 inodes (3 of 4 AGs) xfs_metadump: read failed: Input/output error
xfs_metadump: cannot read inode block 3/36416788
Copied 9251776 of 9534272 inodes (3 of 4 AGs) xfs_metadump: error - read only 16384 of 32768 bytes
xfs_metadump: cannot read inode block 3/36437896
Copied 9279808 of 9534272 inodes (3 of 4 AGs) xfs_metadump: error - read only 8192 of 32768 bytes
xfs_metadump: cannot read inode block 3/36723656
Copied 9292736 of 9534272 inodes (3 of 4 AGs) xfs_metadump: error - read only 16384 of 32768 bytes
xfs_metadump: cannot read inode block 3/36818108
Copied 9332032 of 9534272 inodes (3 of 4 AGs) xfs_metadump: read failed: Input/output error
xfs_metadump: cannot read inode block 3/37269284
Copying log
Тем не менее, я продолжил команды в статье следующим образом:
# xfs_mdrestore /tmp/dump_xfs_meta /tmp/workable_xfs_dump
# xfs_repair /tmp/workable_xfs_dump
# mount /tmp/workable_xfs_dump /mnt/test
В этом состоянии монтирование прошло успешно, и я видел почти файлы и папки, но ни один из файлов не мог быть открыт!
А теперь вот мои вопросы:
Спасибо всем уже за вашу помощь.
xfs_metadump не копирует данные намеренно. На странице руководства
Наиболее распространенный сценарий использования этого инструмента - когда xfs_repair (8) не может восстановить файловую систему и образ метадамп может быть отправлен на анализ.
«Отправлено на анализ» означает оплату того, кто хорошо разбирается в XFS, за консультацию по восстановлению. Возможно, ваша операционная система поддерживает, но, скорее всего, это компания, специализирующаяся на восстановлении данных. Легче отправить им дамп только метаданных, гораздо меньшего размера и, возможно, с удаленными конфиденциальными именами файлов.
Время для анализа затрат и выгод. Сколько времени и денег вы потратите на свои данные? Люди предпочитают инструменты "Сделай сам", например Как восстановить файловую систему XFS с ошибкой чтения суперблока. Начиная с dd_rescue как можно больше скопируйте образ в здоровое хранилище и попытайтесь смонтировать копию. Однако существует риск того, что предпринятые действия еще больше повредят поврежденную файловую систему. Например, обнуление журнала, как вы это сделали. Снижайте цены на профессиональное программное обеспечение и услуги по восстановлению, а не делаете это самостоятельно.
У вас может быть основная ошибка физического диска, основанная на выводе из xfs_repair -L. Из вашего вопроса я полагаю, что резервное копирование не было для вас приоритетом. Это действительно первое, что вам следует изменить с этого момента, независимо от того, удастся ли вам восстановить какие-либо данные.
Вероятно, будет хорошей идеей клонировать диск или раздел, прежде чем приступать к какой-либо операции восстановления. В худшем случае вы можете попробовать dd на устройство, которое больше или больше, чем объем, который вы пытаетесь сохранить. Я уверен, что другие инструменты тоже могут быть полезны. Когда-то мне нравилась Clonezilla, но я не использовал ее много лет, поэтому не знаю, насколько хорошо она управляет сегодняшними системами.