记录一次硬盘数据抢救

2023-06-18 猛禽需要1分钟读完

起因

有个数据库服务器是跑在虚拟机里的，因为最近硬盘空间有点不足，就申请扩容了一下。不过操作这事的同事没注意这个硬盘当初是做成LVM的，直接就拿fdisk扩了，结果就是重启以后找不到LVM，无法启动。

我刚开始不知道事情的起因，还以为只是LVM模块损坏啥的，结果把虚拟硬盘挂到别的服务器上也识别不出来，才知道是LVM分区表损坏了。

本来虚拟硬盘做这种事是很方便的，操作前直接先做个快照备份就好，万一有问题还可以回滚，然而并没有。这让我想起十几年看过大神Delphij的语录：

冗余不做，日子甭过；备份不做，十恶不赦。

放狗搜了一下，大部分的说法是需要有LVM备份文件，否则只能按原参数重建LVM，然后扫描一下看看能找回多少文件。然而我们没有做LVM配置备份，也不记得当时创建的参数了——又是一个备份不做的事情，不过一般来说确实不太会想到来备份LVM的配置，毕竟我们也没用到什么复杂的LVM配置。

附LVM配置备份方法：

vgcfgbackup -f lvmbackup vgname
vgcfgrestore -f lvmbackup

lvmbackup是备份文件名，vgname是巻组名。

后来又问了ChatGPT，提供了一个方案是使用testdisk这个开源工具。

这个工具使用有点复杂，也有一定的风险，这次当然是需要先做个快照，以防万一了。

因为当时光顾着修复，没有截图，现在只能文字说明一下。

首先用：

sudo fdisk -l

看一下现在有哪些盘，别一会搞错就杯具了。

然后用（假设是vdb这块硬盘）：

sudo testdisk /dev/vdb

前面是一堆选择日志，选择硬盘（指定的话好像没有），选择分区表类型（现在当然都是GPT）……这些都弄完了就进入功能菜单，选择”Analyse”，会显示出当前的分区表结构，当然是不对的。

然后点击下面的“Quick Search”快速搜索一下可能被破坏的分区表结构，如果能找到当然好，然而我们这种情况没有找到——我试了一下找到的这几个都不对。

只能继续，点击下面的“Deeper Search”，这个就慢了，500G的硬盘足足搜了5个多小时……

最后找出来可能有几百个分区，当然大部分看size就知道不对，只拿比较大的那些试试，但是也都没成功，而且最坑的是，每次尝试失败都要重新扫描5个小时……

实在没办法，只能放弃恢复分区，争取把丢失的重要文件找回来就好。

再次花了5个小时扫描硬盘后，用“P”命令去一个个查看那些大分区，最后在一个分区里找到需要的文件，小心地操作复制出来保存到vda里去，才终于完成抢救工作。