]>
Commit | Line | Data |
---|---|---|
ec1ae7e6 | 1 | .. _terms: |
1531185d | 2 | |
04e24b14 DW |
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 | ||
ec1ae7e6 | 104 | .. _term_backup_snapshot: |
04e24b14 DW |
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 |