星期一早上的错误：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。

进入Hetzner提供的救援系统，并检查造成的损坏。
将所有文件传输到安全位置，然后重新部署服务器。

恐怕这是您的最佳解决方案。

事实是？在这一点上，还没有简单/容易的自动修复方法。数据恢复是一门科学，即使是基本的通用工具也需要有人坐下来并确保数据在那里。如果您希望在不造成大量停机的情况下从中恢复，那么您将感到失望。

我建议使用testdisk 或某些文件系统特定的恢复工具。尝试一个系统，看看它是否有效，依此类推。没有真正的方法可以自动执行该过程，但是您可以分批谨慎地进行。

就是说，问题和评论中有一些非常可怕的事情应该作为您的事后报告的一部分。

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

其次

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

吓到我。文件级备份的一种方法是解决的问题。Rsync可用于保留权限并以一种方式将文件复制到备份站点。不小心有事吗？重新安装（最好自动安装）rsync，一切正常。将来，您可能会在btrfs或zfs快照中使用文件系统级别的快照，并将这些快照用于系统级备份。实际上，我建议将应用程序服务器，数据库和存储区分开来，并介绍最小特权原则，以便您分担此类风险。

我知道有什么我能做的。我现在需要思考如何保护自己

发生某些事情之后，是考虑这一点的最坏时间。

我们可以从中学到什么？

1. 备份保存数据。可能是职业。
2. 如果您有工具，却不知道它能做什么，那就很危险。绝地武士可以用光剑做奇妙的事情。一小撮黑猩猩和光剑……会变得凌乱。

3. 永远不要一次到处运行命令。分离测试和生产机器，最好分阶段进行生产。最好修复1或10台计算机，而不是100或1000。

4. 两次和三次检查命令。要求同事仔细检查“嘿，我要加一个驱动器，您能不能理智地检查一下，以便我最后不擦驱动器，”是没有耻辱的。包装器也可能有帮助，但没有什么能打动疲倦的眼睛。

你现在可以做什么？获取发给客户的电子邮件。让他们知道停机时间和灾难性的故障。与您的上司，律师，销售人员等交谈，看看如何减轻损失。开始计划恢复，如果需要，您最多将需要雇用更多人员。最坏的情况是，计划花很多钱进行恢复。在此阶段，您将努力减轻故障和技术修复。

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

正如@faker在回答中所说，最好的做法是将文件传输到安全位置，然后再重新部署服务器。

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

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

• 不需要时不要以root身份工作。而且总是做任何事情之前三思而后行。我建议您也安装safe-rm。

• 为此，请勿键入您不希望调用的选项，例如--no-preserve-root或--permission-to-kill-kittens-explicitly-granted。

我遇到了同样的问题，但是仅仅用硬盘进行测试，我就失去了一切。我不知道它是否有用，但是什么也不要安装，不要覆盖数据，您需要挂载硬盘并启动一些取证工具，例如验尸，光记录，测试磁盘。

我强烈建议您使用一些基本命令Testdisk，如果不覆盖数据，则可以恢复数据。

解决此类问题的最佳方法是一开始就不要设置它。

不要手动输入在参数列表中带有斜线的“ rm -rf”命令。（将这样的命令放入具有良好验证/健全例程的shell脚本中以防止您执行愚蠢的操作是不同的。）

只是不要这样做。
曾经 如果您认为需要这样做，则表示您没有足够的努力。

而是将您的工作目录更改为您打算从中开始删除的目录的父目录，以便rm命令的目标不需要斜杠：

cd / mnt

须藤rm -rf hetznerbackup

我会尝试恢复备份机器，其中存储所有副本：

• 第一步-使用ddcomand 备份此已擦除的“ backup machine”驱动器 。
• 第二步- testdisk用于恢复文件。

因此，假设您要恢复1TB，则需要额外的2TB，其中1TB用于备份（第一步），再加上1TB用于恢复（第二步）。

我使用别名rm -fr [phone rang]和cd到珍贵目录也犯了类似的错误。现在我总是三思而后行，然后在使用rm或dd命令之前重新检查几次。

如另一个答案所述，Hetzner具有救援系统。它既包含具有ssh访问权限的netboot选项，又包含一个Java小程序，可在vserver上为您提供屏幕和键盘。

如果要尽可能地恢复，请从适当的设备索引节点读取信息，然后将服务器重新引导到netboot系统，然后登录并下载文件系统的映像。

我认为这样的事情应该起作用：

ssh root@host cat /dev/sda > server.img

当然，重定向是在调用ssh命令之前由外壳完成的，因此server.img是本地文件。如果只需要根文件系统而不是整个磁盘，请替换sda为sda3假定使用的映像与我相同。

您将如何从这里前进？

我会rm在余生中发誓不再使用，并认为疯狂垃圾回收不是nix系统上的默认删除命令是疯狂的。

https://github.com/andreafrancia/trash-cli

我将确保这是我在全新系统上安装的第一件事，并且alias rm要告诉别人使用它trash-cli。它还将包含关于另一个实际运行的别名的注释，/bin/rm但告诉他们在大多数情况下避免使用它。

：（ 真实的故事

在这种情况下，我建议您卸下并使用debugfs，并借助lsdel可以列出所有最近删除的文件，这些文件不会从日志中清除，然后转储所需的文件。相同的快速搜索链接：http : //www.linuxvoodoo.com/resources/howtos/debugfs

希望对别人有帮助。;）

是的，曾经有一个建议是制作脚本，该脚本将ream rm移至real.rm并将symlinc mv移至rm ;）

停止所有服务器进程以及可能导致磁盘I / O的所有事情……然后运行testdisk，它应该在软件堆栈中。如果您具有物理访问权限，请将livecd与testdisk一起使用。