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

Question

我在 Debian wheezy 安装上的主分区是一个加密的 LVM 卷。它是ext3。今天早些时候，我在终端窗口中收到一条奇怪的消息，关于尝试写入我的/home树中的文件由于具有只读文件系统而失败。我重新启动并最终得到一条错误消息，说/dev/sda1 is reported as clean. fsck.ext3，它会自动运行并报告没有这样的设备，/dev/mapper/sda1_crypt并报告退出代码 8。我进入维护外壳并被告知尝试将日志写入/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

这些之后是 2 个在 I 节点 anothernumber 中多重声明的块：[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。这似乎很合理，而且不太可能让事情变得更糟。所以，这就是目前的攻击计划，等待任何更好的建议。

Answer 1

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

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

镜像磁盘的建议也不错。这是badblocks -n检查的“精简版”版本，因为通过强制磁盘在每个扇区中读取，它会导致磁盘重新定位问题块badblocks -n。badblocks -n更有效，因为狡猾的扇区几乎无法读取，并且只能通过尝试写入它们来显示到磁盘足以移动。尽管如此，如果磁盘有足够的生命来进行救援，额外的读取通道将不足以完成它。

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

我的数据被烘烤了吗？

可能，也可能不是。该badblocks -n通有时可以解决这个问题。如果是这样，您仍然需要更换硬盘，因为磁盘只有在启动时几乎死机才能进入如此糟糕的状态。

我是不是已经做错了？

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