mirror of
https://github.com/zrepl/zrepl.git
synced 2024-11-24 09:24:09 +01:00
docs: draw attention to risks of not_replicated
(#810)
Co-authored-by: Christian Schwarz <me@cschwarz.com>
This commit is contained in:
parent
5615f4929a
commit
affe00aefe
@ -50,6 +50,7 @@ Example Configuration:
|
||||
regex: "^manual_.*"
|
||||
|
||||
.. DANGER::
|
||||
|
||||
You might have **existing snapshots** of filesystems affected by pruning which you want to keep, i.e. not be destroyed by zrepl.
|
||||
Make sure to actually add the necessary ``regex`` keep rules on both sides, like with ``manual`` in the example above.
|
||||
|
||||
@ -71,6 +72,14 @@ It only makes sense to specify this rule for the ``keep_sender``.
|
||||
The reason is that, by definition, all snapshots on the receiver have already been replicated to there from the sender.
|
||||
To determine whether a sender-side snapshot has already been replicated, zrepl uses the :ref:`replication cursor bookmark <replication-cursor-and-last-received-hold>` which corresponds to the most recent successfully replicated snapshot.
|
||||
|
||||
.. ATTENTION::
|
||||
|
||||
If you use ``not_replicated`` in your pruning rules, make sure to :ref:`monitor <monitoring>` replication.
|
||||
If your replication gets stuck then ``not_replicated`` causes snapshots to pile uip on the sender.
|
||||
ZFS and especially the ``zfs`` management command are known to degrade in performance with a lot of snapshots.
|
||||
Such degradation impacts zrepl, any other scripts, and human ability to manage your zpool.
|
||||
|
||||
|
||||
.. _prune-keep-retention-grid:
|
||||
|
||||
Policy ``grid``
|
||||
|
Loading…
Reference in New Issue
Block a user