LINUX.ORG.RU

После проверки диска e2fsck пропали каталоги с файлами

 ,


1

2

Всем привет.

Внешний USB-диск, подключенный к роутеру, подвешивал его в процессе записи торрентов. Решил проверить его на ошибки, в консоли запустил «e2fsck -f -y», в результате корневой каталог, в котором было более 2тб файлов в подкаталогах, стал пустым. В lost+found нашлось 2 из них, но большей части нигде не вижу. При этом объем занятого места на диске не изменилось. Файловая система ext4.

Вот часть логов:

.... Pass 2: Checking directory structure Invalid inode number for '.' in directory inode 417793. Fix<y>? yes Invalid inode number for '.' in directory inode 417794. Fix<y>? yes Entry 'Archive' in /shared (2514945) is a link to directory /???/Archive (2514946). Clear<y>? yes Entry 'Photo' in /shared (2514945) is a link to directory /???/Photo (2719761). Clear<y>? yes .... Unconnected directory inode 417794 (/shared/???) Connect to /lost+found<y>? yes .... Unattached inode 417795 Connect to /lost+found<y>? yes .... Directories count wrong for group #3264 (12, counted=13). Fix<y>? yes Main: ***** FILE SYSTEM WAS MODIFIED *****

Можно ли как-то все вернуть? Помогите пожалуйста

Конечно. Скачай заново.

anonymous ()

вы конечно может прогнать утилитами photorec, но мало вероятно. Скорее всего данные не успели синхронизироваться,а вы выдернули диск. Наличие данных в менеджере каталогов еще не значит что они записались на сам диск, сначала они ложатся в кеш, причем объем в кеше может быть очень большой. Кроме того файловая система была повреждена, возможно некорректными завершениями работы - и потому, что там на самом деле записалось - неизвестно.

Silerus ★★★ ()
Ответ на: комментарий от Silerus

Дело не в тех данных/торрентах, на которых произошло подвисание. Это уже было ранее, информация не пропадала никуда. И после этого подвисания также все осталось на месте, но грешным делом показалось, что причина в ошибках на диске и решил его проверить. Диск отмонтировал предварительно, ничего не выдергивал на горячую, и выполнил e2fsck будь он неладен... И теперь там пусто. Но где-то же они есть, ведь диск заполнен также как и был, их просто не видно почему-то.

dabustard ()
Ответ на: комментарий от dabustard

подвисание диска говорит что с ним были проблемы. попробывать востановить данные и разделы можно утилитами photorec

Silerus ★★★ ()
Ответ на: комментарий от dabustard

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

dabustard ()
Ответ на: комментарий от Silerus

Причина пропажи каталогов, если я правильно понял в том, что e2fsck сделал это:

Entry 'Photo' in /shared (2514945) is a link to directory /???/Photo (2719761). Clear<y>? yes

Наверняка можно как-то восстановить? ведь ничем поверх затерто не было...

dabustard ()
Ответ на: комментарий от dabustard

прогони testdisk - по диску, только сохраняй результат в другом месте и все станет ясно. Fsck - битые данные и осводил их. кстати стоит заглянуть в .lost-founds

Silerus ★★★ ()
Ответ на: комментарий от dabustard

виндовая r-studio - незнаю как у нее с ext4 - но востанавливает и имена и структуру - искать гдето на торонтах - пропритарная вещь

Silerus ★★★ ()

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

В одно место ты сделаешь образ ddrescue со своего битого и поврежденного диска, в другое место будешь восстанавливать данных с этого образа с помощью photorec или R-Studio. Образ ddrescue нужен, что бы не усугубить ситуацию с битой фс и умирающим диском. И что бы была возможность попробовать восстановить снова и снова разными способами.

Deleted ()
Ответ на: комментарий от Silerus

Testdisk в итоге отобразил список разделов не подлежащих восстановлению.

Нашел в нем еще в Advansed>Filesystem>Superblock такое: ==== Disk /dev/sdb - 3000 GB / 2794 GiB - CHS 364797 255 63

Partition Start End Size in sectors

MS Data 264192 5860466647 5860202456 [Basic data partition] superblock 0, blocksize=4096 [Main] superblock 32768, blocksize=4096 [Main] superblock 98304, blocksize=4096 [Main] superblock 163840, blocksize=4096 [Main] superblock 229376, blocksize=4096 [Main] superblock 294912, blocksize=4096 [Main] superblock 819200, blocksize=4096 [Main] superblock 884736, blocksize=4096 [Main] superblock 1605632, blocksize=4096 [Main] superblock 2654208, blocksize=4096 [Main]

To repair the filesystem using alternate superblock, run fsck.ext4 -p -b superblock -B blocksize device =============================================

Это не то, что мне надо?

dabustard ()
Ответ на: комментарий от Deleted

Спасибо за совет. Понимаю, что так правильно, но 6 Тб свободного места сходу так и не найдешь... Единственное не понимаю, почему так произошло. С ntfs за 15 лет с таким не сталкивался. Подцепил к роутеру диск, посоветовали использовать ext-фс, после первой проверки на ошибки пропало 90% данных... Плачу.

