掉电后ext3驱动不会挂载;如何恢复文件?

pri*_*uff 5 linux troubleshooting data-recovery fsck ubuntu

最近电源故障导致我的 linux 机器 (Ubuntu 8.10) 从正常运行状态快速关闭电源两次后,我有一个无法安装的驱动器。

更新:驱动器有时会挂载,但显示为完全空的(甚至不是 Lost+Found)并显示 14.9 GB 可用空间(它是 500GB 驱动器)当我尝试做任何事情时,它给我一个权限错误并且驱动器卸载。(或者,也许,一开始就没有真正安装?)

这是我尝试挂载时的错误消息:

~$ sudo mount -a
mount:错误的 fs 类型,错误的选项,/dev/sdd1 上的超级块错误,
       缺少代码页或帮助程序,或其他错误
       在某些情况下,可以在 syslog 中找到有用的信息 - 尝试
       留言 | 尾巴左右

那么也许指定 fs 类型?

~$ sudo mount -t ext3 /dev/sdd1 /media/disk-7
mount:错误的 fs 类型,错误的选项,/dev/sdd1 上的超级块错误,
       缺少代码页或帮助程序,或其他错误
       在某些情况下,可以在 syslog 中找到有用的信息 - 尝试
       留言 | 尾巴左右

不,一样。所以有什么事情搞砸了?

~$ sudo fsck /dev/sdd1
fsck 1.41.3(2008 年 10 月 12 日)
e2fsck 1.41.3(2008 年 10 月 12 日)
/dev/sdd1:恢复日志
fsck.ext3:尝试重新打开 /dev/sdd1 时没有这样的文件或目录
警告...设备 /dev/sdd1 的 fsck.ext3 以信号 11 退出。

谷歌搜索信号 11 并不令人鼓舞,但我找到了一些其他方法来尝试修复磁盘:

~$ sudo e2fsck /dev/sdd1
e2fsck 1.41.3(2008 年 10 月 12 日)
/dev/sdd1:恢复日志
e2fsck:尝试打开 /dev/sdd1 时没有这样的文件或目录

无法读取超级块或未描述正确的 ext2
文件系统。如果设备有效并且它确实包含一个 ext2
文件系统(而不是交换或 ufs 或其他东西),然后是超级块
已损坏,您可以尝试使用备用超级块运行 e2fsck:
    e2fsck -b 8193 [设备] 

仍然希望这次失败与停电有关,我假设超级块已损坏或其他原因,然后尝试另一个:(我首先使用 makefs -n 确定我的块大小为 32k)

~$ sudo e2fsck -b 32768 /dev/sdd1
e2fsck 1.41.3(2008 年 10 月 12 日)
ext3 恢复标志清除,但日志有数据。
备份超级块中未设置恢复标志,因此无论如何都要运行日志。
/dev/sdd1:恢复日志
e2fsck:恢复时日志必须至少为 1024 个块 
/dev/sdd1 的 ext3 日志

根据下面的 Avery Payne,我尝试了以下操作:

须藤挂载 -t ext2 -o ro /dev/sdd1 /media/disk-7

但收到此错误消息:

mount:错误的 fs 类型,错误的选项,/dev/sdd1 上的超级块错误,
       缺少代码页或帮助程序,或其他错误
       在某些情况下,可以在 syslog 中找到有用的信息 - 尝试
       留言 | 尾巴左右
~$ dmesg | 尾巴
[261157.639721] EXT2-fs:sdd1:由于不支持的可选功能(4)而无法安装。

这就是我被困的地方。我尝试了列出的每个备份超级块并得到相​​同的结果。如果有帮助,“恢复日志”步骤需要很长时间才能继续告诉我它不起作用。

老实说,我不太关心在崩溃前几分钟恢复驱动器的状态,只关心恢复驱动器上 400+ GB 的其他数据。如果有人知道我可以尝试的其他任何东西,ext3 数据恢复实用程序或技术等,我将不胜感激!

Jim*_*nis 4

您遇到的问题听起来比我预期的设备上单纯断电(即使在相当繁重的写入活动期间)要严重得多。我想知道您是否真的在接口/驱动程序级别上遇到了更多问题,或者损坏的分区表或类似的问题。

从事情的声音来看,您在尝试解决问题时所做的所有努力可能进一步加剧了问题。

我不知道我们是否可以帮助解决这个案子,但不要放弃。

对于未来,我建议您学习以下技术:

当 Linux 或 UNIX 下的驱动器出现问题时,通常可以使用dd将整个设备的位映像副本复制到其他位置。找到一个至少与相关驱动器一样大的驱动器,然后尝试执行以下命令: dd if=$PROBLEMATIC of=$TARGET bs=4M... 请非常小心 if(输入文件)和 of(输出文件)指令。离开那个运行。tail -f /var/log/messages &运行(或适合您的 /etc/syslog.conf 的可能变体)是个好主意...要么在后台执行,要么在另一个窗口中执行。有一些增强版本dd可以更稳健地处理重试和继续过去的坏块(sdd这是我想到的一个名字)。dd但首先尝试只使用常用的 GNU命令。

您可以制作整个设备(例如 /dev/sdd)或分区(/dev/sdd1)的副本。如果您收到“短读取或类似错误”,则表明设备存在物理错误,阻止读取超过某些柱面,或者在分区的情况下,分区表以某种方式损坏。您甚至可以制作两个不同的dd映像... 一人一个。

窍门如下:进行所有fsck尝试mount,并在复制的图像上使用各种其他恢复工具,例如 TCT(验尸官工具包)!

这可以最大限度地减少运行驱动器所花费的时间(在操作驱动器时可能会在硬件级别上降低性能),并最大限度地减少失败和可能被误导的恢复尝试的影响。(在某些情况下,您制作一张图像,然后根据该图像制作另一张图像,并始终对第三张图像进行操作......取决于数据的价值)。

我个人建议您运行类似hexdump或 的strings操作来阅读图像......只需让它滚动很长时间并查找看起来可能是数据片段的纯文本。我曾经grep从完全损坏的文件系统中恢复有用的(文本)数据。万一我不建议将其作为数据恢复英雄……而是作为健全性检查。如果您滚动浏览数十兆字节或几千兆字节的数据,但没有看到任何可识别的文本...那么您可能遇到了绝望的情况,或者您做了一些非常错误的事情(您是否真的小心那些 if= 和 of = 选项?)。

我不知道这些是否会对您当前的努力有所帮助。但现在学习这些技巧,它们肯定会让您下次尝试数据恢复不再那么可怕。(是的,在健康的系统上练习一两次——去使用十六进制编辑器并尝试在这里或那里添加您自己的创造性损坏——当然是在副本中!然后尝试修复它)。

哦,这是审查您的备份和数据恢复计划和程序(或向您的客户/同事/客户/朋友/其他人提供更好的建议)的好时机。