On Mon, Nov 28, 2016 at 12:00:06AM -0500, Will Dormann wrote: > Hi Dave, > > On 11/27/16 8:59 PM, Dave Chinner wrote: > >> So what can cause a file to silently be skipped during restore? > > > > Usually nothing. This is typical of xfsdump skipping a file due to > > some unexpected occurrence during backup. It's in the dump > > inventory as the directory was processed, but if somthing changed > > during the dump process (e.g. file gets replaced due to atomic > > overwrite via rename) then it may not end up being in the dump. > > This file pretty much never gets written to after the first install of > the system, so I wouldn't suspect anything like that would have happened. > > > >> I'm > >> running the latest xfsdump/xfsrestore provided by Ubuntu 14.04, which is > >> 3.1.1. I notice the same symptoms from my recovery environment, which > >> is SystemRescueCD 4.2.0 > > > > That's /old/. Try running the latest (3.1.6 IIRC) and see if that > > fixes the issue. > > > I tried running xfsrestore 3.1.6 on the existing 3.1.1 dump, and I got > the same symptoms: Yes, that's expected - the file is missing from the dump, indicating a problem exncountered by xfsdump, not xfsrestore. > If the latest xfsrestore indicates that a file is in a backup, but then > doesn't actually restore it when asked, isn't that still indicative of a > problem? That is, if xfsrestore indicates that a file is in a backup, > shouldn't it be restoring something? I think you misunderstand how the inventory and dump process works. The dump process first builds the inventory inode map that it needs to back up, then goes and backs up what it mapped in the inventory. The filesystem can change between the inventory build an dump trying to backup the file, and if the file does not match the inventory for some reason (e.g. different inode generation number) it will skip it. The file does not get removed from the inventory, though, because that's already been written to the dump file. There have also been situations where kernel bugs have meant xfsdump missed files. e.g. off-by-ones in bulkstat continuation code. These bugs had identical symptoms to what you are reporting, but given a new dump worked this is probably not the issue.... > I tried creating a new dump with 3.1.6, and subsequently restoring with > 3.1.6, and it did succeed in restoring config.xml. Yup, no surprise there, either. > However, that may possibly have nothing to do with any sort of fix. > Because I couldn't restore config.xml when I did my system restore, I > had to create a new copy of it from a file-level backup. Therefore, the > original problematic file isn't present anywhere other than my existing > xfsdump backups. Yup, in general, problems with dump contents seen with xfs_restore are most likely going to be a dump issue and can only be rectified by running new backups. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
