]> git.proxmox.com Git - pve-docs.git/commitdiff
vzdump: fix few typos and polish
authorThomas Lamprecht <t.lamprecht@proxmox.com>
Fri, 23 Mar 2018 07:06:36 +0000 (08:06 +0100)
committerThomas Lamprecht <t.lamprecht@proxmox.com>
Fri, 23 Mar 2018 07:08:09 +0000 (08:08 +0100)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
vzdump.adoc

index 03d6caa60310a10b25b696774573d0bf75473a6f..0461140de480509a551eb9c220d9be7cba2adc35 100644 (file)
@@ -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 <integer>` 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