Last October there was some discussion of the problems that arise
when taking incremental dumps with ufsdump against a UFS snapshot.
The crux is that the time that ufsdump writes into /etc/dumpdates
is that when ufsdump starts, not that when the snapshot was taken.
Therefore incremental dumps taken relative to that dump may fail
to include files that were last modified during the gap.
As a result of that thread, a sneaky workround occurred to me: get
the snapshot creation time with "fssnap -i -o createtime /what/ever"
and use it to adjust the /etc/dumpdates entry after ufsdump has run.
I am not sure whether I ever posted this.
I hope not, because the scheme has a fatal flaw. The original dump's
header info contains the time it was run (that it is going to write
into /etc/dumpdates), while the incremental dump's header says that
it was taken relative to a dump with the adjusted (earlier) time.
When you do a recursive restore (ufsrestore -r), the increment gets
rejected with "Incremental volume too high" (meaning "relative to
an earlier dump than the one I just restored").
It's a little alarming that it took me nine months to notice this.
So much for all those pious words about testing one's disaster
recovery procedures... :-(
I suppose I will just have to work on getting Sun to fix the original
bug (e.g. by having ufsdump get and use the snapshot creation time, or
at least by letting the caller specify the reference time).
Email: cet1 [at] cam.ac.uk