to include the mount point in the backup. Device and bind mounts are never
backed up as their content is managed outside the {pve} storage library.
+VM Backup Fleecing
+~~~~~~~~~~~~~~~~~~
+
+When a backup for a VM is started, QEMU will install a "copy-before-write"
+filter in its block layer. This filter ensures that upon new guest writes, old
+data still needed for the backup is sent to the backup target first. The guest
+write blocks until this operation is finished so guest IO to not-yet-backed-up
+sectors will be limited by the speed of the backup target.
+
+With backup fleecing, such old data is cached in a fleecing image rather than
+sent directly to the backup target. This can help guest IO performance and even
+prevent hangs in certain scenarios, at the cost of requiring more storage space.
+Use e.g. `vzdump 123 --fleecing enabled=1,storage=local-lvm` to enable backup
+fleecing, with fleecing images created on the storage `local-lvm`.
+
+The fleecing storage should be a fast local storage, with thin provisioning and
+discard support. Examples are LVM-thin, RBD, ZFS with `sparse 1` in the storage
+configuration, many file-based storages. Ideally, the fleecing storage is a
+dedicated storage, so it running full will not affect other guests and just fail
+the backup. Parts of the fleecing image that have been backed up will be
+discarded to try and keep the space usage low.
+
+For file-based storages that do not support discard (e.g. NFS before version
+4.2), you should set `preallocation off` in the storage configuration. In
+combination with `qcow2` (used automatically as the format for the fleecing
+image when the storage supports it), this has the advantage that already
+allocated parts of the image can be re-used later, which can still help save
+quite a bit of space.
+
+WARNING: On a storage that's not thinly provisioned, e.g. LVM or ZFS without the
+`sparse` option, the full size of the original disk needs to be reserved for the
+fleecing image up-front. On a thinly provisioned storage, the fleecing image can
+grow to the same size as the original image only if the guest re-writes a whole
+disk while the backup is busy with another disk.
+
Backup File Names
-----------------
Backup Jobs
-----------
+[thumbnail="screenshot/gui-cluster-backup-overview.png"]
+
Besides triggering a backup manually, you can also setup periodic jobs that
backup all, or a selection of virtual guest to a storage. You can manage the
jobs in the UI under 'Datacenter' -> 'Backup' or via the `/cluster/backup` API
endpoint. Both will generate job entries in `/etc/pve/jobs.cfg`, which are
parsed and executed by the `pvescheduler` daemon.
+[thumbnail="screenshot/gui-cluster-backup-edit-01-general.png", float="left"]
+
A job is either configured for all cluster nodes or a specific node, and is
executed according to a given schedule. The format for the schedule is very
similar to `systemd` calendar events, see the
Since scheduled backups miss their execution when the host was offline or the
pvescheduler was disabled during the scheduled time, it is possible to configure
-the behaviour for catching up. By enabling the `Repeat missed` option
-(`repeat-missed` in the config), you can tell the scheduler that it should run
-missed jobs as soon as possible.
-
-There are a few settings for tuning backup performance not exposed in the UI.
-The most notable is `bwlimit` for limiting IO bandwidth. The amount of threads
-used for the compressor can be controlled with the `pigz` (replacing `gzip`),
-respectively, `zstd` setting. Furthermore, there are `ionice` and, as part of
+the behaviour for catching up. By enabling the `Repeat missed` option (in the
+'Advanced' tab in the UI, `repeat-missed` in the config), you can tell the
+scheduler that it should run missed jobs as soon as possible.
+
+[thumbnail="screenshot/gui-cluster-backup-edit-04-advanced.png"]
+
+There are a few settings for tuning backup performance (some of which are
+exposed in the 'Advanced' tab in the UI). The most notable is `bwlimit` for
+limiting IO bandwidth. The amount of threads used for the compressor can be
+controlled with the `pigz` (replacing `gzip`), respectively, `zstd` setting.
+Furthermore, there are `ionice` (when the BFQ scheduler is used) and, as part of
the `performance` setting, `max-workers` (affects VM backups only) and
`pbs-entries-max` (affects container backups only). See the
xref:vzdump_configuration[configuration options] for details.
----------------
With the `prune-backups` option you can specify which backups you want to keep
-in a flexible manner. The following retention options are available:
+in a flexible manner.
+
+[thumbnail="screenshot/gui-cluster-backup-edit-02-retention.png"]
+
+The following retention options are available:
`keep-all <boolean>` ::
Keep all backups. If this is `true`, no other options can be set.
You can add notes to backups using the 'Edit Notes' button in the UI or via the
storage content API.
+[thumbnail="screenshot/gui-cluster-backup-edit-03-template.png"]
+
It is also possible to specify a template for generating notes dynamically for
a backup job and for manual backup. The template string can contain variables,
surrounded by two curly braces, which will be replaced by the corresponding
# vzdump 777 --mode suspend
Backup all guest systems and send notification mails to root and admin.
+Due to `mailto` being set and `notification-mode` being set to `auto` by
+default, the notification mails are sent via the system's `sendmail`
+command instead of the notification system.
# vzdump --all --mode suspend --mailto root --mailto admin
-Backup guest 777 and notify via the `notify-admins` notification target on
-failure.
-
- # vzdump 777 --notification-target notify-admins --notification-policy failure
-
Use snapshot mode (no downtime) and non-default dump directory.
# vzdump 777 --dumpdir /mnt/backup --mode snapshot
ifdef::manvolnum[]
include::pve-copyright.adoc[]
endif::manvolnum[]
-
projects / pve-docs.git / blobdiff