☰

加密的 ext3 损坏；如何进行？

tag-icon • tag-icon encryption data-recovery fsck
加密的 ext3 损坏；如何进行？

我在 Debian wheezy 安装上的主分区是一个加密的 LVM 卷。是ext3。今天早些时候，我在终端窗口中收到一条奇怪的消息，称尝试写入/home树中的文件由于只读文件系统而失败。我重新启动并最终收到一条错误消息/dev/sda1 is reported as clean. fsck.ext3，该消息自动运行并报告没有这样的设备，/dev/mapper/sda1_crypt并报告退出代码 8。我被带到维护 shell 并被告知有人试图将日志写入/var/log/fsck/checkfs。

该日志写道：

[Timestamp]

fsck from util-linux 2.20.1
/dev/mapper/sda1_crypt: Super blocks need_recovery flag is clear, but journal has data.
/dev/mapper/sda1_crypt: Run journal anyway

/dev/mapper/sda1_crypt: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
     (i.e., without -a or -p options)
fsck died with exit status 4

我跑了

$ fsck -vnM /dev/mapper/sda1

一堆illegal block #nnnn (mmmmmmmmm) in inode ppppppp IGNORED消息飞过，紧接着

too many blocks in Inode somenumberhere

然后运行额外的传递来解析多个 inode 声明的块

然后输出

Pass 1B: Rescanning for multiply claimed blocks

过了一会儿，我得到了一堵墙

Illegal block number passed to ext2fs_test_block_bitmap somenumberhere for multiply claimed block map

接下来是 I 节点 anothernumber 中的 2 个乘法声明块：[5 和 8 块编号的列表]

然后我得到了一些像这样的节

[ 3828.181915] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 3828.182462] ata1.01 BMDMA stat 0x64
[ 3828.183810] ata1.01 failed command: READ DMA EXT
[ 3828.185889] ata1.01 cmd 25/00:08:08:10:9c/00:00:29:00:00/f0 tag dma 4096 in
[ 3828.185891] res 51/40:00:09:10:9c/40:00:29:00:00/f0 Emask 0x9 (media error)
[ 3828.190071] ata1.01 status: { DRDY ERR }
[ 3828.192153] ata1.01 status: { UNC }

随后是

[ 3830.509338] end_request: I/O error, deb SDA, sector 698093577
[ 3830.509841] Buffer I/O error on device dm-3, logical block 87261184
Error reading block 87261184 (Attempt to read block from filesystem resulted in short read) while reading I node and block bitmaps. Ignore error? no

fsck.ext3: Can't read an block bitmap while retrying to read bitmaps for /dev/mappersfa1_crypt

/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******

e2fsck: aborted

/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******

它中止并警告文件系统仍然有错误。

我的问题是：

  1. 我的数据被烘烤了吗？ （我严格的备份政策最近没有得到严格遵守；我确信我正在受到宇宙的惩罚。）

  2. 我现在可以/应该做什么？

  3. 难道我已经做错事了吗？

  4. 有人会抱住我直到震动停止吗？

编辑

我还在本地 LUG 邮件列表上询问过。我得到的建议是使用 ddrescue 拍摄驱动器的映像，并在该映像的副本上运行 fsck。这似乎很合理，而且不太可能让事情变得更糟。所以，这就是目前的攻击计划，等待任何更好的建议。

答案1

感觉是硬盘本身有问题。 （“短读”等）如果是这样，dmesg | tail可能会显示一些 I/O 错误。

检查这一点的另一种方法是badblocks -n在有问题的分区上运行。或者更好，在整个磁盘上。无论您测试什么，都需要将其卸载。在大型现代磁盘上这将需要几个小时。如果分区上确实安装了您离不开的任何内容，请先将其复制到可移动媒体或网络卷上。

对磁盘进行镜像的建议也很好。这是一种“精简”版本的badblocks -n检查，因为通过强制磁盘读取每个扇区，它可能会导致磁盘重新定位问题块，正如badblocks -n所愿。badblocks -n更有效，因为狡猾的扇区几乎无法读取，并且只能通过尝试写入它们来向磁盘显示为坏到足以移动。不过，如果磁盘还有足够的寿命能够在救援中幸存下来，那么额外的读取通道将不足以完成它。

fsck我对在磁盘映像上运行能够恢复一切不抱太大希望。在此过程中您几乎肯定会丢失扇区，这意味着某些文件将无法读取或损坏而无法使用。例如，JPEG 将使用损坏的数据进行部分解码，但底部 ⅔ 被裁剪掉的 JPEG 可能对您没有用处。

我的数据被烘烤了吗？

可能，也可能不是。通行证badblocks -n有时可以解决问题。如果是这样，您仍然需要更换 HDD，因为磁盘只有在几乎无法启动时才会进入这种糟糕的状态。

难道我已经做错事了吗？

除了忘记“严格”这个词的含义之外，没有。 :)

答案2

希望您有可以从中恢复的当前备份映像。

我现在会对您想要保留的任何内容进行有限备份，然后检查磁盘是否仍然可用。我曾经使用的一个技巧是使用 RAW 分区设备并将其添加到 /dev/null ......通过适当的选项，将识别无法读取的区域。

相关内容