在Linux中恢复丢失和删除的数据

2017-07-17 3955 words 8 minutes

Contents

1. 简介

我们可以修理或更换硬件并购买或重新安装软件。然而，使设备独一无二和有价值的是它的数据。失去它可能是一种痛苦或噩梦。所以这取决于我们是否准备好了。

在本教程中，我们发现了处理意外信息丢失的方法。首先，我们刷新一下存储、分区、文件系统和文件的知识。接下来，我们将讨论由于存储和分区损坏而导致的数据丢失，以及如何处理此类情况。之后，我们专注于损坏的文件系统、它们的分析和恢复。然后，我们根据文件丢失的方式和条件探索恢复文件。最后，我们建议使用一些组合工具集来完成存储诊断和恢复。

我们使用 GNU Bash 5.1.4 在 Debian 11 (Bullseye) 上测试了本教程中的代码。它是 POSIX 兼容的，应该可以在任何这样的环境中工作。

2. 存储、分区、文件系统、文件和inode

物理存储有多种形式。重要的是，它们都有某种控制器。特别是，控制器的作用是组织和优化：

输入和输出（谁和什么时候）
读取和写入（什么和在哪里）

操作系统 (OS) 通过文件系统对存储上的数据进行排序。操作系统如何做到这一点取决于它的类型。

本机 Linux 文件系统使用inode 来存储和索引有关对象的信息。每个带有 inode 的对象都是一个文件。

例如，我们可以有目录文件和常规文件。Linux 中的目录是文件名与 inode 关系的列表。另一方面，常规文件链接到 inode，其中包含文件信息 ：

索引节点号
权限
文件的日期
内容块指针
其他元数据

请注意，实际文件数据位于内容块中（类似于扇区，但符合逻辑）。但是，如果没有 inode 中的指针，我们将不知道它们在哪里。此外，实际的 inode 在索引表中。

此外，文件系统通常是单独的分区，由表格描述。反过来，它们可以被创建和格式化。了解这些关系至关重要。要恢复数据，我们需要知道它的类型、它是如何存储的以及它是如何丢失的。因此，让我们从顶层开始。

3.丢失存储或分区

丢失数据的一种方式是硬件故障。这可能是由于坏块、损坏的控制器或其他坏组件造成的。当然，在这种情况下，数据要么消失了，要么很容易丢失。一旦介质出现故障，在其上存储任何信息都会变得有风险或不可能。

在存储设备上，分区是：

表中描述
由标题标识
用给定的格式

特别是，当分区表头或分区表损坏时，我们可能会丢失分区。例如，由于恶意行为者、流氓软件、硬件问题或错误，可能会发生这种情况。

让我们看看我们可以做些什么来诊断和消除这些问题

4. 分析分区和存储

一般处理存储时，我们可以求助于著名的e2fsprogs （Ext2/3/4 文件系统程序）包。

特别是，**badblocks工具可以方便地查找设备上的坏块。**实际上，它们通常是我们掌握的存储损坏的第一个证据：

$ umount /dev/sda
$ badblocks -v -sn /dev/sda
Checking for bad blocks in non-destructive read-write mode
From block 1 to 26510666
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: 1.05% done, 4:34 elapsed. (55/0/0 errors)
[...]

在这里，我们使用*-v*（详细）、-s（显示进度）和*-n*（非破坏性读写）标志。请注意我们如何在扫描之前首先卸载分区。通常最好在不从目标引导时进行诊断。

或者，我们可以在现代存储设备中使用 SMART（自我监控、分析和报告技术）。例如，有smartmontools （SMART Monitor Tools）：

$ smartctl -l selftest /dev/sda
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.14.0-kali4-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      6660         -

检查设备状态后，我们还可以通过**fdisk （固定磁盘）及其–list ( -l ) 标志查看分区表：

