突然关机后，我的主目录（XFS 分区）无法挂载，我可以用我的帐户登录系统。但我可以用 root 帐户登录（因为 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
在这种状态下，我挂载成功，并且我确实看到了几乎所有的文件和文件夹，但没有一个文件可以打开！
现在，我的问题如下：
- 有什么方法可以修复分区或恢复文件吗？否则我的文件就永远消失了 :(
- 有没有办法修复步骤 2 中的问题（我尝试的步骤），以便修复过程即使丢失一些数据也可以继续？例如强制 xfs_repair 忽略一些块！
非常感谢你们所有人的帮助。
答案1
xfs_metadump不会按设计复制数据。根据手册页
此工具最常见的使用场景是当 xfs_repair(8) 无法修复文件系统并且可以发送元转储图像进行分析时。
“发送分析”意味着付钱给某个对 XFS 了如指掌的人，让他提供恢复建议。可能是您的操作系统支持，但也可能是一家专门从事数据恢复的公司。向他们发送只有元数据的转储更容易，转储文件要小得多，而且可能删除了敏感文件名。
是时候进行成本效益分析了。您将花费多少时间和金钱来获取数据？例如，人们有自己喜欢的 DIY 工具，如何恢复出现“超级块读取失败”的 XFS 文件系统。dd_rescue尽可能多地从样式映像开始，以将副本安装到健康存储中并尝试安装副本。但是，采取的措施可能会进一步损坏损坏的文件系统。例如，像您所做的那样将日志归零。与自己动手相比，请购买专业软件和恢复服务。
答案2
根据 的输出，您可能存在潜在的物理磁盘错误xfs_repair -L。从您的问题来看，我猜想到目前为止备份并不是您的首要任务。无论您是否设法恢复任何数据，这都是您从现在开始应该改变的第一件事。
在进行任何类型的救援操作之前，克隆磁盘或分区可能是一个好主意。最坏的情况是，您可以尝试使用与dd您要保存的卷一样大或更大的设备。我相信其他工具也可能有用。以前 Clonezilla 是我的最爱，但我已经多年没用它了，所以我不知道它管理今天的系统有多好。