Lost and found linux

/lost+found/ восстановить данные.

На сервере в каталоге /var/www/ был расположен сайт. После перезагрузки сервера, в результате каких то работ в датацентре, каталог www полностью пропал. Файлы, находившиеся в этом каталоге, успешно ищутся в каталоге /lost+found/.

Можно ли их как нибудь восстановить? (физического доступа к серверу нет, но ос функционирует, вроде как, без особых проблем.)

Файловая система ext3

Да. Восстановить из бэкапа, сделанного днём ранее до сбоя.

>>> Да. Восстановить из бэкапа, сделанного днём ранее до сбоя.

Свой бэкап недельной давности. У датацентра бэкапы отсутствуют. Хотелось бы вытащить информацию из /lost+found/.

Сколько там файлов/каталогов?

Порядка 150 каталогов и 40 тысяч файлов.

Ну я даже не знаю. Я бы наверное попробовал скриптом отыскать все каталоги внутри lost+found, вывести их содержимое ls’ом в файл и сидел сравнивал с бэкапом и распихивал вручную.

Или всё совсем в рассыпную?

Не знаю, поможет ли тут софт класса testdisk.

Разбросано конечно сильно. Но думаю справлюсь. Осталось чуть разобраться.
После выводом ls получил вот такой файл

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

Не, ну ты точно никогда не видел состояние традиционной Unix-like ФС после аварийного восстановления?

Не знаю, поможет ли тут софт класса testdisk.

testdisk работает на другом уровне.

Хорошо. Придется перемещать вручную. Смущает лишь то что в одном файле находятся несколько файлов. Мне б краткую консультацию по тому как вручную разгрести.

Здесь) человек вернул на место только корневую папку и все стало хорошо. Есть ли шанс на подобную историю успеха?

Ну вот взял и спалил. Как я теперь пацанам в глаза из 95-ой венды смотреть буду-то? 😀

>>Не, ну ты точно никогда не видел состояние традиционной Unix-like ФС после аварийного восстановления?

Да, не видел. Не доводилось крашить ФС или доходить до такого, чтоб не было актуального бэкапа.

>>testdisk работает на другом уровне.

Ну потому и сказал что не уверен.

файлы — можно. имена, скорее всего, нет.

>Смущает лишь то что в одном файле находятся несколько файлов.

В смысле файлы объеденились?

Наверное, лучше всего скопировать все эти файл из lost+found, потом взять резервную копию недельной давности (хоть что-то) и найти одинаковые файлы. А оставшиеся уже вручную. Или может есть тулза, ищущая не сильно различающиеся файлы.

Источник

Lost and found linux

As was explained earlier during the overview of the FSSTND, Linux should always go through a proper shutdown. Sometimes your system might crash or a power failure might take the machine down. Either way, at the next boot, a lengthy filesystem check (the speed of this check is dependent on the type of filesystem that you actually use. ie. ext3 is faster than ext2 because it is a journalled filesystem) using fsck will be done. Fsck will go through the system and try to recover any corrupt files that it finds. The result of this recovery operation will be placed in this directory. The files recovered are not likely to be complete or make much sense but there always is a chance that something worthwhile is recovered. Each partition has its own lost+found directory. If you find files in there, try to move them back to their original location. If you find something like a broken symbolic link to ‘file’, you have to reinstall the file/s from the corresponding RPM, since your file system got damaged so badly that the files were mutilated beyond recognition. Below is an example of a /lost+found directory. As you can see, the vast majority of files contained here are in actual fact sockets. As for the rest of the other files they were found to be damaged system files and personal files. These files were not able to be recovered.

total 368 -rw-r—r— 1 root root 110891 Oct 5 14:14 #388200 -rw-r—r— 1 root root 215 Oct 5 14:14 #388201 -rw-r—r— 1 root root 110303 Oct 6 23:09 #388813 -rw-r—r— 1 root root 141 Oct 6 23:09 #388814 -rw-r—r— 1 root root 110604 Oct 6 23:09 #388815a -rw-r—r— 1 root root 194 Oct 6 23:09 #388816 srwxr-xr-x 1 root root 0 Oct 6 13:00 #51430 srwxr-xr-x 1 root root 0 Oct 6 00:23 #51433 -rw——- 1 root root 63 Oct 6 00:23 #51434 srwxr-xr-x 1 root root 0 Oct 6 13:00 #51436 srwxrwxrwx 1 root root 0 Oct 6 00:23 #51437 srwx—— 1 root root 0 Oct 6 00:23 #51438 -rw——- 1 root root 63 Oct 6 13:00 #51439 srwxrwxrwx 1 root root 0 Oct 6 13:00 #51440 srwx—— 1 root root 0 Oct 6 13:00 #51442 -rw——- 1 root root 63 Oct 6 23:09 #51443 srwx—— 1 root root 0 Oct 6 10:40 #51445 srwxrwxrwx 1 root root 0 Oct 6 23:09 #51446 srwx—— 1 root root 0 Oct 6 23:09 #51448