$ fdisk --list
Disk /dev/sda: 101 GiB, 108587687936 bytes, 212085328 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
Disk identifier: 0xc0666084
Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *         2048 210088528 210086480  100G 83 Linux
/dev/sda2       210090576 212087376   1996800  975M 82 Linux swap / Solaris

我们需要知道布局是否仍然可读。它可能丢失（空白）或只是有故障。

分析损坏后，让我们看看我们可以做些什么来补救任何问题。

5.存储救援

物理设备维修不在本文讨论范围之内。除了更换有故障的存储之外，我们可以直接做的事情不多。但是，如果介质仍然是部分可读的，我们也许能够从中恢复数据。

当然，对设备进行完整备份是恢复所有内容的最简单方法。除此之外，我们应该找到其他应对方式。

例如，GNU ddrescue （Disc Dump Rescue）工具可以逐块转储有问题的介质的原始图像：

$ ddrescue --idirect --retry-passes=3 /dev/sda dump.img dump.logfile
GNU ddrescue 1.23
Press Ctrl-C to interrupt
     ipos:    1597 MB, non-trimmed:        0 B,  current rate:  47972 kB/s
     opos:    1597 MB, non-scraped:        0 B,  average rate:    228 MB/s
non-tried:  273280 MB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    1597 MB,   bad areas:        0,        run time:          6s
pct rescued:    0.58%, read errors:        0,  remaining time:         19m
                              time since last successful read:         n/a
Copying non-tried blocks... Pass 1 (forwards)

我们使用*–idirect* ( -d ) 来跳过内核缓存。此外，–retry-passes ( -r ) 标志设置坏扇区的重试次数。但是，此选项最好留作第二次通过，以避免对故障设备造成进一步压力。重要的是，ddrescue使用特殊算法来确保尽可能少地进一步磨损介质。

同样，不应挂载*/dev/sda* ，并且dump.img必须位于另一台设备上。在此之后，我们只需将此图像文件恢复到新媒体：

$ ddrescue -f dump.img /dev/sda restore.logfile

另一个具有类似功能的工具是safecopy 。现在我们已经看到了完整的设备救援，让我们继续往下看。

6. 恢复分区

分区表通常在顶层组织存储。像往常一样，如果我们有一个现已失效的分区表的备份，我们可以而且可能应该通过脚本版本的fdisk恢复它，即sfdisk ：

$ sfdisk -d /dev/sda > parttable
$ sfdisk /dev/sda < parttable

当第一个命令将表转储到parttable时，第二个命令从该文件中恢复它。

但是，如果像大多数情况一样，我们没有备份，那么仍然有希望。交互式testdisk 工具可以扫描丢失的表：

$ testdisk
[...]
TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <[[email protected]](/cdn_cgi/l/email_protection)>
https://www.cgsecurity.org
Disk /dev/sda - 107 GB / 100 GiB - CHS 13054 255 63
Analyse cylinder  5127/13054: 39%
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux Swap             538 123 34   799 144 41    4194296
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  Linux                    0   0  1 33418 170 32  536870912
  
Stop
[...]

在这里，testdisk从中找到了旧表和条目。在此之后，我们还可以将其中任何一个应用到我们的设置中。此外，还有一个重写MBR 的选项。

分区只是介质中孤立的“房间”。但是，它们通常有一种格式可以识别它们，除非它已损坏。

7. 文件系统损坏和文件问题

由于文件系统基本上是一种数据格式，因此它们使用有序的元数据。弄乱它会导致问题：

无效文件，即指向丢失 inode 的硬链接
不可访问的有效文件，即没有到现有 inode 的硬链接
系统无法启动
无法安装或识别文件系统
其他意外行为

事实上，我们看到的问题在很大程度上取决于文件系统类型、其结构以及丢失的内容。

例如，inode 中的指针指的是大多数人所说的数据，例如文件内容。丢失或损坏 inode 会使内容块指针无效，并仅将文件保留为 shell 文件名。它们将包含完整的元数据但没有内容。

