From affe00aefe4e6c746b568aca3569e3f02209d050 Mon Sep 17 00:00:00 2001 From: wxiaoguang Date: Fri, 6 Sep 2024 05:56:59 +0800 Subject: [PATCH] docs: draw attention to risks of `not_replicated` (#810) Co-authored-by: Christian Schwarz --- docs/configuration/prune.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/configuration/prune.rst b/docs/configuration/prune.rst index 1980ea1..1d9f26e 100644 --- a/docs/configuration/prune.rst +++ b/docs/configuration/prune.rst @@ -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 ` which corresponds to the most recent successfully replicated snapshot. +.. ATTENTION:: + + If you use ``not_replicated`` in your pruning rules, make sure to :ref:`monitor ` 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``