![fsck 后文件丢失](https://linux22.com/image/36556/fsck%20%E5%90%8E%E6%96%87%E4%BB%B6%E4%B8%A2%E5%A4%B1.png)
最近,我的硬盘崩溃了,我不得不运行fsck
命令。许多文件已移至该文件夹,并且我已使用和lost+found
检索了重要文件,但我找不到我的 SQL 数据库。find
grep
问题
- 如何在我的lost+found目录中找到InnoDB数据库?
- 有可能 fsck 没有保存我的 SQL 数据库吗?
- 如果是的话我可以恢复这个文件吗?
答案1
尝试#1:
也许它还在那里,只是它的名字改为 fe /lost+found/#3456254 之类的。在你的位置,我file -szL
对 中的所有内容进行了递归/lost+found
,并 grep 了 innodb:
find /lost+found -type f|xargs -P 1 -n 500 file -szL|grep -i innodb
如果其中还有 innodb 数据库,则您可以保存数据。祝你好运!
尝试#2:
如果您的数据库有大量文本数据,基于扇区的六角搜索也可以为您提供帮助。
答案2
有问题的文件可能无法通过 fsck 重建,因为它们已被删除。 fsck 程序仅尝试修复并尽力重建文件。然而,它绝不是任何类型的备份。 fsck 执行的任何操作基本上都是不可逆的。
我在尝试使用“lost+found”目录中包含的 MySQL 数据库部分时会非常小心,因为数据库不包含在一个文件中,而是包含在许多文件中,这些文件必须处于“同步”状态,才能有希望在一个文件中恢复数据库。存在任何类型的可靠性或数据完整性的模式。
至于文件恢复,抱歉,您必须返回到您可能一直在进行的备份,因为数据很重要。不然的话,你就真的不走运了。
如果数据如此重要,那么您也许可以尝试寻求众多数据恢复服务之一的帮助。它价格昂贵,而且结果并不完美。
答案3
我相信你运气不好。您唯一的选择是浏览lost+found
目录并目视检查每个文件,寻找有关其原始名称的线索。
将来
有一篇博文标题为:更新:自动从丢失+找到的文件恢复,其中讨论了两种在这种情况下会有所帮助的工具。
make-lsLR.sh
- 定期调用此函数 (cron) 以创建存储在 /root/ 中的所需文件。当然,您可以轻松更改位置并排除其他目录进行扫描。
check_lost+found.py
- 第二个脚本将在您的 fsck 设法弄乱您的文件并将其存储到丢失+发现目录中时运行。它需要 3 个参数:1) 混乱的lost+found 目录所在的源目录,2) 数据将保存到的目标目录,3) 实际执行而不是空运行的开关。
这两个脚本一起工作,第一个脚本需要定期运行,以构建系统上存在的文件的清单。如果您需要从lost+found
目录恢复文件,第二个脚本可以使用此清单。