On 11/28/16 3:21 AM, Dave Chinner wrote: > 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. Got it. Thanks. At the end of the backup, wouldn't xfsdump know what files were not able to be backed up, though? In my case, I had a level 0 backup, and also a level 1 backup. The problematic file wasn't present / able-to-be-restored in either backup set. That is, if somebody does a level 0 backup, and a file isn't properly backed up for whatever reason, that file is flagged as "not backed up". That would allow it to be subsequently backed up in a higher-level-number backup. Note that in my case, I tried restoring from the most-recent level 1 backup, the most-recent level 0 backup, and an older level 0 backup as well. None were able to restore the file. If this isn't possible, then I suspect that an xfsdump/xfsrestore of a (running?) system perhaps isn't as robust as I had hoped. In particular, that you might not have all of the files that you need, but you won't know until you actually go to use the system you restored. Thanks -WD -- 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