Источник

а для чего постоянно создается папка lost+found?

собственно сабж, постоянно наблюдаю в ней какие-то файлы с нечитаемым содержимым (да, когда форматировал винт под reiserfs, такого не было)

Re: а для чего постоянно создается папка lost+found?

1. Нет такого слова «папка».

2. В каталог lost+found складывается то, что обнаружила fsck при проверке раздела.

Re: а для чего постоянно создается папка lost+found?

>1. Нет такого слова «папка».

Как это слова нет? Мамка есть, а папки нет?

Re: а для чего постоянно создается папка lost+found?

не понял, а что такое можно обнаружить при проверке, что надо складывать куда-то? разве ошибки не исправляются автоматически?

Re: а для чего постоянно создается папка lost+found?

файлы без названий 😉

Re: а для чего постоянно создается папка lost+found?

В lost+found скидываются файлы, на которых не было ссылок ни в одном каталоге, хотя их иноды не были помечены как свободные.

Re: а для чего постоянно создается папка lost+found?

в винде никогда не находил lost chains? И файлы chk0001.chk? Вот тут то же самое.

Re: а для чего постоянно создается папка lost+found?

возможно, так твой винт готовится отойти в мир иной и пытается предупредить хозяина. Это особый язык, но рано или поздно его осваивают. Лучше рано, чем поздно 🙂

Re: а для чего постоянно создается папка lost+found?

Re: а для чего постоянно создается папка lost+found?

а как такое может получиться? и почему с reiserfs такого ни разу не было?

Re: а для чего постоянно создается папка lost+found?

Питание отрубается часто?

Re: а для чего постоянно создается папка lost+found?

Потому что reiserfsck потерянные файлы не умеет восстанавливать. Она в лучшем случае восстановит работоспособность фс.

Re: а для чего постоянно создается папка lost+found?

а отчего файлы теряются-то? где хваленая стабильность?

Re: а для чего постоянно создается папка lost+found?

Ну и что я должен ответить на твой вопрос, по-твоему? Я вроде ничего тут не хвалил. 🙂 Обращайся к тем, кто хвалил, наверное.

Re: а для чего постоянно создается папка lost+found?

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

Re: а для чего постоянно создается папка lost+found?

Re: а для чего постоянно создается папка lost+found?

