If you look at the inventory after an interrupted backup, it
will indicate the stream (and media file) start and end points.
If the end point is "ino 0 offset 0", then a resumed restore
will end up backing up everything again.
If you can, please try this with the top-of-tree code from
the git tree on kernel.org. I did a quick test and it seems
to be working there.
Note that if you're backing up to stdout, xfsdump cannot
determine when the output is safely on media, so a resumed
backup will always be a full backup.
Bill
Gim Leong Chin wrote:
Hi,
I have observed this since some time back. I have just done an experiment.
1) Using xfsdump 3.0.6, I first did a full dump to regular file and restore,
checked that every thing is correct.
2) I then did the same dump again, but interrupted it. Then I resumed the
dump. I noted that the resumed dump file is the exact same size as the full
dump file.
3) First I did a cumulative restore, with the interrupted dump file, followed
by the resumed dump file. I checked that the restore is correct.
4) I then did a non-cumulative restore, using only resumed dump file. The
resume is successful, and I checked that the restore is correct.
The logs are attached.
The conclusion is that the so-called resume of an interrupted dump session to
regular file produces a full dump file, that is sufficient by itself to do the
full restore.
Are my observations of the behaviour of xfsdump correct?
Everything was done on openSUSE 11.4 x86_64.
GL
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
|