search

oetiker / znapzend

zfs backup with remote capabilities and mbuffer integration.
www.znapzend.org
GNU General Public License v3.0
603 stars 136 forks source link

Quirk may be needed for destination rollback (e.g. --sinceForced=x mode) at least on Oracle Solaris 10u11 #526

Closed jimklimov closed 3 years ago

jimklimov commented 3 years ago

It was recently brought to my attention that a resync of broken backup chain failed due to "cannot receive incremental stream: most recent snapshot of does not match incremental source", even when zfs send -I source@oldsnap source@newestsnap | zfs recv -u -F destination was in use, and the destination also had some newer snapshots that ought to have disappeared to make way.

This was also reproduced manually on command line. If we started from a few common snapshots back into the past, zfs-receive skipped over the snaps already available on destination, and hiccupped just after the last one common (without naming an offending one present on destination).

It worked after I manually destroyed the snapshots newer than the latest one in common.

There was an expectation that zfs recv -F would delete the offending snapshots from destination, but doc seems a bit vague on this detail -- perhaps it only does so for replication streams (zfs send -R -[iI] - and then also kills off internediate snaps that are no longer on source even if they do not offend the receive operation), and otherwise it only rolls back the "live" state of destination dataset to last present snapshot and then finds it is not common with the stream from source.

So... at least on some systems as an option, or maybe everywhere as "The One True Way" if I originally mis-read the man page, we need to make sure ourselves the destination is rolled back to a newest snapshot it has in common with the source (looking by name at least, or by guid?) whenever we do not forbidDestRollback and specify zfs recv -F. Maybe do so after a zfs recv fails, to let the smarter OS try to figure out first what it can do to ensure a proper receive the way we want it - usually unsupervised and unbroken.

This might rightfully require caution in regular operations (now with source cleanup supposedly constrained by keeping the last snapshot that was known to be on a destination, such aggressive rollback is not likely needed - and when it is, likely humans should intevene to decide); however it is sort of the job description for --sinceForced=x mode.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.