Linux分区无法挂载(无法读取超级块)，原因是突然停电，xfs_repair: read :输入/输出错误
突然关闭后，我的主目录( XFS分区)无法挂载，我可以通过我的帐户登录到系统。但是我可以使用根帐户登录(因为根目录和主目录是分开的)。我的操作系统是OpenSuse大拇指草。
我尝试了以下步骤来恢复我的主分区：
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忽略一些块！
谢谢你的帮助。
回答 2
Server Fault用户
发布于 2020-07-07 17:42:29
xfs_metadump不按设计复制数据。根据手册页
这个工具最常见的使用场景是当xfs_repair(8)无法修复一个文件系统，并且可以发送一个元映像进行分析时。
“发送分析”的意思是付钱给了解XFS细节的人，为恢复提供建议。可能是您的操作系统支持，但可能是一家专门从事数据恢复的公司。更容易向它们发送元数据，仅转储，要小得多，并且可能删除敏感文件名。
是时候进行成本效益分析了。在时间和金钱上，你会花多少钱在你的数据上？人们有自己喜欢的工具，例如如何用“超级块读取失败”恢复XFS文件系统。从dd_rescue风格的映像开始，尽可能健康地存储并尝试挂载副本。但是，所采取的措施有可能进一步破坏损坏的文件系统。例如，像你一样对日志进行零化。为专业软件和恢复服务定价，而不是自己动手。
Server Fault用户
发布于 2020-07-06 12:04:33
根据xfs_repair -L的输出，您可能有一个底层物理磁盘错误。从您的问题中，我认为备份到目前为止还不是您的首要任务。从现在开始，这确实是您应该更改的第一件事，无论您是否设法恢复任何数据。
在执行任何类型的救援操作之前，克隆磁盘或分区可能是个好主意。最坏的情况下，您可以尝试dd的设备是一样大或更大的体积，你想要保存。我相信其他工具也可能有用。以前，Clonezilla是我最喜欢的，但是我已经好几年没有使用它了，所以我不知道它管理今天的系统有多好。
https://serverfault.com/questions/1024174
复制相似问题
腾讯云开发者
