GParted显示Linux分区已用空间与实际不符，如何恢复100GiB分区内的数据？

哥们，我完全懂你现在的崩溃——没备份（除了超级块）还遇上这种分区数据“凭空消失”的情况，太闹心了。先别慌，咱们一步步捋清楚，尽量把数据捞回来：

首先！立刻停止对这个分区的任何写入操作！ #

不管是安装工具、创建文件，甚至是不小心挂载成读写模式都不行！写入会覆盖原本还存在的数据，一旦覆盖，神仙也救不回来。如果要查看分区，用只读挂载：

sudo mount -o ro /dev/nvme0n1p4 /mnt

先复盘你的操作，再调整恢复思路 #

你用mkfs -t ext4 -n是模拟创建文件系统，不会实际写入分区，这点还算幸运；之后用超级块备份运行fsck，但结果只看到空的lost+found，说明文件系统的元数据（记录文件位置、结构的信息）已经严重损坏了，单纯修复超级块可能不够。

你执行的命令及输出参考：

ubuntu@ubuntu:~$ sudo mkfs -t ext4 -n /dev/nvme0n1p4

mke2fs 1.45.5 (07-Jan-2020)
/dev/nvme0n1p4 contains a ext4 file system
created on Thu Feb 29 10:25:01 2024
Proceed anyway? (y,N) y
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: f6d50715-fde7-49a1-971b-bcd8fa9aca87
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872

ubuntu@ubuntu:~$ sudo fsck -b 23887872 /dev/nvme0n1p4
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/nvme0n1p4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  +(32768--33792) +(98304--99328) +(163840--164864) +(229376--230400) +(294912--295936) +(819200--820224) +(884736--885760) +(1605632--1606656) +(2654208--2655232) +(4096000--4097024) +(7962624--7963648) +(11239424--11240448) +(20480000--20481024) +(23887872--23888896)
Fix<y>? yes
Padding at end of inode bitmap is not set. Fix<y>? yes
/dev/nvme0n1p4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/nvme0n1p4: 11/6553600 files (0.0% non-contiguous), 557653/26214400 blocks

sudo fsck -b 20480000 /dev/nvme0n1p4
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/nvme0n1p4 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Padding at end of inode bitmap is not set. Fix<y>? yes
Block bitmap differences: Group 1 block bitmap does not match checksum.
FIXED.
/dev/nvme0n1p4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/nvme0n1p4: 11/6553600 files (0.0% non-contiguous), 557653/26214400 blocks

接下来可以尝试的恢复步骤 #

1. 先给分区做完整镜像（必做！）

找一个容量大于100GiB的外部存储，把整个分区复制过去，这样即使后续操作搞砸了，还能回到现在的状态重新尝试：

sudo dd if=/dev/nvme0n1p4 of=/path/to/external/drive/partition_backup.img bs=4M status=progress

（把/path/to/external/drive/换成你外部存储的实际挂载路径）

2. 尝试用Testdisk修复文件系统结构

Testdisk是专门恢复分区和文件系统的工具，能扫描分区表、修复损坏的文件系统元数据：

• 安装Testdisk：sudo apt install testdisk
• 运行：sudo testdisk
• 按照向导选择你的NVMe磁盘，然后选择[Advanced] -> 选择/dev/nvme0n1p4分区 -> 选择[List]查看能不能找到文件；如果能看到，选择[Repair]尝试修复文件系统；如果看不到，试试[Undelete]或者[Rebuild BS]重建超级块。

3. 用Photorec做文件级恢复

如果Testdisk搞不定，Photorec（和Testdisk同属一个工具包）可以直接扫描分区里的文件内容，不管文件系统是否损坏，都能提取出照片、文档、视频等常见格式的文件：

• 运行：sudo photorec
• 选择你的NVMe磁盘 -> 选择/dev/nvme0n1p4分区 -> 选择要恢复的文件类型（默认全选就行） -> 选择外部存储的目录作为恢复文件的保存路径，然后开始扫描。

最后说句实在话 #

如果以上工具都没找回数据，那可能是文件系统的元数据损坏太严重，或者部分数据已经被覆盖了，这时候要么接受损失，要么考虑专业的数据恢复服务（但成本很高，通常按GB收费）。另外，这次之后一定要养成备份的习惯啊！

备注：内容来源于stack exchange，提问作者davynci