“rm -rf”后，如何用冷静和技术逆转数据绝境？

IT运维技术圈

发布于 2025-08-12 09:20:13

24100

代码可运行

文章被收录于专栏：IT运维技术圈IT运维技术圈

运行总次数：0

代码可运行

0. 写在前面：为什么你需要“神器”而非“常用命令

在服务器运维的日常工作里，误删文件这种事并不算稀罕，但真正碰上的时候，心里多少还是会有点慌。处理这类情况，最关键的反应往往不在于“多快恢复”，而在于“怎么避免二次破坏”。这份记录，更像是一次带着回忆和经验的整理，希望在类似事故发生时，能帮人稍微沉住气。那一刻，终端里只剩下一个命令行，回车声像闷雷——rm -rf、git clean -fdx、或者一句手滑的 s3 rm。心跳会加速，脑子会短路。先说一句：别着急敲更多命令。救数据，是有方法的；有序、谨慎、按步骤，成功率远比盲目操作高得多。下面把我多年现场救援的经验浓缩为一份落地可操作的恢复策略，所有命令都给出示例与模拟输出，便于演练与现场使用。

快速备忘（遇到误删后前 5 分钟的优先动作）

按这套「先保，后救，再验」的顺序走，能把伤害降到最低。

• 停止写操作：把相关服务停止或置为只读。

$ sudo systemctl stop myapp.service
# 或者：在应用层拉掉写流量

• 查看是否有已删除但仍被进程占用的文件（有时可以直接救回）：

$ sudo lsof +L1
# 模拟输出：
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK    NODE NAME
myapp    2345 root   22u   REG  8,1   10485760    0  123456 /var/log/app.log (deleted)

• 做磁盘或分区的只读镜像备份（不要直接在原盘上做修复）：

$ sudo dd if=/dev/sda1 of=/tmp/disk.img bs=4M conv=noerror,sync status=progress
12345+0 records in
12345+0 records out
51200000000 bytes (51 GB) copied, 1200.00 s, 42.6 MB/s

• 如果使用 LVM、Btrfs、ZFS 或云盘，优先做快照：

# LVM snapshot 示例
$ sudo lvcreate --size 10G --snapshot --name root_snap /dev/vg0/root
Logical volume "root_snap" created

重要提示：在未创建镜像/快照前，尽量不要写磁盘（包括 apt、yum、日志大量滚动），也不要重启机器（某些删除后打开的文件会在进程退出时彻底释放）。

详细流程（分场景、分技术栈）

下面按常见场景给出可执行步骤与命令模拟输出。遇到实际情形，优先选最贴近你环境的方法。

情况 A：文件被进程删除，但进程仍在运行（常见于日志/进程旋转不当）

很多情况下，文件被删除后，进程仍持有文件句柄。文件实际上还在磁盘上，只是目录项被移除了。

1. 用 lsof +L1 列出被删除但仍打开的文件。（上面快速备忘有示例。）
2. 将打开的文件复制出来：

$ sudo cp /proc/2345/fd/22 /tmp/recovered_app.log
# 模拟输出：无输出 -> 成功
$ ls -lh /tmp/recovered_app.log
-rw-r--r-- 1 root root 10M Aug 10 11:10 /tmp/recovered_app.log

3. 如果需要继续让服务写日志，先把服务优雅重启，或替换日志文件句柄（谨慎）：

$ sudo kill -USR1 2345   # 假设应用支持 reopen log
$ sudo systemctl restart myapp.service

情况 B：有快照（LVM / Btrfs / ZFS / 云盘）——优先用快照恢复

快照是最安全、最高效的恢复途径。目标是从快照中挂载只读副本或克隆为新卷并从上面恢复文件。

LVM 示例：

$ sudo lvcreate --size 10G --snapshot --name root_snap /dev/vg0/root
Logical volume "root_snap" created
$ sudo mkdir /mnt/snap
$ sudo mount -o ro /dev/vg0/root_snap /mnt/snap
$ ls /mnt/snap/var/log | head -n 5

AWS EBS 快照思路（示例 CLI）：

$ aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 --description "pre-recover"
# 模拟返回：
{
  "SnapshotId": "snap-0abcdef1234567890",
  ...
}
# 然后用该 snapshot 创建新卷、挂载到恢复主机进行文件恢复

Btrfs / ZFS：用 btrfs restore 或 ZFS 快照做回滚/克隆。命令因环境而异，原则一样：不要直接在原数据上修复，在快照或克隆上操作。

情况 C：传统文件系统（ext4/xfs）上误删（没有快照）

这类最常见也最棘手。优先步骤如下：

