(РЕШЕНО) Сломался BTRFS

Shama_comp
И что каждый файл вытаскивать?
Грубо можно разделить проблему на две ситуации
1) Система хоть и не рабочая, но раздел определяется и данные (файлы) на разделе видны, например, из другой системы или Live CD. В данной ситуации нет проблемы с извлечением файлов и как правило стоит задача реанимировать систему. Плюс к этому важная инфа всегда бэкапится.
2) Система не рабочая и раздел не определяется, а в большинстве случаев это просто образ такой системы или же ее частей. В данной ситуации не стоит задача реанимации системы, а стоит задача вытащить конкретные данные, то есть отдельные файлы, содержащие важную информацию. То есть на первом месте стоит ИНФОРМАЦИЯ, заключенная в отдельных файлах. И в наилучшем случае имена этих файлов, их приблизительное сдержание и формат известны. И чем меньше информации о данных файлах мы имеем, тем труднее их извлечение.

Лично меня интересует 2-ая ситуация. Зачем, не спрашивай ... И на btrfs смотрю именно с этой точки зрения, захотел посмотреть запасной вариант с использованием inspect-internal dump-tree - всегда должно быть что то в запасе, на всякий пожарный.
Повторюсь - самый надежный способ это поиск по сигнатуре. Но бывают ситуации когда файлов с такой сигнатурой море и найти нужный проблематично - вот тут то и не плохо иметь дополнительную информацию о приблизительном расположении файла в системе, его имени и размере.

PS 1 - у nafanja стоит задача, насколько я понял, спасти систему. Думаю файлы с нужной информацией у него продублированы в другом месте и его это особо не беспокоит.

