mirror
/
borg
mirror of https://github.com/borgbackup/borg.git
1
0
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #6588 from ThomasWaldmann/docs-virt-master 

virtualisation speed tips, fixes #6456
This commit is contained in:
TW 2022-04-13 23:08:00 +02:00 committed by GitHub
parent cfb0821006 18c398e708
commit 1b9a49c5c2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
docs/faq.rst
View File

@ -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
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.
.. _a_status_oddity: