tyler/proxmox-backup
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

tape: improve media set docu

Browse Source
This commit is contained in:
Dietmar Maurer 2021-01-08 16:53:46 +01:00
parent df69a4fc59
commit 59217472aa
1 changed files with 47 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
docs/tape-backup.rst
View File

@ -351,32 +351,70 @@ one media pool, so a job only uses tapes from that pool.
A media set is a group of continuously written tapes, used to split A media set is a group of continuously written tapes, used to split
the larger pool into smaller, restorable units. One or more backup the larger pool into smaller, restorable units. One or more backup
jobs write to a media set, producing a group of tapes. Media sets jobs write to a media set, producing an ordered group of
are identified by an unique ID. That ID and the sequence number is tapes. Media sets are identified by an unique ID. That ID and the
stored on each tape of that set (tape label). sequence number is stored on each tape of that set (tape label).
Media sets are the basic unit for restore tasks, i.e. you need all Media sets are the basic unit for restore tasks, i.e. you need all
tapes in the set to restore the set content. Data is fully tapes in the set to restore the media set content. Data is fully
deduplicated inside a media set. deduplicated inside a media set.
.. topic:: Media Set Allocation Policy .. topic:: Media Set Allocation Policy
The pool additionally defines how long backup jobs can append data The pool additionally defines how long backup jobs can append data
to a media set (allocation policy). The following settings are possible: to a media set. The following settings are possible:
:continue: Try to use the current media set. - Try to use the current media set.
:always: Each backup job creates a new media set. This setting produce one large media set. While this is very
space efficient (deduplication, no unused space), it can lead to
long restore times, because restore jobs needs to read all tapes in the
set.
:Calendar Event: Create a new set when the specified CalendarEvent triggers. .. NOTE:: Data is fully deduplicated inside a media set. That
also means that data is randomly distributed over the tapes in
the set. So even if you restore a single VM, this may have to
read data from all tapes inside the media set.
Larger media sets are also more error prone, because a single
damaged media makes the restore fail.
Usage scenario: Mostly used with tape libraries, and you manually
trigger new set creation by running a backup job with the
``--export`` option.
- Always create a new media set.
With this setting each backup job creates a new media set. This
is less space efficient, because the last media from the last set
may not be fully written, leaving the remaining space unused.
The advantage is that this procudes media sets of minimal
size. Small set are easier to handle, you can move sets to an
off-site vault, and restore is much faster.
- Create a new set when the specified Calendar Event triggers.
.. _systemd.time manpage: https://manpages.debian.org/buster/systemd/systemd.time.7.en.html
This allows you to specify points in time by using systemd like
Calendar Event specifications (see `systemd.time manpage`_).
For example, the value ``weekly`` (or ``Mon *-*-* 00:00:00``)
will create a new set each week.
This balances between space efficency and media count.
Additionally, the following events may allocate a new media set: Additionally, the following events may allocate a new media set:
- Required tape is offline - Required tape is offline (and you use a tape library).
- Current set contains damaged of retired tapes. - Current set contains damaged of retired tapes.
- Database consistency errors, e.g. if the inventory does not
contain required media info, or contain conflicting infos
(outdated data).
.. topic:: Retention Policy .. topic:: Retention Policy