1. 立即停止所有可能写盘的进程。

$ sudo systemctl stop myapp.service
$ sudo systemctl stop rsyslog

2. 做整盘镜像（只读）到恢复主机：

$ sudo dd if=/dev/sda1 of=/tmp/disk.img bs=4M conv=noerror,sync status=progress

3. 在恢复主机上用 debugfs / extundelete 操作（对 ext 文件系统）：

# 在恢复主机上（非原盘）：
$ sudo extundelete /dev/loop0 --restore-directory /var/log
# 模拟输出：
Processing journal...
Examining inode table...
Restored /var/log/app.log to RECOVERED_FILES/var/log/app.log

extundelete 会把恢复出的文件放在 RECOVERED_FILES 目录下。注意：extundelete 要求目标分区在运行时为未挂载状态（或以只读方式挂载）。

4. XFS 情形：XFS 不易做undelete。若没有快照，优先尝试从 xfsdump/xfsrestore 备份恢复，或者使用 xfs_repair（这是修复工具，不是 undelete），最稳妥的方法仍是基于镜像尝试数据恢复工具（testdisk/photorec），成功率参差不齐。

情况 D：数据库级误删（以 MySQL 为例）

数据库误删（误删行/误 drop 表）要求更谨慎：千万别在原库上直接导入全量备份覆盖。

恢复步骤示例（假设你有全量备份 + binlog）：

1. 在隔离恢复环境创建新实例（避免覆盖生产）。
2. 恢复最近一次全量备份：

$ gunzip < prod_full_20250810.sql.gz | mysql -uroot -p -h restore-host
# 模拟：无输出 -> 成功

3. 用二进制日志做 point-in-time 恢复（回放到误删时间点之前）：

$ mysqlbinlog --start-datetime="2025-08-10 09:00:00" --stop-datetime="2025-08-10 09:59:59" /var/lib/mysql/mysql-bin.000001 | mysql -uroot -p -h restore-host mydb
# 模拟：输出 SQL 回放行数统计

4. 验证恢复数据，确认无误后再把应用切到恢复实例，或导出单表数据回写到生产（小心事务与主从复制）。

注意：若误删导致 binlog 上包含删除语句，回放前需要过滤掉 DELETE 语句（用 --rewrite 或手工编辑 SQL），以免再次误删。

情况 E：Kubernetes 中误删（Pod 内文件或 PVC 被误删）

容器化环境恢复思路依赖于持久化存储类型。

• 如果 PVC 背后是可快照的存储类，先用 CSI snapshot 恢复到新 PVC；
• 如果没有快照，把 PVC 挂到临时 Pod 上，尽快把残余数据拷贝到安全位置（或创建 VolumeBackup）。

