mirror of
https://github.com/zrepl/zrepl.git
synced 2024-11-26 02:14:44 +01:00
5b564a3e28
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 | ||