☰

зашифрованный 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. Меня перебрасывает в оболочку обслуживания и сообщает, что была попытка записи журнала в /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 на копии этого образа. Это кажется разумным и вряд ли ухудшит ситуацию. Так что это текущий план атаки, ожидающий лучших предложений.

решение1

Похоже, что у самого жесткого диска возникли проблемы («неполное чтение» и т. д.). Если это так, то, dmesg | tailвероятно, будут обнаружены некоторые ошибки ввода-вывода.

Другой способ проверить это — запустить badblocks -nна проблемном разделе. Или лучше на всем диске. Что бы вы ни тестировали, это нужно размонтировать. Это займет часы на большом современном диске. Если на разделе(ах) есть что-то, что монтируется, и без чего вы не можете жить, сначала скопируйте это на съемный носитель или сетевой том.

Предложение зеркалировать диск тоже хорошее. Это своего рода "облегченная" версия проверки badblocks -n, потому что, заставляя диск читать каждый сектор, это может заставить диск переместить проблемные блоки, как и badblocks -nбудет. badblocks -nболее эффективно, потому что подозрительные сектора могут быть едва читаемыми и будут показаны диску как достаточно плохие для перемещения только при попытке записи на них. Тем не менее, если у диска осталось достаточно жизни, чтобы пережить спасение, дополнительного прохода чтения будет недостаточно, чтобы прикончить его.

Я не питаю больших надежд на то, что запуск fsckобраза диска восстановит все. Вы почти наверняка потеряете сектора в этом процессе, что означает, что некоторые файлы будут нечитаемыми или поврежденными до невозможности использования. JPEG будет частично декодироваться с поврежденными данными, например, но JPEG с обрезанными нижними ⅔ может быть бесполезен для вас.

Мои данные уничтожены?

Возможно, возможно и нет. badblocks -nИногда проход может решить проблему. Если это так, вам все равно придется заменить жесткий диск, поскольку диск может прийти в такое плохое состояние только будучи практически мертвым с самого начала.

Я уже сделал что-то не так?

Кроме того, что я забыл значение слова «строгий», то нет. :)

решение2

Надеюсь, у вас есть актуальный резервный образ, из которого можно выполнить восстановление.

Я бы сделал ограниченную резервную копию СЕЙЧАС всего, что вы хотите сохранить, а затем проверил бы, можно ли еще использовать диск. Один трюк, который я использовал, состоял в том, чтобы использовать устройство раздела RAW и dd его в /dev/null.....с соответствующей опцией область, которая не может быть прочитана, будет идентифицирована.

Связанный контент