☰

Linux上的数据恢复

tag-icon • tag-icon linux ubuntu data-recovery recovery
Linux上的数据恢复

我最近买了一台新电脑，以便升级我的旧 Linux 机器。我的旧机器运行的是 Ubuntu 16.04 Server LTS。操作系统安装在 256 GB SSD 上，而单个 7 TB HDD 用于数据存储。与 SSD 磁盘一样，数据驱动器通过 SATA 连接到系统。换句话说，数据驱动器不是外部 USB 驱动器。

在新系统上，我在新的 1TB SSD 驱动器上安装了 Ubuntu 18.04 Server LTS。然后，我从旧机器上物理移动了 7 TB HDD 并将其连接到新系统。然而，令人惊讶的是，以前存储在旧 7 TB HDD 上的数据现在丢失了，也就是说，Ubuntu 18.04 报告磁盘不包含任何信息，这意味着它不显示任何文件或目录。Ubuntu 显示 7 TB 的可用空间。

当然，我没有对驱动器进行重新分区或向其中写入任何数据。我所做的只是将旧驱动器物理连接到新机器并启动 Ubuntu 18.04 LTS。使用的文件系统是 ext4。

发生了什么事？我该如何恢复我的数据？

我尝试过 testdisk、photorec 等工具，但是没有成功。

以下是一些输出：

sudo fdisk -l

Disk /dev/loop0: 86.9 MiB, 91099136 bytes, 177928 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop1: 89.5 MiB, 93818880 bytes, 183240 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/loop2: 89.5 MiB, 93835264 bytes, 183272 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: XXX

Device           Start         End     Sectors   Size Type
/dev/sda1         2048 15628052479 15628050432   7.3T Linux filesystem
/dev/sda2  15628052480 15628053134         655 327.5K Linux filesystem

Disk /dev/sdc: 1.9 TiB, 2048408248320 bytes, 4000797360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: XXX

Device     Start        End    Sectors  Size Type
/dev/sdc1   2048       4095       2048    1M BIOS boot
/dev/sdc2   4096 4000794623 4000790528  1.9T Linux filesystem

以下是 Foremost 的报道：

Invocation: foremost -i /dev/sda1 -t png -o /home/erran/foremost
File: /dev/sda1
Start: Thu Jan 10 13:55:00 2019
Length: 7 TB (8001561821184 bytes)

Num      Name (bs=512)         Size      File Offset     Comment

Finish: Fri Jan 11 02:27:21 2019

0 FILES EXTRACTED

根据@agc 的建议更多输出：

sudo dd if=/dev/sda count=1 bs=1G | gzip -1 | wc -c
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.43023 s, 127 MB/s
7332366

sudo dd if=/dev/zero count=1 bs=1G | gzip -1 | wc -c
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 4.16624 s, 258 MB/s
4683762

答案1

不要惊慌……这需要很久擦除 7 TB 硬盘。

花一点时间检查数据是否真的通过使用 压缩整个磁盘的第一个 GB gzip -1，然后比较大小，就可以了。例如，使用我当前工作的硬盘：

dd if=/dev/sda count=1 bs=1G | gzip -1 | wc -c

一分钟后输出：

1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 54.3403 s, 19.8 MB/s
1072079878

最后一个数字1072079878是压缩后的大小，与未压缩时的大小非常接近。部分原因是gzip -1速度太快，压缩效果不佳，部分原因是前 1 GB/dev/sda包含大量数据。

将其与相同的代码进行比较，但使用/dev/零，（无尽的零流）：

dd if=/dev/zero count=1 bs=1G | gzip -1 | wc -c

输出（10 秒内运行）：

1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 8.65898 s, 124 MB/s
4683762

由于数据全为零，甚至gzip -1可以压缩1G向下4米， （少于1%原始大小）。

假设没有恶意软件参与，那么只有当你的硬盘驱动器显示压缩率类似于压缩/dev/零，（并且只有当它这样做时两个都电脑），会有什么可担心的吗？否则，可能是一些BIOS配置不一致...

相关内容