I've actually tested, limited might I add, as I'm running v6.5 and found even with putting the QOS on the bandwidth it still seems to saturate the network. Have to perfome a seeding and then the replicaiton or the initial replication is going to be hard to push depending on your bandwidth. I've been reading v7 will have better built in dedupe and compression so I'm waiting to upgrade and test that version when it comes out.
CSSMP You can use the Veeam own global bandwidth trottling for that. See Veeam Options Menu or at each Proxy configuration.
v7 dedup didn´t changed at normal backup. normal Compression will use less CPU ressources with v7. Veeam ads own WAN Acceleration for Backup Copy Jobs (will replicate the backed up Veeam Repository VMs to second target on Change block level) which uses Special compression, dynamic block size deduplication, Global Caching (Cached Data are not transfered a second time over WAN link) and Backup File Caching (Backup Files are used for Cache as well).
ArielStu Hard to guess with the written Information why this happened.
=> ReIP. Did you use the Veeam own "Failover" including enabled Network connection? Was it a Windows VM? I think Veeam Support can Analyse and help you to fix that.
=> Slow Performance: Veeam reads only data when a Backup/Replication Job runs. Veeam Backup & Replication do not Change any storage read/write things at the VMs (like VMware own Replication). If all Jobs are not running and you see still problems with performance, I think you have another Problem with your host. You can use 30 Day Trial of Veeam ONE to have a look at disk IO /Latency, Memory and other things. (Memory Ballooning?). Also please contact Veeam Support to anaylse if Veeam sees anything in their logs.