☰

周一早上的错误：sudo rm -rf --no-preserve-root /

tag-icon • tag-icon ubuntu-12.04 disaster-recovery hetzner
周一早上的错误：sudo rm -rf --no-preserve-root /

请注意：此问题的答案和评论包含另一个类似问题的内容，该问题已受到外部媒体的广泛关注，但结果却是某种病毒式营销计划中的恶作剧问题。由于我们不允许 ServerFault 以这种方式被滥用，因此原始问题已被删除，答案已与此问题合并。

这是一个有趣的悲剧。今天早上，我在对生产服务器进行一些维护时，错误地执行了以下命令：

sudo rm -rf --no-preserve-root /mnt/hetznerbackup /

我之前没有注意到最后一个空格/，几秒钟后，当警告充斥着我的命令行时，我意识到我刚刚点击了自毁按钮。以下是一些让我印象深刻的内容：

rm: cannot remove `/mnt/hetznerbackup': Is a directory
rm: cannot remove `/sys/fs/ecryptfs/version': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/inode_readahead_blks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_max_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/delayed_allocation_blocks': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/max_writeback_mb_bump': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stream_req': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_min_to_scan': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/mb_stats': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/trigger_fs_error': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/session_write_kbytes': Operation not permitted
rm: cannot remove `/sys/fs/ext4/md2/lifetime_write_kbytes': Operation not permitted
# and so on..

我停下了任务，发现生产服务还在运行，顿时松了一口气。遗憾的是，服务器不再接受任何通过 SSH 的用户的公钥或密码。

您将如何继续前进？我将穿越铁丝网海洋，夺回 SSH 访问权限。

该服务器运行 Ubuntu-12.04 并托管在 Hetzner。

答案1

启动 Hetzner 提供的救援系统并检查您造成的损害。
将所有文件转移到安全位置，然后重新部署服务器。

恐怕对于你的情况来说这是最好的解决方案。

答案2

事实是？目前，没有简单/简单的自动修复方法。数据恢复是一种科学甚至基本的常用工具也需要有人坐下来确保数据在那里。如果你期望在没有大量停机时间的情况下恢复，那你就会失望。

我建议使用 testdisk或者一些文件系统特定的恢复工具。尝试一个系统，看看它是否有效，等等。没有真正的方法可以自动化这个过程但你也许可以小心分批进行。

话虽如此，问题和评论中还是有一些非常可怕的事情，应该成为你行动后报告的一部分。

首先，你没有先检查命令，就到处运行了该命令。在一个框上运行命令。然后是几个，然后是更多。基本上，如果出现问题，最好让它影响一个很少而不是所有系统。

第二

@Tim 如何在不在服务器上安装远程驱动器的情况下进行备份？

吓死我了。文件级单向备份是已解决的问题. Rsync 可用于保留权限并复制文件单程到备份站点。意外发生什么了？重新安装（最好是自动）rsync，一切就绪。将来，您可能会使用带有 btrfs 或 zfs 快照的文件系统级快照，并将它们发送用于系统级备份。我实际上会尝试分离应用程序服务器、数据库和存储，并引入最小特权原则，这样您就可以分散类似这样的风险。

我知道我能做任何事情。我现在需要考虑如何保护自己

事情发生之后并不是考虑这个问题的最坏时机。

我们可以从中学到什么？

  1. 备份可以保存数据。也可能保存职业生涯。
  2. 如果你有工具却不知道它能做什么，那就很危险了。绝地武士可以用光剑做出惊人的事情。满屋子拿着光剑的黑猩猩……会弄得一团糟。

  3. 永远不要同时在所有地方运行命令。将测试和生产机器分开，最好分阶段处理生产机器。最好修复 1 台或 10 台机器，而不是 100 台或 1000 台。

  4. 反复检查命令。要求同事反复检查“嘿，我即将添加一个驱动器，你能检查一下这个，这样我就不会最终擦除驱动器吗？”，这没什么不好意思。包装纸可能也有帮助，但没有什么比一双不那么疲惫的眼睛更好了。

你现在能做什么？给客户发一封电子邮件。让他们知道停机和灾难性故障。与你的上级、法律、销售等人员交谈，看看如何减轻损失。开始规划恢复，如果需要，你最好雇佣额外的人手。最坏的情况是，计划在恢复上花费大量资金。在这个阶段，你将努力减轻后果以及进行技术修复。

答案3

当您使用 删除内容时rm -rf --no-preserve-root，几乎不可能恢复。您很可能丢失了所有重要文件。

作为@骗子他在回答中说，最好的做法是将文件转移到安全的地方，然后重新部署服务器。

为了避免将来出现类似的情况，我建议您：

  • 进行备份每周一次，或者至少每两周一次。这将帮助您以尽可能短的 MTTR 恢复受影响的服务。

  • 不需要时不要以 root 身份工作。 和总是做任何事前都要三思。我建议你也安装安全保证。

  • 不要输入你不打算调用的选项，例如--no-preserve-root或--permission-to-kill-kittens-explicitly-granted。

答案4

解决此类问题的最好方法是从一开始就避免这个问题。

不要手动输入参数列表中带有斜线的“rm -rf”命令。（将此类命令放入具有真正良好的验证/健全性例程的 shell 脚本中以防止您做蠢事是不同的。）

千万别这么做。
永远不要。如果你认为你需要这么做，那说明你还不够认真思考。

相反，将您的工作目录更改为您打算开始删除的目录的父目录，这样 rm 命令的目标就不需要斜杠：

cd /mnt

sudo rm-rf hetznerbackup

相关内容