Раздел более не содержит ни одного файла

[IlyaLinux]

Добрый день!

После внезапного отказа в ноуте жёсткого диска asmr (копировал на него данные с флешки), полного зависания системы (root-раздел на нём же) и перезагрузки, один из разделов более не содержит ни одного файла в корне, однако, свободного места на разделе ёмкостью 750 ГБ - 2% (так и должно быть). Заказал другой диск, терпеливо дождался доставки, снял не него дамп с повреждённого диска.
Простая попытка полечить fsck, результатов не принесла:

Код Выделить Развернуть

sudo fsck -fy /dev/sda10Он много и грязно ругался, на контрольные суммы, отрицательные числа и прочее, выдал выхлоп на несколько экранов, но файлы так и не появились, свободного места также не прибавилось.

Пытаюсь что-то сделать при помощи debugfs, но получаю такое:

Код Выделить Развернуть

debugfs:  ls -l <2>
-l: Directory block checksum does not match directory blockКорень не показывает. В этой утилите не так силён, просьба подсказать, что ещё можно попробовать?

Доп:
При снятии дампа dd первые секунды медленно работала, а старый диск сильно хрустел. Но, вроде как, считала, ошибок чтения не вывела. Потом разогналась до 100 МБ/сек. Суперблок на месте, монтировать раздел получается.

ЗЫ. Бекап, как бы есть, но годичной давности. Хотел в новый год засесть, но не вышло... 

[Лия]

что ещё можно попробовать?

Обратиться в компании, которые восстанавливают данные

12 мая 2025, 20:25:34

Он много и грязно ругался, на контрольные суммы, отрицательные числа и прочее, выдал выхлоп на несколько экранов, но файлы так и не появились, свободного места также не прибавилось.

Хотя, если файловую систему так "размотало" , вряд ли удастся что-либо восстановить.

[IlyaLinux]

Хотя, если файловую систему так "размотало"

Грёбанные smr-диски! На этом разделе торренты крутились и виртуалки. Видимо, таблица файлов часто изменялась, а на smr-диске это, скорее всего, приводило к перезаписи целого блока, что в итоге таблицу файлов раздела и доканало. Ну кто разрешил на ноут с единственным винтом ставить это smr-го.но?! На прошлом ноуте диск 10 лет отработал и живее всех живых, ещё в системнике трудится, а тут...
Систему не размотало, данные на месте, это точно, весь остальной раздел бекапился без замедлений и хрустов. Но вот с "оглавлением у книжки" беда, вандалы оторвали. Зато суперблок уцелел... Давайте, пожалуйста, вместе подумаем как блоки данных сопоставить с заголовками (которых как-будто бы нет)?

[Лия]

Давайте, пожалуйста, вместе подумаем как блоки данных сопоставить с заголовками (которых как-будто бы нет)?

https://wiki.archlinux.org/title/File_recovery

[dr_faust]

Т.е. надо восстановить файлы?

r-studio. Замечательная вещь. Пользовался версией под винду, но вроде есть и под линь. Правда хз есть ли крякнутая. В остальном восстанавливает замечательно. Умеет работать с образами, сделанными dd.

Линуксовый testdisk  не рекомендую. Лет 5 надаз пробовал. Не понравился.

[IlyaLinux]

https://wiki.archlinux.org/title/File_recovery

Последний совет помог подтвердить, что данные на месте, нашёл питонячую тетрадку с уникальной текстовой последовательностью:

Код Выделить Развернуть

sudo pv /dev/sda10 | grep -a -C 200 -F 'some_text' > /dev/shm/OutputFile

Т.е. надо восстановить файлы?

Лучше не файлы восстановить, а как-то с таблицей inode поработать, т.к. нужны все файлы с диска, а не конкретные несколько. Если в итоге получим миллион файлов проименованных инкрементом, толку с того будет не много. Помру их разгребая..


12 мая 2025, 22:54:45
Только суперблок продублирован?

А если в каждую йноду потыкать на предмет, что она директория и попытаться прочитать содержимое?

[Лия]

Код Выделить Развернуть

sudo tune2fs -l /dev/sda10
что пишет?

[IlyaLinux]

sudo tune2fs -l /dev/sda10

Код Выделить Развернуть

