Why or why not back up "/lost+found"

[Default User]

Hi!

When backing up my system I have been using this exclusions list:

/dev/*
/proc/*
/sys/*
/tmp/*
/run/*
/mnt/*
/media/*
/lost+found

There are many sources online that suggest that "/lost+found" should be
excluded from backups, but I can't seem to find a good explanation for
why.

I do not know if restoring /lost+found would mess up the file system,
or is it simply "not necessary" to back up/restore /lost+found. 

If backup/restore of /lost+found would not hurt anything, then why not
always back it up for the sake of thoroughness, "just in case". After
all, you can't restore what you have not backed up.

And, if /lost+found should be excluded, then shouldn't "lost+found" in
any other directories be excluded from backups as well? Why/why not?

I think backups are important, so I would like to know now, before I
NEED to know later.

BTW, I am currently using Timeshift for my main system backups (no home
directory), and am using rsync/rsnapshot to back up /, except for the
exclusions listed above. ("Belt and suspenders!").

[Nicolas George]

Default User (12023-08-10):

> And, if /lost+found should be excluded, then shouldn't "lost+found" in
> any other directories be excluded from backups as well? Why/why not?

Before anybody answers all your question, there is something that needs
checking:

Do you know what lost+found is for?

If not, please read some documentation about it. The explanation of its
function contains the answer to the question I left quoted above.

Regards,

--
Nicolas George

[Default User]

Hi, Nicholas.

Well, I did read some documentation, and I have at least a rudimentary
understanding of fsck and lost+found.

Unfortunately, I regret to say that I did not find that the answer to
the question(s) about lost+found in the original post were contained in
the explanation(s) of its function - at least in what I have read so
far.

Or, maybe I'm just stupid.

I'm sorry if I have bothered you.

[Nicolas George]

Default User (12023-08-10):
> > > And, if /lost+found should be excluded, then shouldn't "lost+found"
> > > in any other directories be excluded from backups as well? Why/why
> > > not?

> Unfortunately, I regret to say that I did not find that the answer to
> the question(s) about lost+found in the original post were contained in
> the explanation(s) of its function - at least in what I have read so
> far.

The lost+found directory at the root of the filesystem is special, it is
created when the filesystem is created and set up to receive orphaned
files. A lost+found directory elsewhere… is just a directory with a
wacky name.

Regards,

--
Nicolas George

[Greg Wooledge]

Expanding on this: the only time there are ever going to be files in
the lost+found directory is if your file system has suffered some
damage/corruption, and fsck has found some files that are not
referenced by any directory. Fsck puts those files in lost+found with
a procedurally generated name, since fsck doesn't have any idea what
the file's original names were.

If you ever see files in lost+found, then you know that this has
occurred. Furthermore, it is on *you* to try to figure out what each
file is, where it came from, and what it should be called. This will
be a 100% manual process.

[Bob McGowan]

Almost but not quite completely true.

If you have more than one filesystem on your host, they may also have
lost+found directories which will show up in their mount points.

For example, with your home on a separate disk, mounted on /home, there
may be a /home/lost+found.

The same thinking applies to them as to /lost+found.

Any other location, then it is a user creating a directory or file with
a wacky name, as Nicolas suggests.

Bob

[David Wright]

On Thu 10 Aug 2023 at 15:52:02 (-0700), Bob McGowan wrote:
> On 8/10/23 03:03 PM, Nicolas George wrote:
> > Default User (12023-08-10):
> > > > > And, if /lost+found should be excluded, then shouldn't "lost+found"
> > > > > in any other directories be excluded from backups as well? Why/why
> > > > > not?
> > > Unfortunately, I regret to say that I did not find that the answer to
> > > the question(s) about lost+found in the original post were contained in
> > > the explanation(s) of its function - at least in what I have read so
> > > far.
> > The lost+found directory at the root of the filesystem is special, it is
> > created when the filesystem is created and set up to receive orphaned
> > files. A lost+found directory elsewhere… is just a directory with a
> > wacky name.
> >

> Almost but not quite completely true.
>
> If you have more than one filesystem on your host, they may also have
> lost+found directories which will show up in their mount points.
>
> For example, with your home on a separate disk, mounted on /home,
> there may be a /home/lost+found.
>
> The same thinking applies to them as to /lost+found.

But /home/lost+found is still called /lost+found on the filesystem
it belongs to; it's only now called /home/lost+found because you
mounted that filesystem on /home. That's why Nicolas wrote "at the
root of the filesystem"; that's any filesystem (that uses the concept).

The OP should also note that you musn't use mkdir to create such
directories: mklost+found should be used instead. Typically it
pre-allocates space so that fsck doesn't have to disturb the rest
of the filesystem when it runs.

Cheers,
David.

[Default User]

On Thu, 2023-08-10 at 22:03 +0000, Minecraftchest1 wrote:
> This post on the U&L Stack Exchange sitr summs it up fairly well.
> https://unix.stackexchange.com/a/18157.
>
> In short, `lost+found` is a place for fscheck to link filesystem
> entries that don't have an entry anywhere on the file system, during
> a filesystem check. Chances are, the files there were bring deleted,
> but weren't fully removed from the file system due to an open handle
> on
> the file. If you aren't specifically looking for a file that got lost
> due to a system crash, the files there likely aren't relavent
> and can be safely ignored.
>
>
> On August 10, 2023 9:46:27 PM UTC, Default User

Three of my mount points, each of which is on a separate partition,
have lost+found directories:
/lost+found
/home/lost+found
/var/lost+found

All of these appear to be empty.

Of these, I have rsnapshot configured to exclude:
/lost+found

but the other two:
/home/lost+found
/var/lost+found

ARE currently being backed up.

The backups are to an external usb hard drive, mounted as:
/media/[user]/MSD00001
which has its own lost+found:
/media/[user]/MSD00001/lost+found

which also appears to be empty.

I have read a number of things online about fsck and lost+found,
including the previously mentioned:
https://unix.stackexchange.com/a/18157.

I think I understand the basic concept of how fsck puts stray files and
file parts in lost+found, and (in theory) how to manually extract whole
and partial files from lost+found.

Fortunately, since my lost+found directories are all empty, I have no
"raw material" to practice extraction on.

Now at this point, it seems that I could:

1) Continue to back up /home/lost+found and /var/lost+found, but NOT
back up /lost+found.

2) Start backing up /home/lost+found AND /var/lost+found AND
/lost+found.

3) Start NOT backing up /home/lost+found OR /var/lost+found OR
/lost+found.

What is everyone else doing about backing up, or not backing up, the
various lost+found directories on their systems?

Bonus points for why you do it that way!

:)

[Greg Wooledge]

On Thu, Aug 10, 2023 at 09:15:31PM -0400, Default User wrote:
> Fortunately, since my lost+found directories are all empty, I have no
> "raw material" to practice extraction on.

There's no "extraction". If a file is there, it will be a file. It
will have a meaningful owner, group and permissions. It will have a
meaningless name. You will have to guess what it is based on the
owner, group, permissions, timestamps, and contents.

> Now at this point, it seems that I could:
>
> 1) Continue to back up /home/lost+found and /var/lost+found, but NOT
> back up /lost+found.
>
> 2) Start backing up /home/lost+found AND /var/lost+found AND
> /lost+found.
>
> 3) Start NOT backing up /home/lost+found OR /var/lost+found OR
> /lost+found.
>
> What is everyone else doing about backing up, or not backing up, the
> various lost+found directories on their systems?

You are asking the wrong question.

If you find a file in lost+found, SOMETHING BAD HAS HAPPENED. You
will want to figure out how bad the damage is, and decide what to do
about it.

If the damage is extremely small, then you might be able to figure
out where the files go, and move them.

If the damage is large, you may need to replace the disk and restore
your last working backup. Which will not have anything in lost+found.

Backing up lost+found is pretty meaningless, because if you're backing
up a lost+found with files in it, it means you're backing up a damaged
file system.

What you should be asking instead is whether your backup should ALERT
you if it finds stuff in lost+found. Having it quietly back up the
files is not as helpful as you might be imagining.

[to...@tuxteam.de]

On Thu, Aug 10, 2023 at 03:42:01PM -0400, Default User wrote:
> Hi!
>
> When backing up my system I have been using this exclusions list:
>
> /dev/*
> /proc/*
> /sys/*
> /tmp/*
> /run/*
> /mnt/*
> /media/*
> /lost+found
>
> There are many sources online that suggest that "/lost+found" should be
> excluded from backups, but I can't seem to find a good explanation for
> why.

Squinting the other way (which doesn't contradict what others have
said in this thread): if you see anything in lost+found, the idea
is that you do something about it (rescue it, throw it away). Thus,
the content of lost+found is (or should be) as temporary as, say,
/tmp. And you don't back up that.

So I'd tend to exclude the special "lost+found" dirs (perhaps not
any dir called like that). But then, it's not that important.

Cheers
--
t

[debia...@howorth.org.uk]

One other consideration that I haven't seen mentioned elsewhere in this
thread is what happens if you back up filesystems to filesystems? That
is, if the backup for /home is an ext-? filesystem it may well already
have a /lost+found directory. That directory is hopefully empty but if
not then it contains data related to errors on the backup system, so
you do not want to overwrite it! I suspect that may be why it is
conventionally excluded from backups. It's normally empty so there's no
point in copying it. If there's anything in it on the original or the
backup, then that's a more urgent problem than a backup.

FWIW, I just don't use ext-? filesystems so I don't have to worry.

[to...@tuxteam.de]

On Fri, Aug 11, 2023 at 01:30:13PM +0100, debia...@howorth.org.uk wrote:

[...]

> One other consideration that I haven't seen mentioned elsewhere in this
> thread is what happens if you back up filesystems to filesystems?

I never use the backup's medium top-level dir as a target. In my current
usage, that's how my medium looks like:

tomas@trotzki:~$ ls -l /media/backup
total 20
drwx------ 2 root root 16384 Aug 27 2022 lost+found
drwxr-xr-x 4 root root 4096 Aug 27 2022 trotzki

...so there's a top-level dir named after the "client" host. My backup
scripts gets a positive list of things to back up -- and I sprinkle
files named .backup-filter for more control (I tell rsync about that).

Simple, effective. Putting tons of "--exclude" and things into the
command line will drive you crazy after a while :)

Cheers
--
t

[Default User]

Hi!

Just a clarification, FWIW.

I earlier stated that I back up to:
/media/[user]/MSD00001

I actually back up to:
/media/[user]/MSD00001/rsnapshot_backups_of_[host]
which is of course a sub-directory of /media/[user]/MSD00001.

Anyway, from now on, I am going to explicitly exclude all "lost+found"
directories from being backed up.

Thank you to all who weighed in on this!