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:
---
-> ls /etc/mythtv
4032 session-settings
4127166 session-settings~
50343916 config.xml
4884092 mysql.txt~
-> add /etc/mythtv/config.xml
-> extract
--------------------------------- end dialog
---------------------------------
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: mkdir etc
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: mkdir etc/mythtv
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: dump session label: ""
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: dump session id:
f132cc65-5bd4-4a58-a810-52398fe99326
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: stream 0, object 0, file 0
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: restoring non-directory files
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: media file 0 in object 0
of stream 0
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: restore complete: 207
seconds elapsed
/home/wd/in/xfsdump-3.1.6/restore/xfsrestore: Restore Status: SUCCESS
---
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 tried creating a new dump with 3.1.6, and subsequently restoring with
3.1.6, and it did succeed in restoring config.xml.
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.
-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
