additional space to hold the container copy.
+
When the container is on a local file system and the target storage of
-the backup is an NFS server, you should set `--tmpdir` to reside on a
+the backup is an NFS/CIFS server, you should set `--tmpdir` to reside on a
local file system too, as this will result in a many fold performance
improvement. Use of a local `tmpdir` is also required if you want to
backup a local container using ACLs in suspend mode if the backup
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
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
projects / pve-docs.git / blobdiff