]> git.proxmox.com Git - pve-docs.git/blobdiff - vzdump.adoc
backup: clarify that CLI means FS-level and highlight retention-note
[pve-docs.git] / vzdump.adoc
index 94536849c206e2e9169731d541a10093df5b086a..b9dca2acf8e2e59c55ce560706a5deda27fe105e 100644 (file)
@@ -49,7 +49,10 @@ archiving.
 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.
+the GUI, which will generate a job entry in /etc/pve/jobs.cfg, which
+will in turn be parsed and executed by the `pvescheduler` daemon.
+These jobs use the xref:chapter_calendar_events[calendar events] for
+defining the schedule.
 
 Backup modes
 ------------
@@ -281,6 +284,23 @@ We recommend that you use a higher retention period than is minimally required
 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).
+
 [[vzdump_restore]]
 Restore
 -------
@@ -337,6 +357,58 @@ per configured storage, this can be done with:
 # pvesm set STORAGEID --bwlimit restore=KIBs
 ----
 
+Live-Restore
+~~~~~~~~~~~~
+
+Restoring a large backup can take a long time, in which a guest is still
+unavailable. For VM backups stored on a Proxmox Backup Server, this wait
+time can be mitigated using the live-restore option.
+
+Enabling live-restore via either the checkbox in the GUI or the `--live-restore`
+argument of `qmrestore` causes the VM to start as soon as the restore
+begins. Data is copied in the background, prioritizing chunks that the VM is
+actively accessing.
+
+Note that this comes with two caveats:
+
+* During live-restore, the VM will operate with limited disk read speeds, as
+  data has to be loaded from the backup server (once loaded, it is immediately
+  available on the destination storage however, so accessing data twice only
+  incurs the penalty the first time). Write speeds are largely unaffected.
+* If the live-restore fails for any reason, the VM will be left in an
+  undefined state - that is, not all data might have been copied from the
+  backup, and it is _most likely_ not possible to keep any data that was written
+  during the failed restore operation.
+
+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 seldom used data.
+
+Single File Restore
+~~~~~~~~~~~~~~~~~~~
+
+The 'File Restore' button in the 'Backups' tab of the storage GUI can be used to
+open a file browser directly on the data contained in a backup. This feature
+is only available for backups on a Proxmox Backup Server.
+
+For containers, the first layer of the file tree shows all included 'pxar'
+archives, which can be opened and browsed freely. For VMs, the first layer shows
+contained drive images, which can be opened to reveal a list of supported
+storage technologies found on the drive. In the most basic case, this will be an
+entry called 'part', representing a partition table, which contains entries for
+each partition found on the drive. Note that for VMs, not all data might be
+accessible (unsupported guest file systems, storage technologies, etc...).
+
+Files and directories can be downloaded using the 'Download' button, the latter
+being compressed into a zip archive on the fly.
+
+To enable secure access to VM images, which might contain untrusted data, a
+temporary VM (not visible as a guest) is started. This does not mean that data
+downloaded from such an archive is inherently safe, but it avoids exposing the
+hypervisor system to danger. The VM will stop itself after a timeout. This
+entire process happens transparently from a user's point of view.
+
 [[vzdump_configuration]]
 Configuration
 -------------
@@ -397,7 +469,7 @@ but will match relative to any subdirectory. For example:
 
  # vzdump 777 --exclude-path bar
 
-excludes any file or directoy named `/bar`, `/var/bar`, `/var/foo/bar`, and
+excludes any file or directory named `/bar`, `/var/bar`, `/var/foo/bar`, and
 so on, but not `/bar2`.
 
 Configuration files are also stored inside the backup archive