2023年11月25日发(作者：)

⼀次Linux下testdisk+gdisk恢复XFS⽂件系统及数据的经

历

⼀次Linux下testdisk+gdisk恢复XFS⽂件系统及数据的经历

硬盘之前状况,⽤gdisk进⾏硬盘分区（SATA标准，3.6T容量），1.6T+2.0T两个分区，然后⽤格式化分区，最后结果

就是，GPT分区表+两个XFS⽂件系统的硬盘(/dev/sdb,/dev/sdb1,/dev/sdb2)

我已⽆法确定引起这次硬盘错误的原因，但我确实这么做过：

原因⼀,从另⼀个硬盘的/home挂载点复制了⼤量数据到/dev/sdb1,然后我就将硬盘的数据线和电源线都拔掉了，这个动作在系

统运⾏和关闭的两种情况下都做过，（SATA 硬盘是否安全的⽀持热插拔？）

原因⼆,在这次准备复制数据的之前，我没有将硬盘固定，也没有平放在台⾯（有⼀点斜度），然后开机，（胡乱的猜想着斜

坡加载技术）

下⾯进⼊正题：

1,硬盘错误引起分区⽆法读取，挂载，开始纳闷哪⾥出了问题

2，运⾏gdisk -l /dev/sdb,显⽰如下

有警告信息及注意事项,虽然这⾥的标记GPT:damaged说明GPT有问题，但最后还是显⽰出了有分区的信息存在，（GPT分区

表信息应该没有彻底损坏，不然怎么读取到两个分区的信息的呢），两个分区⾥Code标记都变成了0700（Microsoft basic

data),正常的应该是8300（Linux filesystem），这个标记应该说明的是XFS⽂件系统的superblock信息毁了,这是后来经过XFS

⽂件系统⼯具xfs_repair知道的

详细分区情况，但是是得出来的结果有问题的

gdisk检测到五个问题，（惊讶，这么多的问题）

3,进⾏到这⾥，我着急了，于是寻求帮助

⾸先，尝试了xfs_repair /dev/sdb,这个命令进⾏了⼏次，因为中途中断过，这个修复时间是⽐较长的，⼏⼩时（差不多3，4⼩

时？）后得到的结果却是⽆法检测验证到有效的备份superblock信息，（失败，⼼都凉了）

然后，找到testdisk⼯具，⼤略的看了下说明就上⼿做（英⽂实在是差，仔细地看也不明⽩），第⼀次进⾏Analyse后，完全不

知道做什么，就直接退出

然后就去测试查看，运⾏lsblk，gdisk，没有任何改变，（此刻是没抱什么希望的），输出的⽇志⽂件也完全看不

懂，但我在⽇志⽂件⾥看到了有XFS这三个

字母的⾝影，（此时⼼中还是有⼀丝喜悦的）

4,继续⽹上搜索，寻求答案，（⾟⾟苦苦建⽴的⽂件数据啊，那个⼼情真是⽆奈啊）

使⽤testdisk进⾏第⼆次Analyse(分析⽬前分区结构及搜寻丢失的分区），经过6⼩时的分析与搜索后，我⼤胆的进⾏了第⼆个

动作，转换分区类型，（当时的想法是inode及data block⾥记录的信息应该是不会丢失或被覆盖的），于是我选择了Linux

reserved（⾕歌翻译了⼀下，“Linux保留”，这⾥是没有Linux filesystem 的，找来找去也没找到更合适的了），再进⼊⼦菜单

选择了XFS（还有

XFS2,XFS3，XFS4，这⾥是⽐较疑惑的，⽹上没有找到任何答案），⾄此点击写⼊，然后退出。再⼀次阅读⽂

件，（这⾥有点⼩插曲，我在主⽂件侠⾥找不到⽂件，进⾏whereis 搜寻，这个⽂件怎么会跑

到/usr/src/linux-3.10.3-1-ARCH/这⾥了呢）？

5,⽂件内容如下：

这⾥是系统的⼀些相关信息

这⾥是选择了EFI GPT选项后得出的结果，在这⾥就分析出了当前的分区结构，只有⼀个Linux Reserved分区类型的分区，

（这⾥的这个分析是不是肯定的）

这⾥是应该是选择了Analyse选项后再点击quick search得到的，⼤概是两段内容，第⼀，对于分区1⽂件系统的标记搜索，成

功，（这个标记是什么，superblock？，不是损毁了吗？）。第⼆，对于分区2⽂件系统的标记搜索，在这⾥搜索到了很多标

记，但是在⽐对数据（能这样表达吗）时却出现了问题，（这⾥应该就是为什么会耗时6⼩时的原因)，因为数据的信息标记超

