mirror of
https://github.com/zrepl/zrepl.git
synced 2024-12-22 23:20:51 +01:00
1c270b7e39
This is a stop-gap solution until we re-write the pruner to support rules for removing step holds. Note that disabling step holds for incremental sends does not affect zrepl's guarantee that incremental replication is always possible: Suppose you yank the external drive during an incremental @from -> @to step: * restarting that step or future incrementals @from -> @to_later` will be possible because the replication cursor bookmark points to @from until the step is complete * resuming @from -> @to will work as long as the pruner on your internal pool doesn't come around to destroy @to. * in that case, the replication algorithm should determine that the resumable state on the receiving side isuseless because @to no longer exists on the sending side, and consequently clear it, and restart an incremental step @from -> @to_later refs #288 |
||
---|---|---|
.. | ||
gen | ||
batchDestroy.go | ||
generated_cases.go | ||
getNonexistent.go | ||
helpers.go | ||
holds.go | ||
idempotentBookmark.go | ||
idempotentDestroy.go | ||
idempotentHold.go | ||
listFilesystems.go | ||
listFilesystemVersions.go | ||
recvForceIntoEncryptedErr.go | ||
recvRollback.go | ||
replication.go | ||
replicationCursor.go | ||
resumableRecvAndTokenHandling.go | ||
resumeTokenParsing.go | ||
resumeTokensGenerate.bash | ||
sendArgsValidation.go | ||
tests.go | ||
undestroyableSnapshotParsing.go |