dabustard ()
Ответ на: комментарий от dabustard

Причем я уверен, что диск исправен, ошибка чисто программная. И ничего нельзя сделать, кроме как побайтово вытаскивать данные.

dabustard ()
Ответ на: комментарий от dabustard

Единственное не понимаю, почему так произошло.

Подцепил к роутеру диск

Вот поэтому.

Плачу

Зато научишься делать резервные копии.

С ntfs за 15 лет с таким не сталкивался.

На подключённом 24/7 к роутеру через USB диске?

anonymous ()
Ответ на: комментарий от dabustard

Причем я уверен, что диск исправен, ошибка чисто программная

Ололо, «уверен» он. Ext4, конечно, днище по всем параметрам, но вот просто так потерять все файлы без проблем с железом (вроде отключений USB из-за слабого питания) она врд ли может.

anonymous ()
Ответ на: комментарий от dabustard

так ты прямо с роутера делал fsck?

К сожалению, если есть дырка на роутере, это не значит, что оно будет работать. У меня, например, на tplink не удалось стабильно заставить работать usb диск. Там были проблемы с битой памятью роутера и просадками по питанию. По идее, обе причины были вылечены (изменены частоты памяти и установлен usb-хаб c гарантированно внешним питанием (это тоже проблема найти такой) ), но нестабильная работа диска с роутером продолжала наблюдаться, хоть и в меньших количествах. Усугублялось всё это периодическим втыкиванием LTE-модема. Явно траблы с железом. Варианта это застаивть работать с ntfs и виндой не было совершенно, как ты понимаешь :)

Я рекомендую synology или qnap 2х или 4х дисковый для NAS. И роутер ничем не перегружать, пусть себе вайфай раздает.

Deleted ()
Ответ на: комментарий от anonymous

Я еще раз повторю, для «особо одаренных», что файлы пропали после проверки утилитой e2fsck. До проверки они были на месте и с чтением/записью никогда не было проблем. Да, и диск хоть и подключен к роутеру через USB, но имеет свое питание и 99% времени находился в режиме ожидания. Роутер тоже не абы-какой, а Asus RT-N56U, с нормальным «железом».

dabustard ()
Ответ на: комментарий от Deleted

Тем не менее, в моем случае все работало и работало стабильно и работало бы еще столько же, если бы не сделал эту проверку диска.

Прямо с роутера делал проверку, через telnet. В логе сообщений о нехватке ресурсов не было.

dabustard ()
Ответ на: комментарий от bormant

Спасибо, bormant

Установил extundelete, смотрю в мануале есть команда восстановления каталогов: --- sudo extundelete /dev/sdXY --restore-directory /путь_к_директории/DIRECTORY --- Подскажите, пожалуйста, как правильно указать параметры: -проблемный хард /dev/sdb2 -каталог «Photo», который хочу восстановить находился в корне раздела «Main» в каталоге «shared»

dabustard ()
Ответ на: комментарий от dabustard

для «особо одаренных»

Для себя? Ну повтори :)

файлы пропали после проверки утилитой e2fsck

А ФС была дохлой до.

До проверки они были на месте и с чтением/записью никогда не было проблем.

Еженедельный scrub всех холодных данных? Не верю.

Роутер тоже не абы-какой
Asus RT-N56U

Ой всё.

с нормальным «железом»

Говорят, у них плохой USB. Не знаю, правда, относится это к питанию или ещё что.

anonymous ()
Ответ на: комментарий от dabustard

Не совсем понял вопрос, поэтому пара примеров:
/dev/sdb2 корень, путь был /usr/shared/Photo, соответственно:
extundelete /dev/sdb2 --restore-directory /usr/shared/Photo

Или он же был смонтирован отдельным /usr:
extundelete /dev/sdb2 --restore-directory /shared/Photo
т.к. путь внутри ФС на разделе не содержит саму точку монтирования /usr.

bormant ★★★★★ ()
Ответ на: комментарий от dabustard

выполнил

mint@mint /media/mint/C28E4B4B8E4B3767 $ sudo extundelete /dev/sdb2 --restore-directory shared/Photo WARNING: Extended attributes are not restored. Loading filesystem metadata ... 22355 groups loaded. Loading journal descriptors ... 29541 descriptors loaded. Failed to restore file shared/Photo Could not find correct inode number past inode 2514945. mint@mint /media/mint/C28E4B4B8E4B3767 $

Правильная команда? Что означает такой ответ? У меня в логе проверки ошибок сохранились inode номера пропавших каталогов. Может это как-то помочь?

dabustard ()
Ответ на: комментарий от anonymous

выполнил команду:

sudo extundelete /dev/sdb2 --inode 608384

где 608384 - inode пропавшего каталога «Photo» и в ответе увидел все его соержимое с файлами и подкаталогами!

