最近，我的硬盘崩溃了，我不得不运行fsck命令。许多文件已移至该文件夹，并且我已使用和lost+found检索了重要文件，但我找不到我的 SQL 数据库。findgrep
问题
- 如何在我的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目录恢复文件，第二个脚本可以使用此清单。