🙂 Это ты пральна сказанул (:

Re: а для чего постоянно создается папка lost+found?

> а как такое может получиться? и почему с reiserfs такого ни разу не было?

Удаление файла в Unix-системах — это две операции:

1. Удаление ссылки из каталога;
2. Удаление инода.

Если выполнилась первая операция и произошёл сбой, например, выключилось питание, то в системе останется потерянный инод, который вроде как и указывает на корректный файл, но этот файл не содержится ни в одном каталоге. В нежурналируемых файловых системах (например, ext2), в которых нет средства определения такого сбоя, задача восстановления таких файлов ложится на fsck. Он находит иноды, на которые нет ссылок, и создаёт на них ссылки в lost+found. Предполагается, что после этого пользователь сможет просмотреть файлы и при необходимости переместить им куда надо, вернув нужные имена.

Такая же ситуация теоретически может произойти при создании нового файла, если инод уже создан, а ссылка в каталоге — нет.

В журналируемых файловых системах (а к ним относятся ext3 и ReiserFS) fsck просто просматривает журнал, видит, что операция на завершилась полностью, и откатывает её. Поэтому и потерянные иноды находятся там реже.

Re: а для чего постоянно создается папка lost+found?

reiserfs вообще как-то сильно по-другому устроена, там аналогии с ext2 не стоит применять. Хотя подробностей я не знаю. 🙂

Re: а для чего постоянно создается папка lost+found?

и кудаже мне надо перемещать файлы, набитые мусором? это наверное какие-то служебные? или их сразу удалять можно, раз они создаются при кривом удалении? у меня ext3

Re: а для чего постоянно создается папка lost+found?

ИМХО, файлы на ext2/ext3 теряются при выключении без отмонтирования диска при неработающем журнале, при сбоях железа (шлейф отошёл) и при поиске приключений на свою задницу.

У меня такие файлы в lost+found возникают при ошибках при ковырянии в настройках ФС и изменении размера разделов. Просматриваю в mc и конквероре (или в чём-нибудь ещё, что умеет угадывать формат по содержимому), определяю формат, открываю соответствующей программой, по результатам — переименовываю или удаляю. Ещё там часто оказываются обрывки логов (если попытка загрузиться в новой конфигурации закончилась ресетом).

Источник

Какова цель папки lost + found в Linux и Unix?

В корне Linux и операционных систем Unix есть папка под названием /lost+found/

Для чего это? В каких обстоятельствах я бы с ним взаимодействовал? Как я буду с ним взаимодействовать?

3 ответа

Если вы запустите fsck , команду проверки и восстановления файловой системы, он может найти данные фрагменты, на которые не ссылаются нигде в файловой системе. В частности, fsck может найти данные, которые выглядят как полный файл, но не имеют имени в системе — inode без соответствующего имени файла. Эти данные все еще используют свободное пространство, но оно недоступно никакими нормальными средствами.

Если вы скажете fsck для восстановления файловой системы, он вернет эти почти удаленные файлы обратно в файлы. Дело в том, что файл имел имя и местоположение один раз, но эта информация больше не доступна. Поэтому fsck откладывает файл в определенном каталоге, называемый lost+found (после потерянный и найденный ).

Файлы, которые появляются в lost+found , как правило, являются файлами, которые уже были отсоединены (т.е. их имя было стерто), но все же открыто каким-то процессом (так что данные еще не были удалены), когда система внезапно остановилась (паника ядра или отказ питания). Если это все, что произошло, эти файлы были запланированы для удаления в любом случае, вам не нужно заботиться о них.

Файлы также могут отображаться в lost+found , потому что файловая система находилась в несогласованном состоянии из-за ошибки программного или аппаратного обеспечения. Если это так, вы можете найти файлы, которые были потеряны, но восстановление системы удалось спасти. Файлы могут содержать или не содержать полезные данные, и даже если они могут быть неполными или устаревшими; все зависит от того, насколько плохим был ущерб файловой системы.

Во многих файловых системах каталог lost+found является немного особенным, потому что он предопределяет бит пространства для fsck для хранения там файлов. (Пространство не для данных файла, которое fsck оставляет на месте, это для записей в каталоге, которые fsck должен составлять.) Если вы случайно удалите lost+found , не создавайте его с помощью mkdir , используйте mklost+found , если он доступен.

Каталоги lost+found (а не Lost + Found) — это конструкция, используемая fsck , когда есть повреждение файловой системы (не аппаратное устройство, а fs). Файлы, которые обычно теряются из-за повреждения каталога, будут связаны в каталоге lost+found файловой системы по номеру inode. Некоторые из них могут быть потерянными каталогами или потерянными файлами или даже потерянными устройствами. Каждая файловая система должна иметь свой собственный каталог lost+found , но вы можете посмотреть на систему с только одной файловой системой. В общем, вы должны надеяться, что каталог пуст; но если есть коррупция, будьте благодарны, что во многих случаях файлы могут быть восстановлены после того, как fsck помещает их здесь.

В разделе «Иерархия файловых систем Linux», раздел /lost + found

Как было объяснено ранее в обзоре FSSTND, Linux должен всегда проходить надлежащее завершение работы. Иногда ваша система может произойти сбой или сбой питания может привести к отключению аппарата. Или путь, при следующей загрузке, длительная проверка файловой системы с использованием fsck будет сделанный. Fsck будет проходить через систему и попытаться восстановить поврежденные файлы, которые он находит. Результатом этой операции восстановления будет помещенный в этот каталог. Восстановленные файлы вряд ли будут полны или имеют смысл, но всегда есть шанс, что что-то стоящее восстанавливается. Каждый раздел имеет свои собственные потерянный + найденный каталог. Если вы находите файлы там, попробуйте переместить их вернуться в исходное местоположение. Если вы найдете что-то вроде сломанного символическую ссылку на «файл», вам необходимо переустановить файлы /с из соответствующий RPM, так как ваша файловая система настолько повреждена, что файлы были искалечены до неузнаваемости. Ниже приведен пример /lost + found. Как вы можете видеть, подавляющее большинство файлов содержащиеся здесь, на самом деле являются сокетами. Что касается остальной части в других файлах были обнаружены поврежденные системные файлы и личные файлы. Эти файлы не были восстановлены.

Источник