系统与基础设施ee.ryerson.ca
Unix 恢复传奇
Unix recovery legend
2010 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇经典故事讲述一次严重的 Unix 误删事故：大量关键系统文件和命令被删掉后，机器仍在运行，管理员仅凭剩下的 root shell 和仍在运行的进程，利用 /proc 等机制一步步把系统救回来。它常被称作 Unix 恢复传奇，是早期系统管理员口口相传的应急恢复案例。
为什么经久不衰：它把 Unix 在极端故障下仍能运行、以及管理员冷静利用 /proc 和残留 shell 的智慧展现得淋漓尽致，所以每次被重提都值得读。
HN 评论精选
远程只有单个 root shell 时也能完成恢复，印证了故事中的情形。
我在一条卫星链路的远端遇到过几乎一模一样的情况，机器是 SunOS，人在美国而我们在新西兰。只能说，靠 bash 和一个 root shell 能做很多事。
jamesotron查看英文原文
I have experienced this very thing with a SunOS box at the remote end of a satellite link. It was in the US and we were in NZ. Let's just say that you can do a lot with bash and a single root shell.
执行通配符删除前先用 echo 预览，是避免误删的关键习惯。
我作为系统管理员养成的最重要习惯就是：三思而后行（量两次，剪一次）。我从不会直接执行 sudo rm *。我会先执行 echo sudo rm *，检查输出，然后用命令行编辑调回这条命令，再把 echo 删掉。凡是涉及通配符的操作我几乎都这么做。这能救命。
FfejL查看英文原文
Single most important habit I've developed as a SysAdmin: measure twice, cut once. I never just sudo rm * First, I do echo sudo rm * inspect the output, and then use CLI editing to recall the command, and delete the "echo" I do this for damn near everything that involves a wildcard. It's a lifesaver.
恢复文件系统时先只读排查、验证假设，不要慌乱动手。
我不展开细节——那些过程又长又折磨人，而且照例发生在凌晨。rsync.net 过去只跑 UFS2，2009/2010 年前后我们把 UFS2 推到磁盘容量、每文件系统 inode 数量、fsck 所需内存等极限，好几次非常接近毁掉文件系统、丢失客户数据。每次化险为夷的关键都是：不要慌；先假设发生了什么；做一件非破坏性的事来验证或推翻假设；必要时重复。慢下来，在证明自己理解了问题之前不要动手。另外，处理文件系统时别忘了可以以只读模式非破坏性地运行；很多排查都可以在显式只读模式或把 fsck 等工具设为不写入/非破坏性的情况下完成。第一步永远应该是只读。
rsync查看英文原文
I'm not going to go into details - they are long, torturous and (of course) occurred very early in the morning - as they always did. But, rsync.net used to run - exclusively - on UFS2 and, circa 2009/2010 we were pushing UFS2 to the very limits in terms of disk size, number of inodes per filesystem, size of memory used to fsck, etc.[1] Several times we came very, very close to destroying a filesystem and losing customer data. What made all the difference, every time, was: - don't panic - postulate what is happening - do something non destructive that will prove or disprove the theory - possibly repeat Go slow and don't take any steps until you have proven that you understand the problem. ALSO, when working with filesystems remember that you can run a filesystem, non-destructively, in read-only mode. There are a lot of investigations that can be done on a filesystem in either explicitly read-only mode or with tools (like fsck) set to run no-write, or non-destructive. Your first steps should always be read-only ... [1] I asked Kirk M., in 2010, what the long term solution to our problems with UFS was and he said "migrate to ZFS".
被删文件若仍被进程打开，可从 /proc/<pid>/fd 恢复。
还有一件有用的常识：如果你删除了一个文件，但仍有进程打开着它，你可以从 /proc 里的文件描述符把它复制出来！用 lsof 找到 PID 和 FD 即可。这招过去救过我几次。
pram查看英文原文
Another useful thing to remember: if you deleted a file and a process still has it open, you can copy it from the file descriptor in /proc! Just use lsof to find the PID and FD. This has saved my bacon a few times in the past ;P
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选