KVM machines very slow /unreachable during vmtar backup

[jollyscots]

That's the way its been for 22years? Fantastic. Ever think maybe thats precisley the bloody problem?

I made it clear that I accept tar is old and is the reason for twin scan, but future formats could easily do without!

Shit man. Sorry for thinking I know a bit or two about bloody computers.

Pack of arseholes and this is absolutely my last entry.

Good luck with y'all thinking you're the king dicks of virtualisation.

 

[dietmar]

Pack of arseholes and this is absolutely my last entry.

Good luck with y'all thinking you're the king dicks of virtualisation.

OK, I will disable your account now.

 

[e100]

Oh, good catch - just fixed that.

I am using pigz with 4 cores, the patched vmtar seems to work fine not doing a sparse scan when backing up a 200GB LVM Volume:

INFO: Total bytes written: 214748367360 (304.76 MiB/s)
INFO: archive file size: 20.58GB
INFO: Finished Backup of VM 101 (00:11:14)

I am going to put the updated vmtar on a couple of my production 1.9 servers.
After the backups run I can look to see if it reduced the time needed to backup.

 

[e100]

Same backup with old vmtar:

INFO: Total bytes written: 62714525696 (58.01 MiB/s)
INFO: archive file size: 19.93GB
INFO: Finished Backup of VM 101 (00:17:15)

No sparse handeling made for a slightly larger backup but the backup was much faster and used less IO.
So far I am happy with the results of turning off sparse handeling.

 

[e100]

See: https://git.proxmox.com/?p=qemu-server.git;a=summary
What do you think?

Some real world numbers from my production machines:

#2 server:
Old vmtar: 246 Minutes 309.49GB compressed
New vmtar: 223 Minutes 310.23GB compressed
Saved 23 Minutes

#3 server:
Old vmtar: 291 Minutes 182.18GB compressed
New vmtar: 181 Minutes 182.51GB compressed
Saved 110 Minutes