On 2021/10/28 19:34, L A Walsh wrote:
On 2021/10/25 17:48, Dave Chinner wrote:
On Mon, Oct 25, 2021 at 02:30:08PM -0700, L A Walsh wrote:
> I'm trying to do a cumulative restore a directory from a multi-file
backup
> w/names:
> -rw-rw-r-- 1 1578485336160 Oct 1 06:51 home-211001-0-0437.dump
> -rw-rw-r-- 1 262411348256 Oct 23 04:53 home-211023-1-0431.dump
> -rw-rw-r-- 1 1881207032 Oct 25 04:31 home-211025-2-0430.dump
>
Have you ever successfully restored a directory from a multi-file
backup?
---
many times. I thought back to when I 1st noticed this prob: When
I replaced my disks when I had to get new containers.
All of the backed up "devices" (meta lvm partitions) needed
a new lvl 0 then.
Before that, never a problem, after that, only have had about 2 times
trying a restore -- both times, had the message about an ino
being placed in the orphanage.
The first time this happened, my /home was restored under
orphanage/<256.0>. I.e. complete /home tree started at:
/home/orphanage/<256.0>/home
This time, nothing at all appears under /home/orphanage/<256.0>
and, interactively in the lvl-0 dump of the home backup,
nothing appears when I try 'ls' in xfsrestore (interactively) at
the root of backup.
Note that restore errors are often caused by something going wrong
during the dump and it not being noticed until restore is run and
the error found. And at that point, there's nothing that can be done
to "fix" the dump image so it can be restored.
What was the xfs_dump commands that created these dump files?
The scripts that create the dumps date back to 2008 with last
revisions in 2013, so their style makes it hard to conveniently
provide a listing of params.
I decided the scripts ned a bit of modernizing and refactoring
to allow easier additions (like echoing the command being
executed...etc)
Did you take the dumps from a frozen filesystem or a read-only
snapshot of the filesystem, or just take it straight from a running
system?
----
Does xfs support creating of arbitrary read-only snapshots?
In the past 20+ years running snapshots haven't ever used
a frozen snapshot -- never been that important.
What happens if you try to restore one dump at a time? i.e. is the
problem in the level 0 dump, or in one of the incrementals that are
based on the level 0 dump?
----
Both, with the most problems in lvl 0.
> xfsrestore: NOTE: ino 1879669762 salvaging file, placing in
orphanage/256.0/tools/libboost/boost_1_64_0/doc/html/boost/accumulators/extract/extended_p_square.html
IIUC, this means an ancestor directory in the path doesn't exist in
the inventory and so the path for restore cannot be resolved
correctly. Hence the inode gets placed in the orphanage under the
path name that is stored with the inode.
"/home" has an ancestor dir of "/" and "home". When trying to
restore /home interactively, it showed no files in the root
directory.
I /think/ this error implies that the backups (dumps) were taken from
an active filesystem.
This part is most definitely true, w/default backups being run
at 4:30am when the system wasn't likely to be in active use.
i.e between the time the dump was started
and when the inventory was finally updated, the directory structure
had changed and so the dump is internally inconsistent.
----
Don't think this is possible. Backup is of contents of
/home. I.e. only '/' and '/home' could be deleted/missing,
Neither of which is likely.
It would be interesting to know what part of the above path is
actually missing from the dump inventory, because that might help
explain what went/is going wrong...
---
Well, at very least am going to rewrite/refactor these
scripts to get some more answers.
