The importance of testing these backups!

Userlevel 7
Badge +7

I wanted to share with you a customer’s feedback that I encountered. They contacted me to report extremely slow restoration times during a file restoration process.

I was a bit surprise cause I had tested all types of restauration on his infrastructure and everything worked properly.

  • The restore type : “Guest File Restore”
  • OS: Microsoft
  • Restore option: Keep
  • Folder Size : 64 MB
  • Restore Time: 1h30min 😱

I first checked the log in the History

I directly noticed the fact that the restoration is via vSphere guest interaction API and not using a Veeam proxy .
After a brief exchange with the admin, it figured out that the VM to which the files should be restored is in a new Vlan ! You’ve probably guessed it, but it’s once again the fault of the network!

Indeed, the network openings between the Veeam environment and the production environment for this new VLAN have not been set up, after having done the necessary we tried again the restore.

This time, the restore used my proxy and took only few seconds ! 

Understanding how the various components of Veeam communicate with each other is crucial to avoid issues during emergencies. In our case, the restoration was not critical and did not require rapid recovery. However, in a different context, it could have been quite problematic. Hence, regularly testing these backups is essential to ensure compliance with requested Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).



Userlevel 7
Badge +21

Amazing how a new VLAN could cause so much issue for a restore.  Great to see after the changes the restore was much faster.  Thanks for sharing this one Stabz.

Userlevel 7
Badge +9

thanks for sharing the case @Stabz. hahaha it's always the firerwall's fault

Userlevel 7
Badge +2

Thank you for sharing @Stabz ,

Yes, this may not be the problem when not restoring under the pressure, but yes, manual testing is still required to uncover this type of bottleneck.