数据丢失：逐步操作指南
当文件或数据库消失时的处理流程：如何避免第一个操作让情况更糟，到哪里寻找残留，以及哪些能恢复、哪些不能。
更新于 2026年8月23日
数据丢失后的第一个动作比之后的一切都重要。下面这套流程不会让您白白断送恢复的机会。
立即：停止写入磁盘
被删除的文件会一直留在磁盘上，直到它占用的空间被新数据覆盖。每一次写入——安装软件包、运行中的网站、不断增长的日志——都会降低您的恢复几率。
- 停止一切正在写入的进程：Web 服务器、数据库、队列工作进程。
- 不要把恢复软件安装在同一块磁盘上。
- 不要重装系统：重装会彻底且不可逆地销毁磁盘。
如果数据很重要且您没有备份，请先关机，并在做任何尝试之前联系支持。
弄清究竟发生了什么
| 现象 | 实际情况 | 去哪里 |
|---|---|---|
| 文件被命令删除 | 普通删除 | 见下文 |
| “No space left on device” | 空间不足，应用程序无法写入 | 空间不足 |
| 数据库打不开，文件还在 | 数据库损坏 | 数据库备份 |
| 系统无法启动 | 引导加载程序或文件系统 | 救援磁盘 |
| 陌生文件、不熟悉的进程 | 可能已被入侵 | 入侵迹象 |
如果您有备份
这是最快的路径，而且几乎总是唯一成功的路径。用您自己的方案恢复——rsync 或 restic——并且不要只验证解包是否成功，而要验证内容：大小、行数、数据库能否打开。
restic -r /path/to/repo snapshots
restic -r /path/to/repo restore latest --target /restore
请先恢复到单独的目录，而不是直接覆盖正在使用的目录：备份本身也可能不完整，用它覆盖残留数据只会让两种选择都失去。
如果您没有备份
我们不保留您机器的自动备份，也没有快照。虚拟机的磁盘就是您的磁盘：上面发生了什么就是发生了什么。正因如此，备份要在第一天就配置好——具体该备份什么。
您还可以自行尝试以下方法：
- 文件仍被某个进程打开。 如果某个程序仍持有已删除的文件，可以通过
/proc访问它：
这只在进程存活期间有效——不要重启它。lsof +L1 cp /proc/<pid>/fd/<n> /root/recovered-file - 数据库日志中的数据。 PostgreSQL 和 MySQL 都有预写日志，专家可以据此重建崩溃前的状态。不要盲目以修复模式启动数据库——那样连日志也会一起丢失。
- 启动到救援磁盘，先把磁盘镜像到另一台机器，再尝试
extundelete或photorec之类的工具。您必须对镜像操作，而不是对正在使用的磁盘操作。
不要做的事
- 在决定是否需要这些数据之前，就重装系统“从头开始”。
- 运行会把输出写到同一块磁盘上的恢复程序。
- 在没有镜像的情况下，对正在使用的磁盘运行
fsck并自动回答“yes”来修复文件系统。 - 等上一周再来请求恢复：机器运行得越久，能找回的就越少。
如何避免重蹈覆辙
同样的对话总是以同样的方式结束：要么您有备份，要么没有。今天就配置好备份，并且每季度用一次恢复演练来测试——从未恢复过的备份不算备份。