If you run
fsck, the filesystem check and repair command, it might find data fragments that are not referenced anywhere in the filesystem. In particular,
fsck might find data that looks like a complete file but doesn’t have a name on the system — an inode with no corresponding file name. This data is still using up space, but it isn’t accessible by any normal means.
If you tell
fsck to repair the filesystem, it will turn these almost-deleted files back into files. The thing is, the file had a name and location once, but that information is no longer available. So
fsck deposits the file in a specific directory, called
lost+found (after lost and found property).
Files that appear in
lost+found are typically files that were already unlinked (i.e. their name had been erased) but still opened by some process (so the data wasn’t erased yet) when the system halted suddenly (kernel panic or power failure). If that’s all that happened, these files were slated for deletion anyway, you don’t need to care about them.
Files can also appear in
lost+found because the filesystem was in an inconsistent state due to a software or hardware bug. If that’s the case, it’s a way for you to find files that were lost but that the system repair managed to salvage. The files may or may not contain useful data, and even if they do they may be incomplete or out of date; it all depends how bad the filesystem damage was.
On many filesystems, the
lost+found directory is a bit special because it preallocates a bit of space for
fsck to deposit files there. (The space isn’t for the file data, which
fsck leaves in place; it’s for the directory entries which
fsck has to make up.) If you accidentally delete
lost+found, don’t re-create it with
mklost+found if available.
lost+found directory (not Lost+Found) is a construct used by
fsck when there is damage to the filesystem (not to the hardware device, but to the fs). Files that would normally be lost because of directory corruption would be linked in that filesystem’s
lost+found directory by inode number. Some of these might be lost directories or lost files or even lost devices. Each filesystem should have its own
lost+found directory, but you might be looking at a system with only one filesystem. In general, you should hope that the directory is empty; but if there is corruption, be thankful that in many conditions files can be recovered after
fsck places them here.
From “Linux Filesystem Hierarchy”, section /lost+found”:
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 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.