Значил он есть, а вот как его восстановить. Если я правильно понимаю, то inode, это своего рода «ссылка» на каталог и если ссылка некорректная каталога не видно. Как теперь восстановить это дело, у меня есть все inod'ы пропавших каталогов.

dabustard ()
Ответ на: комментарий от dabustard

Как теперь восстановить это дело

Руками точно так же. Если это работает рекурсивно, то все каталоги верхнего уровня по очереди. Если нужно каждый отдельно, то идёшь в гугл: https://www.google.ru/search?q=sh read while Скопировать всё важное, создать новую ФС.

anonymous ()
Ответ на: комментарий от anonymous

Задам вопрос конкретнее, какой командой я могу привязать «потерянный» inode к существующему каталогу shared, чтобы он и его содержимое там отобразились.

e2fsck сделал при проверке Clear:

Entry 'Photo' in /shared (2514945) is a link to directory /???/Photo(608384). Clear<y>? yes

Теперь нужно заново привязать, вопрос - как?

dabustard ()
Ответ на: комментарий от dabustard

тот же e2fsck сделал для некоторых каталогов:

Unconnected directory inode 417794 (/shared/???) Connect to /lost+found<y>? yes

почему не сделал для остальных - вопрос... Как теперь сделать это вручную?

dabustard ()
Ответ на: комментарий от anonymous

в lost+found искал в первую очередь, там как и говорил ранее нашлось 2 каталога из примерно 10-ти

нашел такое решение и промоделировал на другом диске - работает:

sudo debugfs -w /dev/sdc1 debugfs: unlink shared/test debugfs: quit

в результате каталог test пропал из shared (inode # 21), потом сделал обратную операцию :

sudo debugfs -w /dev/sdc1 debugfs: link <21> shared/test debugfs: quit

Каталог вернулся на свое место. Теперь хочу таким же образом привязать потерянные inode на проблемном диске, что думаете?

dabustard ()
Ответ на: комментарий от dabustard

почему не работает перенос строк на этом форуме, извиняюсь за кашу в командах..

[code] ... [/code]

anonymous ()

Проблема решена!

Может обратился не совсем по адресу, но удивлен, что ее достаточно простое решение неизвестно местным гуру. В итоге оно было найдено самостоятельно, полным нубом в линуксе. Также хочу поблагодарить всех откликнувшихся, в особенности bormant, благодаря которому была загуглена статья с заветными строками.

Распишу здесь, что делал, надеюсь кому-то поможет.

Итак , если у вас в результате проверки диска пропали каталоги и файлы, в lost+found не объявились и при этом занятое место на диске не изменилось, все можно очень просто восстановить.

1) Первое, что нужно сделать это сохранить лог работы утилиты проверки диска e2fsck / fsck, в котором можно найти подобные строки (как пример, у вас будут другие):

Entry 'Photo' in /shared (2514945) is a link to directory /???/Photo (2719761). Clear<y>? yes

В этой строке видим 2 каталога "shared" и "Photo" и в скобках указан некий inode этих каталогов: их надо сохранить, они понадобятся в процессе восстановления (допускаю, что inode потерянных каталогов можно узнать другим способом, но я до этого не дошел)

2) Далее скачиваем LiveCD с linux (я использовал Linux Mint Tools LiveCD) и записываем образ на флешку. Загружаемся с нее. Там понадобится 2 вещи - "Диски" (для монтирования/размонтирования устройств) и "Эмулятор терминала" (в нем нужно будет вводить все команды для восстановления)

3) Подключаем проблемный диск и в «Дисках» смотрим смонтирован ли он, если да - то обязательно размонтировать (там есть кнопка play/stop) и там же посмотреть куда он смонтировался (/dev/sdXY, вместо XУ будет комбинация буквы и числа)

4) В терминале вводим команду :

$ sudo debugfs -w /dev/sdXY

5) В открывшемся приглашении debugfs: вводим ключевую команду, которая и привяжет потерянный каталог любого имеющегося на устройстве:

link <номер_inode> каталог_назначения/имя_восстанавливаемого_каталога

Номер_inode берем из лога работы который ранее сохранили (<> также надо указывать), каталог_назначения - любой имеющийся на диске каталог, имя также можно вводить любое (в нем появится содержимое нашего потерянного)

Повторяем для все потерянных каталогов.

После чего вводим команду quit, тем самым выходим из debugfs. ВСЕ!

Желательно делать все эти операции не напрямую на проблемном диске, а на его образе, как здесь советовали, однако как сделать образ и как с ним работать не подскажу. У меня, к сожалению не было лишних 3 Tб под рукой.

Ссылка на статью, где нашел нужную команду - https://www.opennet.ru/docs/HOWTO-RU/mini/Ext2fs-Undeletion-Dir-Struct.html

dabustard ()
Ответ на: комментарий от dabustard

Может обратился не совсем по адресу, но удивлен, что ее достаточно простое решение неизвестно местным гуру.

Гуру делают бэкапы, а остальные здешние... Ну ты понел.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.