出了磁盘的整个容量，（这会是什么原因造成的呢）

这⾥是搜索完成后得到⽆法恢复分区2⽂件系统的信息

这⾥是这次使⽤testdisk最后的结果⽇志，只找到了丢失的分区1⽂件系统，然后进⾏了分区类型的改变和确定写⼊。

6,经过上步的尝试，（说实话，⼼⾥很忐忑），使⽤lsblk查找，还是找不

到/dev/sdb1,于是运⾏gdisk

虽然看到不想看到的信息，但是No problems found⼀句让我有些惊喜，继续

作出决定，重写分区表信息7,喜出望外的结果

检测出/dev/sdb/sdb1

成功挽回⽂件！（兴奋啊）8,疑问与猜想

GPT分区表已经修复好，分区1的类型为Linux reserved（并不是未出问题之前的Linux filesystem），成功检测到/dev/sdb1的

⽂件系统是XFS。已经挽回了数据，虽然并没有完整的修复，但现在没有空闲的磁盘来备份这些数据，所以这⾥就没敢继续往

下尝试恢复了

疑问⼀：能不能直接使⽤gdisk的重新建⽴分区表的功能，使⽤testdisk好像最主要的作⽤就是做了分区的搜索，然后做了个分

区类型的转换（这步是否可⽤其它⼯具完成）？

疑问⼆：XFS⽂件系统的superblock到底有没有损毁，如果没有损毁，怎么就检测不到分区⽂件系统信息，如果损毁了⼜是怎

么恢复的，因为尝试运⾏了xfs_repair,检测到磁盘最后⼀个扇区也验证不了备份的superblock。superblock有没有彻底恢复，

如果是彻底恢复的，为什么不能正确的检测到分区2的信息，如果并不是完整的superblock，⼜何以能够读取分区1的作息？

疑问三：总觉得这⾥的Linux reserved怪怪的，难道它在磁盘⾥的记录信息与Linux filesystem是兼容的？这个记录信息与XFS

⽂件系统的superblock有没有关系？

疑问四：运⾏dd if=/dev/sdb of=/dev/sdax,会是什么结果？

猜想疑问⼀：阅读了鸟哥的私房菜基础篇⾥的ext2⽂件系统的那⼀章节，对⽂件系统（ext2,ext3,ext4，XFS）有这么个了解，

记录整个磁盘分区情况的是GPT分区表，记录分区⽂件系统信息的是superblock，记录⽂件系统⾥的⽂件信息的是inode，记

录⽂件系统⾥的⽂件实际数据的是block，这⾥的inode与block是否有独特的标记，是否可写这样⼀个程序，直接读取到磁盘

⾥的inode来找到block

从⽽搜索出⽂件信息

猜想疑问⼆：说到这⾥当然还有⼀些疑问，这⾥的思维有些乱。GPT磁盘在开始区域

记录着保留的MBR信息，GPT信息及superblock信息，这些是怎么记录下来的，因为这个区域没有进⾏⽂件系统格式化，磁

盘的整个磁盘的最⼩单位是sector（扇区），进⾏分区⽂件系统格式化后，磁盘⽤来记录信息的最⼩单位是block吗，那么

默认256bytes的inode⼜是个什么，superblock信息为什么会记录在第⼀个

分区以前未格式化的区域？

此篇⼩记说明：以上信息仅针对本⼈使⽤的系统环境，其中有⼀⼩部份表达的信息⽆法

⽤图⽚来⽐对，因为⼀开始没想要写此记，所以⼀些信息的截图就忽略了，特别是

xfs_repair这个环节。

最后作个提醒：硬盘发⽣错误，在系统运⾏期间⽆法⾃动fsck导致系统⽆法成功启动

或⽆法检测分区读取数据信息（⾮启动盘）后，绝不能再对硬盘进⾏任何写操作，慎⽤fsck，切记，切记，这样，⾃⼰就能最

有把握的将数据拯救出来！