示例：把 PVC 挂到临时恢复 Pod：

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: recover-pod
spec:
  containers:
  - name: shell
    image: ubuntu
    command: ["/bin/bash","-c","sleep 3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: my-pvc
EOF

$ kubectl exec -it recover-pod -- bash
root@recover-pod:/# ls -la /data

在 Pod 中将重要文件复制到另一个安全存储（例如临时 PVC、NFS 或对象存储）。

情况 F：对象存储（S3/OSS 等）误删

对象存储的恢复策略取决于是否开启了版本控制或回收站：

• 开启版本控制：直接下载带 VersionId 的历史版本。

$ aws s3api list-object-versions --bucket my-bucket --prefix path/to/file
# 找到 VersionId 后：
$ aws s3api get-object --bucket my-bucket --key path/to/file --version-id <VERSIONID> /tmp/file

• 开启回收站/回收策略：按所用云厂商流程恢复。
• 若都未开启，数据通常难以恢复（除非云厂商可做底层恢复——需要尽快联系支持）。

情况 G：Git 仓库误删/误提交

Git 通常可以自救，前提是本地存在 reflog 或远程有未删除的引用。

$ git reflog
# 找到删除前的 commit id
$ git checkout -b recover <COMMIT_ID>
# 或从远程 fetch 后恢复分支

如果整仓被删除，但远程仍有备份，可从远程 clone 回来。

情况 H：无快照、也无法从镜像恢复——数据雕刻（testdisk / photorec）

这是最后的手段，针对文件头识别做恢复，常用于照片、日志之类。成功率不保证，但仍可试：

$ sudo apt-get install testdisk
$ sudo testdisk /tmp/disk.img
# 交互式界面进行分区/文件恢复

或使用 photorec 批量恢复文件类型（注意恢复目录占用空间大）。

恢复后的验证（不可省略）

恢复不是交差，必须验证。

• 校验文件完整性：sha256sum 对比源/备份。

$ sha256sum /tmp/recovered_app.log
e3b0c44298fc1c149afbf4c8996fb924...

• 应用级验证：复跑关键用例（健康检查、写入/读取一条记录）。

$ curl -I http://127.0.0.1:8080/health
HTTP/1.1 200 OK

• 对数据库，核对行数、关键表统计、主从复制状态。

事后复盘与补救（必做）

恢复后必须做完整复盘，把经验固化为变更，避免复发。

建议记录并提交的内容包括：

• 误删时间、操作人、具体命令、影响范围。
• 恢复步骤、所用快照/镜像、是否创建了新卷、是否存在数据差异与校验结果。
• 根因分析（权限、流程、人为失误、自动化脚本缺陷）。
• 长期修复项（权限收紧、引入快照/版本化、改进运维流程、增加二次确认机制、演练计划）。

把关键命令、恢复 playbook 写成 Runbook，加入 on-call 手册并做演练。

防范与长期策略（务必落地的 10 条清单）

这些策略能把事故概率与恢复时间大幅拉低。

1. 对关键卷启用自动快照（LVM/Btrfs/ZFS/CSI snapshots / EBS snapshots）。
2. 对对象存储启用版本控制（S3 Versioning / OSS）。
3. 常态化做全量备份 + 增量日志（DB：全备 + binlog；文件：rsync 增量 + 快照）。
4. 把关键操作加审计与二次确认（UI/CLI 都要有）。
5. 严格最小权限原则，拆分角色（谁能删，谁能快照）。
6. 在生产机上避免直接 rm -rf，引入安全工具（safe-rm、trash-cli、或内部统一删除工具）。
7. 关键路径演练：每季度恢复演练，测 RTO / RPO。
8. 把恢复脚本与步骤版本化，放入版本控制并与 CI 集成。
9. 对生产日志做异地归档（对象存储），减少本地误删影响。
10. 定期检查并演练快照恢复流程（不要只是开启快照而不验证它能否用）。

常用命令备忘（可直接复制）

# 停止写入
sudo systemctl stop myapp.service

# 查被删除但仍打开的文件
sudo lsof +L1

# 做镜像（只读备份）
sudoddif=/dev/sda1 of=/tmp/disk.img bs=4M conv=noerror,sync status=progress

# 创建 LVM snapshot
sudo lvcreate --size 10G --snapshot --name root_snap /dev/vg0/root

# 挂载镜像
sudomkdir /mnt/recover
sudo mount -o ro,loop /tmp/disk.img /mnt/recover

# extundelete（在恢复盘对未挂载分区运行）
sudo extundelete /dev/loop0 --restore-directory /var/log

# MySQL 恢复示例（在恢复实例上）
gunzip < prod_full.sql.gz | mysql -uroot -p
mysqlbinlog --start-datetime="2025-08-10 09:00:00" --stop-datetime="2025-08-10 09:59:59" /var/lib/mysql/mysql-bin.000001 | mysql -uroot -p mydb

# S3 恢复版本
aws s3api list-object-versions --bucket my-bucket --prefix path/to/file
aws s3api get-object --bucket my-bucket --key path/to/file --version-id <VERSIONID> out.file

结语：一份冷静的承诺

误删发生时，情绪会争先登场，但真正有用的是节奏。先保全证据、先做只读镜像或快照、再恢复并验证——用耐心去换取数据的完整。把今天的流程写进明天的 Runbook，把今天学到的防御措施变成明天的常态。技术可以把错误变小，把恢复变快；组织可以把错误变成成长。

老杨时间

这里我先声明一下,日常生活中大家都叫我波哥,跟辈分没关系,主要是岁数大了.就一个代称而已. 我的00后小同事我喊都是带哥的.张哥,李哥的. 但是这个称呼呀,在线下参加一些活动时.金主爸爸也这么叫就显的不太合适. 比如上次某集团策划总监,公司开大会来一句:“今个咱高兴!有请IT运维技术圈的波哥讲两句“ 这个氛围配这个称呼在互联网这行来讲就有点对不齐! 每次遇到这个情况我就想这么接话: “遇到各位是缘分,承蒙厚爱,啥也别说了,都在酒里了.我干了,你们随意!” 所以以后咱们改叫老杨,即市井又低调.还挺亲切,我觉得挺好.

运维X档案系列文章:

从告警到CTO：一个P0故障的11小时生死时速

企业级 Kubernetes 集群安全加固全攻略（附带一键检查脚本）

老杨的关于AI的号

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2025-08-11，如有侵权请联系 cloudcommunity@tencent.com 删除

日志