[pbs-devel] [PATCH proxmox-backup] docs: improve tape-backup examples

[Dominik Csapak]

Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
---
thanks @thomas for looking over it

 docs/tape-backup.rst | 43 ++++++++++++++++++++-----------------------
 1 file changed, 20 insertions(+), 23 deletions(-)

diff --git a/docs/tape-backup.rst b/docs/tape-backup.rst
index 5d4ce444..1511ba32 100644
--- a/docs/tape-backup.rst
+++ b/docs/tape-backup.rst
@@ -987,11 +987,10 @@ 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
-~~~~~~~~~~~~
+Single Continued Media Set
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The most simple setup, always continue the media-set and never expire.
-All backups are stored on a single media set and never deleted.
+The most simple setup: always continue the media-set and never expire.
 
 Allocation policy:
   continue
@@ -999,20 +998,22 @@ Allocation policy:
 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. If you want to start a new media-set
-manually, you can set the currently writable media of the set either to
-'full', or set the location to an offsite vault. In that case, a new
-media-set will be created.
+This setup has the advantage of being easy to manage and is re-using the benefits
+from deduplication as much as possible. But, it's also prone to a failure of
+any single tape, which would render all backups referring to chunks from that
+tape unusable.
+
+If you want to start a new media-set manually, you can set the currently
+writable media of the set either to 'full', or set the location to an
+offsite vault.
 
 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.
+A slightly more complex scheme, where the goal is to have an independent
+tape or media set for each weekday, for example from Monday to Friday.
+This can be solved by having a separate 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.
@@ -1020,12 +1021,12 @@ Allocation policy:
 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,
+There should be a (or more) tape-backup jobs for each pool on the corresponding
+weekday. This scheme is still very manageable with one media set per weekday,
 which can even be taken off site easily.
 
-Staggered Pools
-~~~~~~~~~~~~~~~
+Multiple pools with different policies
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Alternatively, more complex setups are possible with multiple media pools and
 different allocation and retention policies.
@@ -1038,11 +1039,7 @@ Allocation policy:
 Retention policy:
   3 weeks
 
-This creates a new media set each week, and expires them after the 4th
-media set.
-
-Then in addition, there could be a yearly pool that only gets allocated
-once a year, but will not be expired (e.g. for long-term archival purposes):
+And another pool with yearly allocation that does not expire:
 
 Allocation policy:
   yearly
-- 
2.30.2