[pbs-devel] [PATCH proxmox-backup 1/2] docs: explain retention time for event allocation policy in more detail

[pbs-devel] [PATCH proxmox-backup 1/2] docs: explain retention time for event allocation policy in more detail

[Dominik Csapak]

'when the calendar event' triggers was too vague, it could mean for
the current media-set or the next time. Apart from that, it was not
technically correct all the time, since we take the start time of
the next media set if that exists first.

The idea here is that we begin the retention when the media set is
finished.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 docs/tape-backup.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/tape-backup.rst b/docs/tape-backup.rst
index a8d6b7fd..ae597d3d 100644
--- a/docs/tape-backup.rst
+++ b/docs/tape-backup.rst
@@ -519,8 +519,9 @@ a single media pool, so a job only uses tapes from that pool.
 
      This balances between space efficiency and media count.
 
-     .. NOTE:: Retention period starts when the calendar event
-        triggers.
+     .. NOTE:: Retention period starts on the creation time of the next
+        media-set or, if that does not exist, when the calendar event
+        triggers the next time after the current media-set start time.
 
    Additionally, the following events may allocate a new media set:
 
-- 
2.30.2

[pbs-devel] [PATCH proxmox-backup 2/2] docs: add tape schedule examples

[Dominik Csapak]

just a few examples how one could configure tape pools and jobs.

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
 docs/tape-backup.rst | 71 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/docs/tape-backup.rst b/docs/tape-backup.rst
index ae597d3d..8b268d55 100644
--- a/docs/tape-backup.rst
+++ b/docs/tape-backup.rst
@@ -979,3 +979,74 @@ This command does the following:
 - run drive cleaning operation
 
 - unload the cleaning tape (to slot 3)
+
+Example Setups
+--------------
+
+Here are a few example setups for how to manage media pools and schedules.
+This is not an exhaustive list, and there are many more possible combinations
+of useful settings.
+
+Simple Setup
+~~~~~~~~~~~~
+
+The most simple setup, always continue the media-set and never expire.
+All backups are stored on a single media set and never deleted.
+
+Allocation policy:
+  continue
+
+Retention policy:
+  keep
+
+Such a simple setup has the advantage that it uses not much space, and
+since there is only one media-set, it is easy to manage. On the other hand,
+it is prone to errors. If a single tape fails, all backups that uses chunks
+from that tape will not be restorable.
+
+Weekday Scheme
+~~~~~~~~~~~~~~
+
+A slightly more complex scheme, where the goal is to have a tape for each
+weekday, e.g. from Monday to Friday. This can be solved by having a seperate
+media pool for each day, so 'Monday', 'Tuesday', etc.
+
+Allocation policy:
+  should be 'mon' for the 'Monday' pool, 'tue' for the Tuesday pool and so on.
+
+Retention policy:
+  overwrite
+
+There should be a (or more) tape-backup jobs for each pool on the correspondig
+weekday. This scheme is still easily managable with one media set per weekday,
+which can even be taken off site easily.
+
+Staggered Pools
+~~~~~~~~~~~~~~~
+
+Alternatively, more complex setups are possible with multiple media pools and
+different allocation and retention policies.
+
+An example would be to have a media pool with weekly rotation:
+
+Allocation policy:
+  mon
+
+Retention policy:
+  3 weeks
+
+This creates a new media set each week, and rotates them out after the 4th
+media set.
+
+Then in addition, there could be a yearly pool that only rotates once a year,
+but will not be expired (e.g. for long-term archival purposes):
+
+Allocation policy:
+  yearly
+
+Retention policy:
+  keep
+
+In combination with suited prune settings and tape backup schedules, this
+achieves long-term storage of some backups, while keeping the current
+backups on smaller media sets that rotate out every 4 weeks.
-- 
2.30.2