PS 2 - ну а если нужно вытащить много файлов, то для этого есть специальные утилиты, не зависящие от типа файловой структуры, работающие с raw date - foremost и scalpel, правда они не все сигнатуры понимают, им нужно это объяснять.
Ошибки не исчезают с опытом - они просто умнеют
vasek
PS 1 - у nafanja стоит задача, насколько я понял, спасти систему. Думаю файлы с нужной информацией у него продублированы в другом месте и его это особо не беспокоит.
А я думал наоборот восстановить данные. С моей точки зрения на систему-то п*срать ведь ее легко можно переустановить исключение составляют конфиги, которые заточены "под себя", а ну а дефолтные не важно они есть и все работает без настройки и редактирования.
Shama_comp
С моей точки зрения на систему-то п*срать ведь ее легко можно переустановить исключение составляют конфиги, которые заточены "под себя", а ну а дефолтные не важно они есть и все работает без настройки и редактирования.
Согласен, думаю большинство так и делает, плюс к этому и бэкапит нужные документы, хранящиеся в /home.
Но всегда интересно поработать над восстановлением системы, у большинства системы стоят много, много лет.
Ошибки не исчезают с опытом - они просто умнеют
vasek
Но всегда интересно поработать над восстановлением системы, у большинства системы стоят много, много лет.
Согласен да интересно разобраться в чем проблема. За одно не малый опыт приобрести по восстановлению данных на экзотической ФС. Ведь по-моему мнению это единственное нас отличает от "форточников", которые себя не утруждают и тянутся к загрузочной флешке\болванки для переустановки ОСи, конечно, не все так делают, но большинство. Даже не знаю, чтобы я делал в такой ситуации,наверное, тоже потянулся к загрузочной флешке с Арчем. Плохая,конечно, манера, но она у сохранилась как не печально было бы мне.
и так, итоги.
команда которая привела к тому что раздел можно было примонтировать раздел в режиме RO:
mint@mint:~$ sudo btrfs check –repair –init-extent-tree /dev/sda3
enabling repair mode
Checking filesystem on /dev/sda3
UUID: 4432f74b-a439-48cc-96e6-226c7902d714
Creating a new extent tree
Failed to find [487869906944, 168, 16384]
btrfs unable to find ref byte nr 487869906944 parent 0 root 1  owner 1 offset 0
Failed to find [487870529536, 168, 16384]
btrfs unable to find ref byte nr 487870660608 parent 0 root 1  owner 0 offset 1
Failed to find [487870562304, 168, 16384]
btrfs unable to find ref byte nr 487994556416 parent 0 root 1  owner 0 offset 1
checking extents
ref mismatch on [451362684928 4096] extent item 0, found 8
data backref 451362684928 parent 580500160512 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 580500160512 owner 0 offset 0 found 1 wanted 0 back 0x5ff983c0
data backref 451362684928 parent 580158013440 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 580158013440 owner 0 offset 0 found 1 wanted 0 back 0x13bc2080
data backref 451362684928 parent 580451762176 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 580451762176 owner 0 offset 0 found 1 wanted 0 back 0x5e0d3250
data backref 451362684928 parent 513070186496 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 513070186496 owner 0 offset 0 found 1 wanted 0 back 0x13e21dd0
data backref 451362684928 parent 488814985216 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 488814985216 owner 0 offset 0 found 1 wanted 0 back 0x857ac10
data backref 451362684928 parent 579627270144 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 579627270144 owner 0 offset 0 found 1 wanted 0 back 0x84f97a0
data backref 451362684928 root 471 owner 7010715 offset 589824 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 root 471 owner 7010715 offset 589824 found 1 wanted 0 back 0x57f5d280
data backref 451362684928 parent 488756936704 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362684928 parent 488756936704 owner 0 offset 0 found 1 wanted 0 back 0xd65d320
backpointer mismatch on [451362684928 4096]
adding new data backref on 451362684928 parent 580500160512 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 580158013440 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 580451762176 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 513070186496 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 488814985216 owner 0 offset 0 found 1
adding new data backref on 451362684928 parent 579627270144 owner 0 offset 0 found 1
adding new data backref on 451362684928 root 471 owner 7010715 offset 589824 found 1
adding new data backref on 451362684928 parent 488756936704 owner 0 offset 0 found 1
Repaired extent references for 451362684928
ref mismatch on [451362689024 4096] extent item 0, found 1
data backref 451362689024 parent 513244233728 owner 0 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 451362689024 parent 513244233728 owner 0 offset 0 found 1 wanted 0 back 0x2bb1880
backpointer mismatch on [451362689024 4096]
adding new data backref on 451362689024 parent 513244233728 owner 0 offset 0 found 1
Repaired extent references for 451362689024
ref mismatch on [451362693120 28672] extent item 0, found 1
data backref 451362693120 root 725 owner 1293192 offset 1048576 num_refs 0 not found in extent tree
incorrect local backref count on 451362693120 root 725 owner 1293192 offset 1048576 found 1 wanted 0 back 0x2722ca20
backpointer mismatch on [451362693120 28672]
adding new data backref on 451362693120 root 725 owner 1293192 offset 1048576 found 1
....
до окончания я так и не дождался, макс что было это 12 часов (и это на ssd размер ~100Г), но хватило бы, для того же результата, и 15 минут.
после выполнения команды я все же сумел подключить раздел только для чтения и вытащить нужные данные, но не все...
для под тома @kubuntu_root не было ниодного снимка (я до поломки подчищал, что бы выделить место) и на верное по этому я не смог полностью вытащить все данные с него, где то была ошибка чтения записи.
под тома @archlinux_boot @kubuntu_boot @archlinux_root были скопированны без ошибок.
под том @home_all был тоже поврежден, но для него были снимки, поэтому удалось вытащить данные только с задержкой 1 час назад (снимки home делались каждый час).

выводы:
btrfs в принципе это хорошо для экономии места: сжатие, псевдоразделы совместно использующие все доступное свободное пространство, снимки как история изменений, штатные средства для настоящих и даже инкрементных бэкапов, а не просто снимки.
так и плохо, потому что это все же одна фс, если испортится, то потянет и псевдоразделы (под тома)...

я могу рекомендовать btrfs тем, у кого много свободного места для снимков, но все же настоящий бэкап на другом диске никогда не помешает!!!
Псевдографический инсталлятор Arch Linux ver. 3.8.2
Благодарности принимаются на ЯД 410012815723874
Как восстановить каталог с повреждённого btrfs раздела? (поднимаю продолжение темы)
Предыстория: поставил CentOS 7, результат: btrfs раздел оказался удалён.
Где был первый сектор btrfs-раздела, не знаю. Вывод gdisk:
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Total free space is 169312222 sectors (80.7 GiB)

