extern/zrepl
1
0
Fork 0
mirror of https://github.com/zrepl/zrepl.git synced 2024-11-21 16:03:32 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs: draw attention to risks of not_replicated (#810)

Browse Source 
Co-authored-by: Christian Schwarz <me@cschwarz.com>
This commit is contained in:
wxiaoguang 2024-09-06 05:56:59 +08:00 committed by GitHub
parent 5615f4929a
commit affe00aefe
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/configuration/prune.rst
View File

@ -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``