Вопрос или проблема
У меня есть жесткий диск на 8 ТБ, на котором есть несколько плохих секторов. Файловая система — ext4 с одним большим разделом. Я смонтировал его в режиме только для чтения и заметил, что некоторые файлы/папки, которые должны там быть, отсутствуют; кроме того, dmesg сообщил об ошибках чтения (как и ожидалось) при попытке просмотреть файловую систему.
Поэтому я снова размонтировал его, затем использовал ddrescue, чтобы скопировать раздел в файл образа, и он спас 99,99% данных. Затем я смонтировал файл образа в режиме только для чтения, и еще больше файлов/папок отсутствовали. Прежде чем у диска начались проблемы, на нем было около 28 ГБ свободного места, но теперь как на диске, так и на файле образа при монтировании отображается 419 ГБ свободного места.
Этот диск использовался в качестве резервного, поэтому данные не столь важны, но было бы хорошо восстановить то, что можно.
Вывод ddrescue, прямо перед остановкой и монтированием файла образа:
Изначальное состояние (прочитано из файла карты)
спасено: 8001 ГБ, попыток: 24494 кБ, плохие секторы: 32768 Б, плохие области: 50
Текущее состояние
ipos: 917084 МБ, необработано: 10616 кБ, текущая скорость: 0 Б/с
opos: 917084 МБ, не соскребано: 20856 кБ, средняя скорость: 0 Б/с
непроверено: 133038 кБ, плохие секторы: 32768 Б, ошибка скорости: 3276 Б/с
спасено: 8001 ГБ, плохие области: 50, время выполнения: 32м 55с
% спасено: 99,99%, ошибки чтения: 107, время до завершения: н/д
время с момента последнего успешного чтения: н/д
Копирование необработанных блоков... Проход 5 (вперед)
fdisk:
Диск /dev/sds: 7.28 TiB, 8001563222016 байт, 15628053168 секторов
Модель диска: ST8000VN004-2M21
Единицы: сектора по 1 * 512 = 512 байт
Размер сектора (логический/физический): 512 байт / 4096 байт
Размер ввода-вывода (минимальный/оптимальный): 4096 байт / 4096 байт
Тип метки диска: gpt
Идентификатор диска: 3A4482B4-C72A-B14E-B514-E7FC8F8EC1BF
Устройство Начало Конец Секторы Размер Тип
/dev/sds1 2048 15628053134 15628051087 7.3Т Файловая система Linux
и это команда форматирования, которая изначально использовалась на диске при установке:
mkfs -t ext4 -N 2000000 -m 0 /dev/sds1
и при монтировании файла образа dmesg полон этих ошибок:
[164466.391546] Ошибка EXT4-fs (устройство loop11): ext4_lookup:1760: inode #1702684: команда smbd: iget: недопустимая контрольная сумма
[164466.392370] Ошибка EXT4-fs (устройство loop11): ext4_lookup:1760: inode #1702684: команда smbd: iget: недопустимая контрольная сумма
[164477.134838] Ошибка EXT4-fs (устройство loop11): ext4_lookup:1760: inode #2582801: команда smbd: iget: недопустимая контрольная сумма
[164477.136100] Ошибка EXT4-fs (устройство loop11): ext4_lookup:1760: inode #2582801: команда smbd: iget: недопустимая контрольная сумма
[164477.197242] Ошибка EXT4-fs (устройство loop11): ext4_lookup:1760: inode #2582802: команда smbd: iget: недопустимая контрольная сумма
ОС: Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-204-generic x86_64)
Учитывая, что было восстановлено 99,99% данных диска, интересно, почему теперь отсутствуют несколько сотен ГБ файлов?
Я еще не запускал e2fsck на файле образа, однако, прежде чем это сделать, я ищу советы о том, как лучше всего действовать дальше для восстановления как можно большего количества данных. Есть ли другие инструменты, которые я могу использовать?
Заранее спасибо.
Ответ или решение
Восстановление потерянных файлов с файловой системы ext4 после использования ddrescue — задача, требующая тщательного подхода и понимания процессов восстановления данных. В вашем вопросе описана ситуация с 8 ТБ HDD, который имеет проблемы с сектами и на котором возникли ошибки при доступе к файловой системе ext4. Вы отметили использование утилиты ddrescue для создания образа диска и получили 99.99% данных. Тем не менее, все еще отсутствуют некоторые файлы и доступная емкость на диске увеличилась, что вызывает дополнительные вопросы.
Теория
Файловая система ext4 иногда может работать некорректно на дисках с проблемными секторами, так как любые повреждения в структуре данных файловой системы могут привести к потере доступа к некоторым файлам. Хотя ddrescue является мощным средством для копирования данных с поврежденных дисков, оно все же может не идеально воспроизвести файловую систему в условиях поврежденных данных. Ваша ситуация, скорее всего, связана с тем, что некоторые метаданные файловой системы были повреждены, что привело к неправильному отображению свободного места и отсутствию файлов.
Пример
Ошибки в dmesg, такие как:
EXT4-fs error (device loop11): ext4_lookup:1760: inode #1702684: comm smbd: iget: checksum invalidуказывают на проблемы с контрольными суммами inode, что свидетельствует о повреждении метаданных или данных файлов. Это, в свою очередь, может быть причиной потери доступа к части данных.
Применение
Чтобы максимально эффективно восстановить потерянные файлы, следует рассмотреть несколько шагов:
-
e2fsck: Прежде чем предпринимать другие действия, имеет смысл запустить
e2fsck. Это встроенный инструмент Linux для проверки и восстановления файловых систем ext4. Он может помочь обнаружить и исправить ошибки, которые могут быть связаны с неправильными контрольными суммами inode или другими повреждениями.e2fsck -f -y /путь/к/образуОбратите внимание, что выполнение
e2fsckна образе может потенциально изменить его, что может привести к дополнительным потерям данных, если исправления будут неудачными. Поэтому, сделайте резервную копию образа перед началом. -
TestDisk и PhotoRec: Это еще одни мощные инструменты для восстановления данных.
TestDiskможет помочь восстановить разделы потерь, в то время какPhotoRecфокусируется на восстановлении файлов без зависимости от файловой системы, что может быть полезно в случае значительных повреждений.sudo testdisk /путь/к/образу sudo photorec /путь/к/образу -
Анализ моделей повреждений: Если вы предпочитаете ручное исправление, используйте такие инструменты, как
debugfs, для анализа состояния образа. Это может предоставить больше понимания о том, где могут находиться поврежденные области и как можно работать с ними. -
Создание резервных копий: Раз уж восстановление из этой точки может привести к дальнейшим неожиданностям, обязательно создайте резервную копию всего образа, прежде чем применять любые изменения.
-
Обновление ядра и софта: Поскольку ваш ОС Ubuntu 20.04.4 имеет 5.4.0 ядро, может быть целесообразно обновить его, если доступна более новая версия, исправляющая ошибки с файловыми системами. Например, убедитесь, что
e2fsprogs(пакет, который включаетe2fsck) обновлен до последней версии. -
Профессиональные услуги: Если ваши данные очень важны, подумайте о привлечении профессиональных компаний по восстановлению данных, которые имеют аппаратные средства и специализированные ПО для работы с поврежденными дисками.
Ваша текущая ситуация — это идеальная возможность оценить процедуры резервного копирования и позаботиться о доступности резервных копий в различных местах для критически важной информации. Использование RAID-типов массивов и дополнительно проверенных систем хранения поможет избежать подобных ситуаций в будущем.