View Ticket
Ticket UUID: 22962fd50076048f30b72a41f992feefb7440cd2
Title: Snapshot sync facility
Status: Open Type: Feature_Request
Severity: UNSPECIFIED Priority: 2_Medium
Subsystem: Backup_Frontend Resolution: Open
Last Modified: 2016-09-25 17:11:22
Version Found In:
Building on the core logic in [1d491d7ec2], we could also sync snapshot tags between vaults.

Again, we name source and destination tags. If the destination tag exists it must be a snapshot tag, and it must point to a predecessor of what the source tag points to, so it can just be advanced after the content has been synchronised.

If the destination tag does not exist, it can be created.

The mirroring should be able to be limited to the depth of snapshot chain it traverses (with a number of snapshots, or a date limit, either as an absolute date or "now minus specified interval". If there is no existing destination tag, we create the chain with a dangling pointer if we hit the limit. If there is an existing destination tag, then the current state of it must be an ancestor of the source tag within the limit.

Unless a special "rebase" option is given - in which case, we don't directly copy snapshot blocks, but copy their contents and update the "previous" pointer to point to what's currently on the destination tag (or none if it didn't exist), just like a git rebase. That makes it easy to, say, once a month sync across the most recent snapshot, to create a vault that has one snapshot per month while the main one has a snapshot per day, etc.