From 3802f512b9733615ce60d31588fb2d3e13441a0c Mon Sep 17 00:00:00 2001 From: Thomas Lamprecht Date: Fri, 23 Mar 2018 08:06:36 +0100 Subject: [PATCH] vzdump: fix few typos and polish Signed-off-by: Thomas Lamprecht --- vzdump.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/vzdump.adoc b/vzdump.adoc index 03d6caa..0461140 100644 --- a/vzdump.adoc +++ b/vzdump.adoc @@ -170,7 +170,7 @@ the target storage. This can negatively effect other virtual guest 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 @@ -185,14 +185,14 @@ you have `Data.Allocate' permissions on the affected storage. You can use the `--bwlimit ` 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