Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #260814 > unrolled thread

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

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why or why not back up "/lost+found" Nicolas George <george@nsup.org> - 2023-08-10 21:50 +0200
    Re: Why or why not back up "/lost+found" Default User <hunguponcontent@gmail.com> - 2023-08-10 23:50 +0200
      Re: Why or why not back up "/lost+found" Nicolas George <george@nsup.org> - 2023-08-11 00:10 +0200
        Re: Why or why not back up "/lost+found" Greg Wooledge <greg@wooledge.org> - 2023-08-11 00:30 +0200
        Re: Why or why not back up "/lost+found" Bob McGowan <tumcsv@gmail.com> - 2023-08-11 01:10 +0200
          Re: Why or why not back up "/lost+found" David Wright <deblis@lionunicorn.co.uk> - 2023-08-11 01:40 +0200
      Re: Why or why not back up "/lost+found" Default User <hunguponcontent@gmail.com> - 2023-08-11 03:20 +0200
        Re: Why or why not back up "/lost+found" Greg Wooledge <greg@wooledge.org> - 2023-08-11 04:20 +0200

#260814 — Re: Why or why not back up "/lost+found"

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#260816

On Thu, 2023-08-10 at 21:45 +0200, 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? 
> 
> 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,
> 


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. 

[toc] | [prev] | [next] | [standalone]

#260817

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#260818

On Fri, Aug 11, 2023 at 12:03:26AM +0200, 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.

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.

[toc] | [prev] | [next] | [standalone]

#260819

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.
>
> Regards,
>
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

[toc] | [prev] | [next] | [standalone]

#260820

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.

[toc] | [prev] | [next] | [standalone]

#260821

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
> <hunguponcontent@gmail.com> wrote:
> > On Thu, 2023-08-10 at 21:45 +0200, 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? 
> > > > 
> > > 
> > > 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,
> > > 
> > > 
> > 
> > 
> > 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. 
> > 


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!

:)

[toc] | [prev] | [next] | [standalone]

#260823

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web