From: Stefan Reiter <s.reiter@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH v2 docs 1/2] vzdump: add section about live-restore
Date: Thu, 22 Apr 2021 14:21:27 +0200 [thread overview]
Message-ID: <20210422122128.26198-1-s.reiter@proxmox.com> (raw)
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Reviewed-by: Dylan Whyte <d.whyte@proxmox.com>
---
v2:
* Incorporate Dylan's review + R-b
Agreed with all suggestions, for both patches :)
vzdump.adoc | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/vzdump.adoc b/vzdump.adoc
index 9453684..b8ea081 100644
--- a/vzdump.adoc
+++ b/vzdump.adoc
@@ -337,6 +337,34 @@ 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 seldomly used data.
+
[[vzdump_configuration]]
Configuration
-------------
--
2.20.1
next reply other threads:[~2021-04-22 12:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-22 12:21 Stefan Reiter [this message]
2021-04-22 12:21 ` [pve-devel] [PATCH v2 docs 2/2] vzdump: add section about single file restore Stefan Reiter
2021-04-24 17:43 ` [pve-devel] applied: " Thomas Lamprecht
2021-04-24 17:43 ` [pve-devel] applied: [PATCH v2 docs 1/2] vzdump: add section about live-restore Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210422122128.26198-1-s.reiter@proxmox.com \
--to=s.reiter@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.