From: Dominik Csapak <d.csapak@proxmox.com>
To: pbs-devel@lists.proxmox.com
Subject: [pbs-devel] [PATCH proxmox-backup 2/2] docs: add tape schedule examples
Date: Fri, 25 Feb 2022 12:33:05 +0100 [thread overview]
Message-ID: <20220225113305.3862718-2-d.csapak@proxmox.com> (raw)
In-Reply-To: <20220225113305.3862718-1-d.csapak@proxmox.com>
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
prev parent reply other threads:[~2022-02-25 11:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 11:33 [pbs-devel] [PATCH proxmox-backup 1/2] docs: explain retention time for event allocation policy in more detail Dominik Csapak
2022-02-25 11:33 ` Dominik Csapak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220225113305.3862718-2-d.csapak@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.