另一方面，块内的数据丢失可能是永久性的，但它如何发生很重要。是否找到丢失的数据取决于许多因素，包括：

信息是如何丢失的
我们是否丢失了指向它的数据或元数据
是否还有元数据指向我们的数据
存储类型
自丢失以来的设备使用情况
文件系统状态

让我们专注于最后一点。

8. 文件系统分析与恢复

当然，检查文件系统的标准方法是fsck （文件系统一致性检查）工具：

$ fsck /dev/sda1
fsck from util-linux 2.37.2
e2fsck 1.46.4 (18-Aug-2021)
/dev/sda1: clean, 11/6553600 files, 557848/26510666 blocks

请注意，我们指定分区*/dev/sda1而不是整个存储设备/dev/sda*。即使我们使用*/dev/sda*，fsck也只会一个接一个地检查文件系统。

就像testdisk一样，fsck结合了扫描和恢复。为避免后者，我们可以添加*-n以防止任何更改。虽然在 Linux 下有类似功能的工具，例如ext4magic ，但fsck*是无处不在的。

所以，如果我们的存储是有序的，分区表——正确的，文件系统——完好无损，我们可能只是丢失了一个文件。它去了哪里，我们如何找回它？

9. 数据和文件的发现和恢复

首先，始终备份关键数据。

第二，尽量减少数据丢失后的介质使用。这包括手动活动和自动任务，如碎片整理、扫描、cronjobs 和操作系统进程。

我们应该始终确定我们所缺少的东西。无论是单个常规文件、一个文件的片段、许多单独的文件，还是整个目录。然后我们找出或推测它是如何丢失的，检查日志和扫描。

事实上，扫描可以是最精确或最通用的方法。所以这取决于它的类型。

9.1. lost+found

通常，当一个对象的所有硬链接都被删除时，它的 inode 就会失效。然而，如果这没有发生，lost+found目录可能包含一个占位符文件，指向仍然有效但不可访问的 inode。

为此，我们应该事先运行fsck以查找“断头”的 inode。

9.2. 数据识别

另一方面，丢失 inode 可能会带来更大的问题，因为我们可能看不到文件内容的位置。**扫描可能能够根据文件的格式 **部分或全部恢复文件。

但是，有许多注意事项。例如，碎片，即文件块的分散程度，起着重要作用。那是因为片段是由 inode 中的信息链接起来的。此外，这取决于我们能够识别多少格式和哪些格式的软件。

例如，尽管名为photorec 工具，但它可以识别480 多个扩展名 。方便的是，它是testdisk包的一部分，因此具有类似的交互式命令行界面。

或者，空军特别调查办公室提供了最重要的工具 。但是，没有多少工具像photorec那样得到积极维护。

9.3. 损坏的文件信息

事实上，我们可能有影响文件一致性的因素组合：

损坏的存储块，影响文件的硬链接、内容或索引节点
文件系统问题，导致 inode 丢失、部分或被替换
文件意外损坏、删除或覆盖

然后我们应该把我们讨论的所有问题都一一处理。为了使这更容易，有可用的免费包。

事实上，它们通常包括我们探索过的标准工具，但也包括针对特定情况的其他工具。

10. 可引导工具集

正如我们已经提到的，最好尽量减少有问题的存储活动。因此，我们通常希望克隆有问题的媒体并使用该克隆。如果不可能，我们至少应该卸载。

但是，我们的操作系统通常是从我们尝试使用的同一台设备上运行的，因此我们不能在我们的环境中使用任何工具。为此，有打包的映像，其中包含预安装在可启动环境中的救援工具集：

Trinity Rescue Kit ，一个主要面向 Windows 恢复的 Linux 环境
Hiren 的启动 CD ，一个带有许多工具的通用 Windows 便携式环境
终极启动光盘
System Rescue ，一个 Linux 系统救援工具包

使用它们就像获取图像、将其写入介质并从该介质启动一样简单。事实上，不从数据丢失或损坏的设备启动会大大增加恢复数据的机会。