.Backup Storage
-Before a backup can run, a backup storage must be defined. Refer to
-the Storage documentation on how to add a storage. A backup storage
-must be a file level storage, as backups are stored as regular files.
-In most situations, using a NFS server is a good way to store backups.
-You can save those backups later to a tape drive, for off-site
-archiving.
+Before a backup can run, a backup storage must be defined. Refer to the
+xref:chapter_storage[storage documentation] on how to add a storage. It can
+either be a Proxmox Backup Server storage, where backups are stored as
+de-duplicated chunks and metadata, or a file-level storage, where backups are
+stored as regular files. Using Proxmox Backup Server on a dedicated host is
+recommended, because of its advanced features. Using an NFS server is a good
+alternative. In both cases, you might want to save those backups later to a tape
+drive, for off-site archiving.
.Scheduled Backup
-Backup jobs can be scheduled so that they are executed automatically
-on specific days and times, for selectable nodes and guest systems.
-Configuration of scheduled backups is done at the Datacenter level in
-the GUI, which will generate a cron entry in /etc/cron.d/vzdump.
+Backup jobs can be scheduled so that they are executed automatically on specific
+days and times, for selectable nodes and guest systems. See the
+xref:vzdump_jobs[Backup Jobs] section for more.
-Backup modes
+Backup Modes
------------
There are several ways to provide consistency (option `mode`),
For Proxmox Backup Server storages, you can optionally set up client-side
encryption of backups, see xref:storage_pbs_encryption[the corresponding section.]
+[[vzdump_jobs]]
+Backup Jobs
+-----------
+
+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.
+
+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
+xref:chapter_calendar_events[calendar events] section for details. The
+'Schedule' field in the UI can be freely edited, and it contains several
+examples that can be used as a starting point in its drop-down list.
+
+You can configure job-specific xref:vzdump_retention[retention options]
+overriding those from the storage or node configuration, as well as a
+xref:vzdump_notes[template for notes] for additional information to be saved
+together with the backup.
+
+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 `performance` setting, `max-workers` (affects VM backups only). See the
+xref:vzdump_configuration[configuration options] for details.
+
[[vzdump_retention]]
Backup Retention
----------------
by your environment; you can always reduce it if you find it is unnecessarily
high, but you cannot recreate backups once they have been removed.
+[[vzdump_protection]]
+Backup Protection
+-----------------
+
+You can mark a backup as `protected` to prevent its removal. Attempting to
+remove a protected backup via {pve}'s UI, CLI or API will fail. However, this
+is enforced by {pve} and not the file-system, that means that a manual removal
+of a backup file itself is still possible for anyone with write access to the
+underlying backup storage.
+
+NOTE: Protected backups are ignored by pruning and do not count towards the
+retention settings.
+
+For filesystem-based storages, the protection is implemented via a sentinel file
+`<backup-name>.protected`. For Proxmox Backup Server, it is handled on the
+server side (available since Proxmox Backup Server version 2.1).
+
+Use the storage option `max-protected-backups` to control how many protected
+backups per guest are allowed on the storage. Use `-1` for unlimited. The
+default is unlimited for users with `Datastore.Allocate` privilege and `5` for
+other users.
+
+[[vzdump_notes]]
+Backup Notes
+------------
+
+You can add notes to backups using the 'Edit Notes' button in the UI or via the
+storage content API.
+
+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
+value when the backup is executed.
+
+Currently supported are:
+
+* `{{cluster}}` the cluster name, if any
+* `{{guestname}}` the virtual guest's assigned name
+* `{{node}}` the host name of the node the backup is being created
+* `{{vmid}}` the numerical VMID of the guest
+
+When specified via API or CLI, it needs to be a single line, where newline and
+backslash need to be escaped as literal `\n` and `\\` respectively.
+
[[vzdump_restore]]
Restore
-------
This mode of operation is especially useful for large VMs, where only a small
amount of data is required for initial operation, e.g. web servers - once the OS
and necessary services have been started, the VM is operational, while the
-background task continues copying seldomly used data.
+background task continues copying seldom used data.
Single File Restore
~~~~~~~~~~~~~~~~~~~
projects / pve-docs.git / blobdiff