Unless i'm missing something, they didn't solve the "matching snapshots"
thing yet, from their site:
Additional error handling for mismatched snapshots (last destination snap
no longer exists on the source) walk backwards through the remote snaps
until a common snapshot is found and destroy non-matching remote snapshots"
As more evidence, the script doesn't contain any for loops, and has
comments that indicate it just uses the latest snapshot on the target. It
also doesn't appear that the script uses "zfs hold" anywhere, so I don't
think it will stop the auto-snapshots from disappearing on the source (i'm
also not sure how the auto-snap service will respond to a failure to
destroy a held snapshot, i've had it go into maintenance mode on me for
just changing the timezone).
Why are you trying to solve this harder problem, rather than using your own
snapshots that the auto-snapshot service won't destroy? If you make a
snapshot that doesn't start with zfs-auto-snap, then use it (them) as the
endpoint(s) for the transfer, adding holds if desired, this entire mess of
matching snapshots that may or may not still exist just goes away.
On Wed, Sep 12, 2012 at 5:05 PM, Edward Ned Harvey
> > From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> > boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
> > Question #2: What's the best way to find the latest matching snap on
> > the source and destination? At present, it seems, I'll have to build a
> list of
> > sender snaps, and a list of receiver snaps, and parse and search them,
> till I
> > find the latest one that exists in both. For shell scripting, this is
> very non-
> > trivial.
> Someone replied to me off-list and said:
> Try http://blog.infrageeks.com/auto-replicate/
> Does everything you're looking for in a portable shell script.
> The auto-backup adds in zfs holds
> zfs-discuss mailing list
zfs-discuss mailing list