docs/terminology.rst

   1 .. _terms:
   2
   3 Terminology
   4 ===========
   5
   6 Backup Content
   7 --------------
   8
   9 When doing deduplication, there are different strategies to get
  10 optimal results in terms of performance and/or deduplication rates.
  11 Depending on the type of data, it can be split into *fixed* or *variable*
  12 sized chunks.
  13
  14 Fixed sized chunking requires minimal CPU power, and is used to
  15 backup virtual machine images.
  16
  17 Variable sized chunking needs more CPU power, but is essential to get
  18 good deduplication rates for file archives.
  19
  20 The Proxmox Backup Server supports both strategies.
  21
  22
  23 Image Archives: ``<name>.img``
  24 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  25
  26 This is used for virtual machine images and other large binary
  27 data. Content is split into fixed-sized chunks.
  28
  29
  30 File Archives: ``<name>.pxar``
  31 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  32
  33 .. see https://moinakg.wordpress.com/2013/06/22/high-performance-content-defined-chunking/
  34
  35 A file archive stores a full directory tree. Content is stored using
  36 the :ref:`pxar-format`, split into variable-sized chunks. The format
  37 is optimized to achieve good deduplication rates.
  38
  39
  40 Binary Data (BLOBs)
  41 ~~~~~~~~~~~~~~~~~~~
  42
  43 This type is used to store smaller (< 16MB) binary data such as
  44 configuration files. Larger files should be stored as image archive.
  45
  46 .. caution:: Please do not store all files as BLOBs. Instead, use the
  47    file archive to store whole directory trees.
  48
  49
  50 Catalog File: ``catalog.pcat1``
  51 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  52
  53 The catalog file is an index for file archives. It contains
  54 the list of files and is used to speed up search operations.
  55
  56
  57 The Manifest: ``index.json``
  58 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  59
  60 The manifest contains the list of all backup files, their
  61 sizes and checksums. It is used to verify the consistency of a
  62 backup.
  63
  64
  65 Backup Type
  66 -----------
  67
  68 The backup server groups backups by *type*, where *type* is one of:
  69
  70 ``vm``
  71     This type is used for :term:`virtual machine`\ s. Typically
  72     consists of the virtual machine's configuration file and an image archive
  73     for each disk.
  74
  75 ``ct``
  76     This type is used for :term:`container`\ s. Consists of the container's
  77     configuration and a single file archive for the filesystem content.
  78
  79 ``host``
  80     This type is used for backups created from within the backed up machine.
  81     Typically this would be a physical host but could also be a virtual machine
  82     or container. Such backups may contain file and image archives, there are no restrictions in this regard.
  83
  84
  85 Backup ID
  86 ---------
  87
  88 A unique ID. Usually the virtual machine or container ID. ``host``
  89 type backups normally use the hostname.
  90
  91
  92 Backup Time
  93 -----------
  94
  95 The time when the backup was made.
  96
  97
  98 Backup Group
  99 ------------
 100
 101 The tuple ``<type>/<ID>`` is called a backup group. Such a group
 102 may contain one or more backup snapshots.
 103
 104 .. _term_backup_snapshot:
 105
 106 Backup Snapshot
 107 ---------------
 108
 109 The triplet ``<type>/<ID>/<time>`` is called a backup snapshot. It
 110 uniquely identifies a specific backup within a datastore.
 111
 112 .. code-block:: console
 113    :caption: Backup Snapshot Examples
 114
 115     vm/104/2019-10-09T08:01:06Z
 116     host/elsa/2019-11-08T09:48:14Z
 117
 118 As you can see, the time format is RFC3399_ with Coordinated
 119 Universal Time (UTC_, identified by the trailing *Z*).
 120
 121