Since we upgraded our main Veeam server to version 13, the “Migrate to production” phase of Instant Recovery has become roughly 2.5× slower compared to version 12.3.
We first noticed this when migrating VMs that we had migrated before the upgrade and then again shortly after upgrading. We use vMotion, as it gives us shorter downtime for the VMs being migrated. However, when we check the “Force Veeam transport usage” option in the Quick Migration wizard, the migration completes much faster.
To confirm whether the slowdown was related to the v13 upgrade, we set up a VBR v12 server on the same network as the v13 server and ran Instant Recovery + Migration tests using:
A backup of the same VM
A repository on the same underlying storage
Windows proxies on the same network
The same target host and datastore on the same vCenter
Both VBR servers running as VMs on the same Proxmox hypervisor
In short, we kept everything identical except for the Veeam version.
Version 13 consistently ran about 2.5× slower than our test VBR 12 server.
Monitoring the proxy during migration shows significantly higher network throughput on v12.3, which correlates with better performance. General backup speeds remain similar to pre-upgrade levels.
Veeam Support insists this is a vMotion-related issue (case ID: 07986725), but that seems unlikely given our testing. I wanted to check whether anyone else has experienced this behavior on v13.
-
Aggi
- Service Provider
- Posts: 5
- Liked: never
- Joined: Sep 20, 2012 11:22 am
- Full Name: Agnar Arason
- Contact:
-
david.domask
- Product Manager
- Posts: 3455
- Liked: 831 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Migrate to production phase of Instant recovery slower since upgrade to v13
Hi Agnar,
Thank you for sharing the case number and details, and sorry to hear about the challenges.
Not aware of any issue that match this specific , and while Veeam Support is correct that the ultimate speed of vMotion is outside of Veeam's control, the discrepancy found in your testing is a bit unusual.
Please continue with Veeam Support on the case, and will discuss internally as well.
Thank you for sharing the case number and details, and sorry to hear about the challenges.
Not aware of any issue that match this specific , and while Veeam Support is correct that the ultimate speed of vMotion is outside of Veeam's control, the discrepancy found in your testing is a bit unusual.
Please continue with Veeam Support on the case, and will discuss internally as well.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Semrush [Bot] and 26 guests