PVE version, as restore is PVE side.
PVE 8.4 require updates to allow "Restoring from Proxmox Backup Server now fetches multiple chunks concurrently in each worker thread.
This can improve the restore performance in setups with fast network...
After you discover how it works under the hood, you will follow the recommended way : Local PBS then WAN PBS Remote Sync from.
Give a try , I bet on no more QEMU guest agent stopped with a local PBS.
Root cause isn't QEMU guest agent itself, others services can fail too.
I'd had same problem with too slow HDD on PBS side.
Too slow PBS impacts source guest activity , timeout up to crash
( see simulated example here )
Fleecing is mandatory for...
I did a quick test to reproduce this backup "hang" issue, and the results are pretty clear. It seems Backup Fleecing is exactly what we need for these kinds of bottlenecks.
My test setup:I tried to simulate a "worst-case scenario" with a...
again, sorry for my english wording...
Do you get the point of "Stop mode" backup ?
"Stop mode" backup is still "live".
Fleecing option is mandatory to mitigate.
https://forum.proxmox.com/threads/backup-sync-performance-over-vpn.164450/post-835072
Update:
after a bit of research I think that the error in the dmesg logs has little if anything to do with the issue I described.
Thats related to a bug (?) of the i40e driver, as I understand it: at first the interface tries to filter the vlan...
if downtime isn't critical, if whole reading source isn't too long, the safest is
schedule shutdown guest, then backup offline, then start guest after Backup done using hook script
Reminder : during backup, I/O writes are sent to PBS before within guest itself, it's a "copy-before-write" méthode.
There is fleecing option to mitigate.
it's known issue when PBS is slower than guest I/O usage.
guest is slowdown up to crash some apps if timeout
because snapshot is done when guest is shutdown state, then guest started directly while backup started concurrently.