№  Start (sector) End (sector)  Size      Code  Name
1            2048       786431   383.0 MiB  EF00 EFI System Partition
3       170096640   1886412799   818.4 GiB  NTFS  исправный раздел
4      1886412800   1953525134   32.0 GiB   сюда поставил CentOS 7
под № 2 примерно с 786432 сектора был btrfs-раздел на 80 GB
Далее я поломал таблицу файлов: в gparted под Arch-Linux создал на этом свободном месте btrfs-раздел, и gparted пересоздал btrfs структуру.
Как исправить мою ошибку? Дамп в testdisk я сделал лишь после того, как gparted всё затёр, создав btrfs заново.

Пробовал искать суперблок: sudo btrfs inspect-internal dump-super -a /dev/sdb2
superblock: bytenr=65536, device=/dev/sdb2
ERROR: bad magic on superblock on /dev/sdb2 at 65536
superblock: bytenr=67108864, device=/dev/sdb2
ERROR: bad magic on superblock on /dev/sdb2 at 67108864

Текущий вывод gdisk, неизвестно настоящее начало btrfs-раздела:
Disk /dev/sdb: 1953525168 sectors, 931.5 GiB
Sector size (logical/physical): 512/4096 bytes
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          786431   383.0 MiB   EF00  EFI System Partition
   2          786432       170096639   80.7 GiB    8300  Linux filesystem
   3       170096640      1886412799   818.4 GiB   0700  Basic data partition
   4      1886412800      1953525134   32.0 GiB    0700  Basic data partition
Мне нужно вытащить каталог с фотками, их было десятки тысяч!
btrfs-раздел был со включенным сжатием, без подтомов, снимки файловой системы я не делал.
Dobrov
Мне нужно вытащить каталог с фотками, их было десятки тысяч!
btrfs - неплохая система, но нет софта для восстановления удаленных разделов и не все хорошо обстоит с восстановлением файлов.
Так как файлов (фоток) очень и очень много, то вижу один путь для их восстановления - утилиты foremost и scalpel (одинакового типа, но scalpel из AUR и более шустрая - хотя все это относительно) - работают не с файловой системой, а с raw date и файлы находятся по их сигнатуре. Удобнее для начала задать один тип файлов и прошерстить раздел/диск, если все найдется, то можно дальше задать уже и несколько типов, но, имхо, лучше так и искать по отдельности.
В инете много примеров их использования.

EDIT 1 - плохо то, что
Dobrov
Предыстория: поставил CentOS 7, результат: btrfs раздел оказался удалён.
Многие файлы могут быть затерты. Можно для интереса (да и набора информации) попробовать востановить ручками любое фото (как, описывал в одном из блогов).
Вот если бы не btrfs .... можно было бы пробовать восстановить раздел, используя дисковый редактор ...
Ошибки не исчезают с опытом - они просто умнеют
vasek
Вот если бы не btrfs …. можно было бы пробовать восстановить раздел, используя дисковый редактор …
А есть возможность найти в btrfs цепочки каталогов? Фото были сгруппированы и имена каталогов были важны.
dmde, testdisk и scalpel находят файлы, но это сортировать всё это слишком долго…
Dobrov
А есть возможность найти в btrfs цепочки каталогов? Фото были сгруппированы и имена каталогов были важны.
Я btrfs практически не знаю, но утилиты восстанавливают, как правило файлы, а не директории - любая директория в файловой системе это тот же файл, размером обычно 4096 байт (1 страница), но inode директории имеет таблицу всех inode входящих в эту директорию (дерево). При удалении файла, удаляется не содержимое файла а его информация об inode (нет inode, нет файла). Удалили директорию, но не удалили файлы, входящие в эту директорию, а удалили информацию об inode. То есть нужно восстанавливать файлы, а не директории.
Писал по памяти, почти не думая, так что возможны и не точности. Строго прошу не судить.
Ошибки не исчезают с опытом - они просто умнеют
Dobrov
dmde …. находят файлы,
Забыл спросить, давно не работал с DMDE - вроде бы DMDE не поддерживает btrfs?
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.