Veeam B&R 6.5 and Windows Server 2012 Dedup - part II

This is part II of my Veeam B&R in conjunction with dedup feature of Windows Server 2012.

This time I will try to figure out, if using dedup on the Veeam backup storage only as advantages or if there are some stumbling blocks.

The first thing to have a look at is the recover speed if you have to use deduped backup files. Will the rehydration of the dedupoed data have any influence on the recover speed?

To evaluate this, I made two simple tests: first I used Instant Recovery feature of Veeam to start my two backed up VMs from the backup storage. Since one VM is on deduped storage and one on non-deduped storage, there should be some difference in boot behavior/time and also in using the VM.

Secondly I used StorageVMotion to migrate both VMs back to the SAN storage. This time, all data is read and written back to the primary storage. There should have been some difference in CPU load, transfer speed etc. on the backup server.

 

Going back to the first test. Starting both VMs from instant recovery NFS storage. Both VMs needed nearly the same time to get up from scratch. So regarding the read speed, deduped storage is nearly as fast as non-deduped. Writes are committed to the NFS store as well ( I didn't use redirection to VMFS) but have the same impact for both VMs since the dedup is not done inline. So all writes to the NFS store are non-deduped for both VMs.

The general use of the VM running either from deduped or non-deduped storage didn't show any big differences. Both VMs were reactive to tasks and copy jobs to and from the VM were nearly identical.

So until now, no difference.

 

Let's look at test number 2, the SVMotion. In this test, all VM data has to be read and transferred. For the deduped space this means that the data has to be rehydrated first and then sent over the wire. Rehydration needs I/O and CPU power so it possibly has some impact on the SVMotion speed.

The deduped VM was transferred in ~30min with an average load on the LAN of ~600MBit/s and a CPU load on the backup server of ~30%. The CPU load mainly came from the VeeamNFS service.

The non-deduped VM showed nearly the same behavior. Same time to relocate, same load on the CPUs, same transfer speed.

So in my environment, there was absolutely no negative impact by using deduplication.

 

Here is a first summary what to bear in mind when using Windows Server 2012 deduplication feature with Veeam:

 

  • Windows Server 2012 deduplication is a posponed process that runs in defined intervals
  • Deduplication needs time, fairly CPU and RAM ressources and puts high load on your storage
  • You can achieve massive storage savings when using MS deduplication in conjunction with Veeam
  • Impacts on restore times were not observed during my tests but could have a negative impact in larger installations (especially when dedup job is currently running)
  • MS defines 800GB/hr as maximum data rate for deduplication so don't use dedup for backupservers that max this rate out
  • You should always set the dedup option only for files older than 2 days. This way you will always have the latest backup non-deduped
  • You can use deduplication inside a Windows Server 2012 VM and back it up with Veeam. Single file restore is possible but you have to start the recovery job from a Veeam server that is also a Windows Server 2012 system with deduplication feature enabled
  • Do not enable inline Veeam dedup for VMs already have deduped data inside
  • For best reduction rates, use inline dedup in Veeam AND MS dedup on the backup volume. Use dedup-friendly compression in the backup job

 

Leave your comments

Post comment as a guest

0
Your comments are subjected to administrator's moderation.
  • No comments found
Powered by Komento
joomla templatesfree joomla templatestemplate joomla
2017  v-strange.de   globbers joomla template