:pve-toplevel:
endif::manvolnum[]
-Backups are a requirements for any sensible IT deployment, and {pve}
+Backups are a requirement for any sensible IT deployment, and {pve}
provides a fully integrated solution, using the capabilities of each
storage and each guest system type. This allows the system
administrator to fine tune via the `mode` option between consistency
`snapshot` mode::
This mode provides the lowest operation downtime, at the cost of a
-small inconstancy risk. It works by performing a Proxmox VE live
+small inconsistency risk. It works by performing a {pve} live
backup, in which data blocks are copied while the VM is running. If the
guest agent is enabled (`agent: 1`) and running, it calls
`guest-fsfreeze-freeze` and `guest-fsfreeze-thaw` to improve
consistency.
-A technical overview of the Proxmox VE live backup for QemuServer can
+A technical overview of the {pve} live backup for QemuServer can
be found online
https://git.proxmox.com/?p=pve-qemu.git;a=blob_plain;f=backup.txt[here].
-NOTE: Proxmox VE live backup provides snapshot-like semantics on any
+NOTE: {pve} live backup provides snapshot-like semantics on any
storage type. It does not require that the underlying storage supports
snapshots. Also please note that since the backups are done via
a background Qemu process, a stopped VM will appear as running for a
additional space to hold the container copy.
+
When the container is on a local file system and the target storage of
-the backup is an NFS server, you should set `--tmpdir` to reside on a
+the backup is an NFS/CIFS server, you should set `--tmpdir` to reside on a
local file system too, as this will result in a many fold performance
improvement. Use of a local `tmpdir` is also required if you want to
backup a local container using ACLs in suspend mode if the backup
directory. The parameter `maxfiles` can be used to specify the
maximum number of backups to keep.
+Backup File Compression
+-----------------------
+
+The backup file can be compressed with one of the following algorithms: `lzo`
+footnote:[Lempel–Ziv–Oberhumer a lossless data compression algorithm
+https://en.wikipedia.org/wiki/Lempel-Ziv-Oberhumer], `gzip` footnote:[gzip -
+based on the DEFLATE algorithm https://en.wikipedia.org/wiki/Gzip] or `zstd`
+footnote:[Zstandard a lossless data compression algorithm
+https://en.wikipedia.org/wiki/Zstandard].
+
+Currently, Zstandard (zstd) is the fastest of these three algorithms.
+Multi-threading is another advantage of zstd over lzo and gzip. Lzo and gzip
+are more widely used and often installed by default.
+
+You can install pigz footnote:[pigz - parallel implementation of gzip
+https://zlib.net/pigz/] as a drop-in replacement for gzip to provide better
+performance due to multi-threading. For pigz & zstd, the amount of
+threads/cores can be adjusted. See the
+xref:vzdump_configuration[configuration options] below.
+
+The extension of the backup file name can usually be used to determine which
+compression algorithm has been used to create the backup.
+
+|===
+|.zst | Zstandard (zstd) compression
+|.gz or .tgz | gzip compression
+|.lzo | lzo compression
+|===
+
+If the backup file name doesn't end with one of the above file extensions, then
+it was not compressed by vzdump.
+
+
[[vzdump_restore]]
Restore
-------
Restoring one or more big backups may need a lot of resources, especially
storage bandwidth for both reading from the backup storage and writing to
-the target storage. This can negatively effect other virtual guest as access
+the target storage. This can negatively affect other virtual guests as access
to storage can get congested.
To avoid this you can set bandwidth limits for a backup job. {pve}
-implements to kinds of limits for restoring and archive:
+implements two kinds of limits for restoring and archive:
* per-restore limit: denotes the maximal amount of bandwidth for
reading from a backup archive
You can use the `--bwlimit <integer>` option from the restore CLI commands
to set up a restore job specific bandwidth limit. Kibit/s is used as unit
-for the limit, this means passing '10240` will limit the read speed of the
+for the limit, this means passing `10240' will limit the read speed of the
backup to 10 MiB/s, ensuring that the rest of the possible storage bandwidth
-is available for the already running virtual guests, and does not impacts
-their operations.
+is available for the already running virtual guests, and thus the backup
+does not impact their operations.
NOTE: You can use `0` for the `bwlimit` parameter to disable all limits for
a specific restore job. This can be helpful if you need to restore a very
-important virtual guest as fast as possible. (Need `Data.Allocate'
+important virtual guest as fast as possible. (Needs `Data.Allocate'
permissions on storage)
Most times your storage's generally available bandwidth stays the same over
per configured storage, this can be done with:
----
-# pvesm set STORAGEID --bwlimit KIBs
+# pvesm set STORAGEID --bwlimit restore=KIBs
----
-
+[[vzdump_configuration]]
Configuration
-------------
projects / pve-docs.git / blobdiff