docs: improve tape-backup examples
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
This commit is contained in:
parent
787c6550d4
commit
bd0300917e
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user