mirror of
https://github.com/borgbackup/borg.git
synced 2024-12-24 08:45:13 +00:00
virtualisation speed tips
This commit is contained in:
parent
b59230380f
commit
18c398e708
1 changed files with 16 additions and 0 deletions
16
docs/faq.rst
16
docs/faq.rst
|
@ -989,6 +989,22 @@ Then you do the backup and look at the log output:
|
||||||
You can use the ``stat`` command on files to manually look at fs metadata to debug if
|
You can use the ``stat`` command on files to manually look at fs metadata to debug if
|
||||||
there is any unexpected change triggering the ``M`` status.
|
there is any unexpected change triggering the ``M`` status.
|
||||||
|
|
||||||
|
When borg runs inside a virtual machine, there are some more things to look at:
|
||||||
|
|
||||||
|
Some hypervisors (e.g. kvm on proxmox) give some broadly compatible CPU type to the
|
||||||
|
VM (usually to ease migration between VM hosts of potentially different hardware CPUs).
|
||||||
|
|
||||||
|
It is broadly compatible because they leave away modern CPU features that could be
|
||||||
|
not present in older or other CPUs, e.g. hardware acceleration for AES crypto, for
|
||||||
|
sha2 hashes, for (P)CLMUL(QDQ) computations useful for crc32.
|
||||||
|
|
||||||
|
So, basically you pay for compatibility with bad performance. If you prefer better
|
||||||
|
performance, you should try to expose the host CPU's misc. hw acceleration features
|
||||||
|
to the VM which runs borg.
|
||||||
|
|
||||||
|
On Linux, check ``/proc/cpuinfo`` for the CPU flags inside the VM.
|
||||||
|
For kvm check the docs about "Host model" and "Host passthrough".
|
||||||
|
|
||||||
See also the next few FAQ entries for more details.
|
See also the next few FAQ entries for more details.
|
||||||
|
|
||||||
.. _a_status_oddity:
|
.. _a_status_oddity:
|
||||||
|
|
Loading…
Reference in a new issue