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? 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? 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? 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? > So I tried restoring the full thing: > > I'm getting 1000's of messages like where it doesn't seem to be able > to restore the file and instead places it in the orphanage: > > xfsrestore: NOTE: ino 1879669758 salvaging file, placing in orphanage/256.0/tools/libboost/boost_1_64_0/doc/html/boost/accumulators/extract/coherent_tail_mean.html > xfsrestore: NOTE: ino 1879669759 salvaging file, placing in orphanage/256.0/tools/libboost/boost_1_64_0/doc/html/boost/accumulators/extract/count.html > xfsrestore: NOTE: ino 1879669760 salvaging file, placing in orphanage/256.0/tools/libboost/boost_1_64_0/doc/html/boost/accumulators/extract/covariance.html > xfsrestore: NOTE: ino 1879669761 salvaging file, placing in orphanage/256.0/tools/libboost/boost_1_64_0/doc/html/boost/accumulators/extract/density.html > 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. I /think/ this error implies that the backups (dumps) were taken from an active filesystem. 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. Hence some of the files that were recorded in the dump image were removed before the inventory was updated, hence there's no directories present in the inventory that reference those files and so they get salvaged into the orphanage for admin cleanup. 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... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
