Если вы запускаете fsck — утилиту для проверки и починки файловой системы — она может найти фрагменты данных, на которые никто не ссылается. Чаще всего это выглядит как целый файл, у которого нет имени в системе: inode без соответствующего имени. Данные место занимают, но обычными способами к ним не подобраться.
Если сказать fsck чинить файловую систему, он превратит эти почти удалённые файлы обратно в полноценные. Проблема в том, что имя и местоположение файла уже потеряны. Поэтому fsck сваливает всё в специальную директорию — lost+found.
Откуда там берутся файлы? Самый частый сценарий: файл уже был удалён (имя стёрли), но оставался открытым в каком-то процессе — данные ещё не стёрли. И тут система внезапно упала: kernel panic или отключили свет. Если дело только в этом, файлы всё равно были обречены на удаление, и можно просто забыть о них.
Второй вариант — файловая система оказалась в неконсистентном состоянии из-за бага в софте или железе. Тогда lost+found — это шанс найти то, что система восстановила. Только нет гарантии, что внутри полезные данные. Файлы могут быть битыми, устаревшими или вообще пустыми. Всё зависит от того, насколько серьёзно повреждена файловая система.
Важный технический нюанс: на многих файловых системах lost+found — особый каталог. Он заранее резервирует немного места, чтобы fsck мог туда складывать восстановленные записи. Речь не про сами данные (их fsck не трогает), а про записи в каталоге, которые системе приходится создавать с нуля. Если вы случайно удалили lost+found, не пытайтесь воссоздать его через mkdir. Используйте утилиту mklost+found, если она есть в системе — иначе fsck может не сработать как надо.