我不小心压缩了整个服务器

好吧，如果有人想扮演上帝并创造奇迹，我会失望的。

因此，我的任务是制作一个脚本，该脚本可以找到6个月以上的文件，将其压缩然后删除。在制作该脚本的过程中，我运行了此命令：

find / -type f -mtime -400 ! -mtime -180 | xargs gzip blablabla

这给每个单文件一个.gz扩展名。现在我一发现就撤消了，但是为时已晚。命令完成后，我的bash命令都不起作用，因为$ PATH变量已清空。在意识到问题所在之前，我尝试了很多事情。

因此，请解压缩我仍然无法启动的所有内容。在遵循网上指示进行以下操作后，我设法使其得以抢救：

root (hd0,0)
setup (hd0)
kernel (hd0,0)/boot/vml[...]
initrd (hd0,0)/boot/initrd.im[...]

在将我的Linux部分启动之后，却给我以下错误：

Begin : Running /scripts/init-bottom ... mount : mounting /dev on /root/dev failed : No such file or directory
mount: mounting /sys/ on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed : No such file or directory
Target filesystem doesn't have requrested /sbin/init.
No init found. Try passing init= bootarg.

我尝试修复文件系统，从3种不同的LiveCD /救援磁盘启动，从2种不同的dicsc进行引导修复。我确实强迫了fscks ...

我真的没有主意，我需要让该服务器至少启动，以便我可以恢复我的SQL数据库。我迫切需要帮助，如果需要我什至会付钱。

我整天都在论坛上潜伏了3天，以寻找可能的解决方案，但我仍然处于同一时间...请帮忙吗？

linux boot gzip

— 德西里安
source

如果它们是mysql db，则不必启动；在这种情况下，我将尝试将驱动器作为从站挂载并复制到/ var / lib / mysql目录中

— user16081-JoeT 2013年

全新安装在新的存储设备上。安装旧驱动器，根据需要传输数据。我敢打赌，修理将不值得。

— Zoredache

这是从备份还原的点。请记住，下次不要以root用户身份来执行非特权操作。

— 麦哲伦

because of version differences,用完全相同的版本重新安装。 we have corruption issues,您的数据可能已损坏。如果数据已被破坏，则修复系统使其可引导，将无济于事。如果在使用数据库时gzip命令压缩了数据库文件，则损坏似乎是不可避免的。

— Zoredache

如果运行这些命令时数据库软件正在运行，则可能无法恢复数据库。Gzip会愉快地压缩文件，然后取消链接。但是您的数据库软件仍然打开了文件，并且正在提交对其所做的更改。一旦停止，该文件便被删除。

— toppledwagon

Answers:

这将取决于文件系统是否已修复得足够使您能够从LiveCD挂载那些分区。不要打扰尝试启动系统。首先，安装分区并解压缩所有.gz文件。这将为您提供init和系统二进制文件的工作副本。然后，您可以使用grub修复引导扇区。然后引导至单用户模式并再次fsck文件系统。如果可行，您将拥有一个正在运行的系统。您还将拥有一堆确实应该压缩的未压缩文件（例如手册页），但是比拥有不可引导的系统要好。

如果无法从LiveCD挂载分区，那么很遗憾，您很不幸。此时，您将无法恢复系统。

— 迈克尔·马丁内斯
source

这实际上起到了一种魅力的作用……我为此不胜感激！MySQL不会启动，但是我还没有做--force fsck，希望它能解决它！谢谢

— Dexirian

太棒了很高兴它有所帮助。

— Michael Martinez

我要尝试的第一件事是运行LiveCD环境，并尝试将所有内容解压缩，希望这会使系统返回到可启动状态。注意：如果原始gzip进程被中断，我将担心潜在的数据损坏。

否则，我会尝试按照其他人的建议将数据库迁移到新系统，但是正如您所遇到的那样，可能存在劳动密集型依赖性和配置问题，需要单独解决。

— 鲍勃·巴克
source

快速的问题：我们不确定旧的SQL数据库服务器，而新的服务器正在使用其他Linux Distro。较新的服务器正在运行带有WHM的CentOS，而较旧的服务器是Debian / Unbuntu。所以我的问题是，如何才能有效地迁移我的SQL数据库而又不会损坏呢？

— Dexirian

此处的普遍共识是，您应该仅将磁盘挂载在工作系统中并营救文件，这没有错。这是明智的选择。但是另一种方式更有趣，而且很有教育意义。在摆脱混乱的局面时，我学到了很多东西，而在这种混乱的情况下，其他人只会放弃并从头开始安装。（虽然不在其他人所依赖的服务器上...）

无论如何，到目前为止，您已经运行了一个initramfs（initrd）。这是一个好的开始。但是它不能完成到init的切换，因为现在init.gz也许是init ？为了取得任何进展，这将有助于准确了解您拥有的Linux发行版，因此我们可以在initramfs中查找可用于紧急使用的工具。

您呈现的错误消息看起来可能是来自Debian的initramfs。如果是Debian，那么您应该(initramfs)在最后一个错误之后的下一行获得了shell提示符。如果这样做了，您应该调查那些失败的挂载的情况。被/root/dev遗漏？（这/root是在运行initramfs时应挂载普通根fs的位置）

如果没有得到shell提示，那么后续操作No init found. Try passing init= bootarg.将很有趣。即使只是光标闪烁而已，这也是一个提示。如果看上去完全死机了，请尝试使用magic sysrq或Ctrl + ScrollLock来获取有关仍在进行哪些进程的一些信息。

Debian initramfs还允许您通过向break=内核命令行添加参数来在一些特殊的地标处请求shell 。例如，要Running /scripts/init-bottom在行之前获取外壳，请使用break=bottom。

另外：我不知道该find命令如何压缩每个文件...对于选择180到400天之间的文件，它对我来说似乎是正确的。

当我在/ root下执行ls时，找不到任何内容。所以我可以认为启动时fs安装不好吗？我在哪里可以更改？

— Dexirian

@Dexirian，所以您确实得到了shell提示符（是否必须使用break=bottom？）...是的，在尝试挂载/root/devand /root/proc和时/root/sys，它/root应该是真正的根文件系统。以前肯定有一条错误消息，关于无法挂载它。您是否root=在内核命令行中包含参数？关于这一点，我的记忆有些模糊，但是我认为这root (hd0,0)只是告诉grub在哪里找到其支持文件，而您仍然需要分别告诉内核根目录。

是的，我确实使用过root =，kernel = initrd =和setup =，而我不必使用break = bottom。而且我没有发现较早的安装失败消息，因为它滚动得非常快

— Dexirian

@Dexirian控制台回滚可用吗？Shift + PgUp。您能在(initramfs) 提示时安装它mount -r /dev/sda1 /root吗？cat /proc/partitions查看可用的磁盘。

欢迎来到系统管理的世界。

— Michael Martinez