$ sudo tune2fs -l /dev/sda10
tune2fs 1.46.2 (28-Feb-2021)
Filesystem volume name:   granary
Last mounted on:          /media/ilya/granary
Filesystem UUID:          4e44fafb-48d8-41e9-8d7c-593b7686e249
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean with errors
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              48865280
Block count:              195429888
Reserved block count:     0
Overhead clusters:        3346604
Free blocks:              2275556
Free inodes:              48837418
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      977
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Thu May 19 18:11:52 2022
Last mount time:          Sat May 10 08:38:13 2025
Last write time:          Mon May 12 18:51:57 2025
Mount count:              3
Maximum mount count:      -1
Last checked:             Thu May  1 17:41:55 2025
Check interval:           0 (<none>)
Lifetime writes:          3407 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      bb307d31-d235-41d6-bd70-161f52397469
Journal backup:           inode blocks
FS Error count:           125
First error time:         Sat May 10 08:37:02 2025
First error function:     __ext4_find_entry
First error line #:       1595
First error inode #:      2
First error err:          EFSBADCRC
Last error time:          Sat May 10 08:38:15 2025
Last error function:      htree_dirblock_to_tree
Last error line #:        1045
Last error inode #:       2
Last error err:           EFSBADCRC
Checksum type:            crc32c
Checksum:                 0x6297a2c9
Размер свободного места на разделе показывает правильно, т.е. кол-во пустых йнод, вроде как, корректное, не испортилось, что намекает, что и остальная информация в йнодах может быть верной, но контрольные суммы часто не совпадают.


13 мая 2025, 10:38:22

Код Выделить Развернуть

Lifetime writes:          3407 GB
занижена, это с 2022 года, когда раздел претерпел разукрупнение. Винт с 2018 трудился примерно с одинаковой нагрузкой.

13 мая 2025, 11:37:59
Попробовал скопировать первые 100МБ с разным размером блока: 64K, 4K, в надежде, что медленней как-то иначе прочитает. увы sha256 одинаковый. Все 100МБ копировал медленно, с хрустом.

[IlyaLinux]

Просканировал раздел в поисках наименования конкретной директории, которая я знаю, что точно находится на диске, т.к. эту аудиокнигу недавно слушал. Она с длинным именем.

Код Выделить Развернуть

sudo pv /dev/sda10 | grep -a -C 200 -F 'long dir name' > /dev/shm/granary_string.txtИ нашлось сразу 8! участков на диске, где это наименование встретилось. Рядом с наименованием аудиокниги, наименования других директорий, которые находились вместе с ней. Подумал в начале, что это так разбита длинная директория на несколько блоков, но некоторые наименования встретились по нескольку раз. Да и сама аудиокнига повторилась 8 раз. Что это может быть такое?
И ещё вопрос, можно ли как-то зная где физически размещены данные на диске вычислить номер блока данных, чтобы через него на йноду выйти?

15 мая 2025, 14:36:32
Проделаю тоже самое на бекапе, годичной давности, посмотрим как там покажет. Плюс, у бекапа йноды целые можно будет потестировать гипотезы.

15 мая 2025, 19:47:38
В бекапе наименование аудиокниги повторилось 3 раза. У иноды родительского каталога 6 блоков:

Код Выделить Развернуть

debugfs:  blocks <22020097>
88096521 88088608 88088912 88088913 88088964 88088967
, однако если вывести содержимое этих блоков наименование аудиокниги встретится только 1 раз:

Код Выделить Развернуть

printf '%s\n' 88096521 88088608 88088912 88088913 88088964 88088967 | xargs -i sudo dd if=/dev/loop0 status=none bs=4k count=1 skip={} > blocks.ddТогда вопрос, почему физически на разделе наименование встретилось трижды?. Думаю как поискать ещё раз, только дополнить поиск информацией о номере блоке. Через dd в цикле плохое решение, медленно, не дождёмся..

[ihammers]

ИМХО: лучше использовать GNU ddrescue, а не dd для снятия дампа. Данная программа позволяет как прямой проход, так и обратный. А также mapfile/logfile, в котором содержится информация по блокам, которые у программы не получилась обработать.

PS: все работы с debugfs, осуществляйте на копии дамп-файла.

[IlyaLinux]

PS: все работы с debugfs, осуществляйте на копии дамп-файла.

Местов столько нет, жираф большой. ) Подмонтировал годовалый бекап в режиме ro, или есть вероятность испортить? Тогда ещё один диск заказывать.

16 мая 2025, 10:57:27
Сокрушаюсь от мысли, что ext4 настолько уязвима. Вышли из строя лишь несколько секторов, капля в море. Но не обычных, а с инодами. Но именно в этом месте и происходит наибольшее кол-во перезаписей! Это самая динамичная часть раздела. Такая ситуация и для обычного hdd не хороша, а для черепичного вообще смерть. И разработчики совсем её не предусмотрели. Суперблок несколько раз продублировали, а таблицу инод нет. Плюс она фиксирована на одном месте, а не "плавающая" по разделу. Мало того, не до конца понятно как провести обратную операцию, от блоков на диске перейти к файлам и директориям, пока не нашёл инструментов.
Получается, необходимо самостоятельно организовывать резервное копирование при загрузке заголовков каждого раздела ext4 с инодами и битовыми картами, накрыться медным тазом может совершенно в любой момент, непредсказуемо. Просто несколько секторов!