NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/52432: /etc/dumpdates format egregious

The following reply was made to PR bin/52432; it has been noted by GNATS.

From: Greywolf <>
To: Robert Elz <>, Christos Zoulas <>
Subject: Re: bin/52432: /etc/dumpdates format egregious
Date: Fri, 4 Aug 2017 18:43:30 -0700

 Hi, Robert,
 [I wrote]:
 | > Restore uses restoresymtable to determine whether or not the
 | > incremental restore is of the proper date.
 [You replied]:
 |  That file is more for deleting files that were deleted before one dump
 |  and the incremental that follows, if it also serves to check that the
 |  correct incremental is being restored, that's news ... but I am not sure
 |  how it really can (except perhaps to make sure that one from earlier
 |  than the previous restore is not attempted) - it is built from the
 |  contents of the level N dump when it is restored, and so can only possibly
 |  have info that existed when that dump was done - what the next dump level
 |  would be, for the next incremental, cannot possibly be known then, nor is
 |  it really possible to tell if a level is skipped in the restore sequence,
 |  as only the changes get dumped, and all the changes do, but when we come
 |  to a restore, we (ie: restore) cannot tell if a dir/inode is not on the
 |  backup because it was never changed (between previous and current) or
 |  whether it was changed, but backed up onto an intermediate level dump that
 |  happened between the one that has already been restored, and the one that
 |  is now about to be - except in some quite rare cases (that is, nothing that
 |  we can rely upon.)
 Here's my understanding:
 The restoresymtable contains, among the inode map and such:
 * the device which was dumped,
 * possibly the filesystem name associated with the device (if it can figure
    it out),
 * possibly a dump label (optional),
 * the level of the dump last restored from,
 * the date of said dump (the day the files were dumped on),
 * the date SINCE files were dumped (i.e. the date of the previous dump,
    which would have shown on the screen during the dump as
    "Date of last level <X> dump:").
 If you do a level 0 full restore (-r), with the intention of doing an
 incremental restore (handling deletions/moves), your next restore MUST
 come from a dump whose last-dumped-from date matches the date of the
 level 0, and so on, or the incremental restore will fail.
 If an incremental restore depended on /etc/dumpdates, we'd never be able
 to get an integral incremental restore of the root filesystem, nor any
 other filesystem thereafter if we needed to restore the whole thing,
 because the relevant information to the current dump wouldn't be available
 until it finished.

Home | Main Index | Thread Index | Old Index