We have a new Nimble storage array that I am going to create two volumes, VeeamBackup and VeeamReplica
The VeeamBackup volume is presented via iSCSI to our Veeam physical proxy server and formatted ReFS. It is the target for our Veeam backup jobs
The VeeamReplica volume is presented to our VMware setup and is the target for our Veeam replication job
When these volumes are created on the Nimble array I have to choose what Nimble calls a Performance Policy. There is a big list of built in policies or I can create one of my own. This list included a performance policy called "Veeam Backup Repository". This policy has
Compression Enabled
Caching Enabled
For backup and replication jobs is it OK to have compression enabled on the array AND compression enabled on the Veeam job?
On a Nimble array caching is primarily used to increase read performance. I believe there is some reading going on (metadata and change block tracking) during backup and replication jobs. Is having caching enabled on the array volumes used for Veeam backup and replication jobs OK?
If this performance policy is specifically created by HPE to be used for the Veeam repository (judging by its name), then, I suppose, it should be enabled. I'm not sure regarding the volume used as a replication target though. I will try to find out what the compression and caching effectively are in this case and how do they affect performance.
That was my thought as well. On the Nimble array in the drop down menu is the Performance Policy called "Veeam Backup Repository". This leads me to believe that someone from Veeam worked with someone from Nimble to create this policy which has compression and caching enabled. Given the name of "Veeam Backup Repository", the question becomes should compression and caching be enabled for a volume that is used for replication
I went ahead and created the Nimble volume called VeeamBackup and used the built in performance policy "Veeam Backup Repository". I presented it to my Veeam physical proxy server, formatted it as ReFS with 64K cluster size, and pulled it into Veeam as a backup repository. I then switched my two backup jobs to use this new repository. Backup overnight ran just fine.
I am waiting on making the Nimble volume VeeamReplica to find out if the same Performance Policy (Veeam Backup Repository) should be used for it. This performance policy enables compression and caching on the Nimble volume
The document recommends to disable Veeam own compression and deduplication, and to use the Nimble ones instead.
This configuration is optimized for capacity reduction. If you have bottlenecks on the iSCSI connectivity or on the array sequential throughput (very uncommon, but every environment has specific requirements), then you could enable Veeam own compression and deduplication, and disable them on Nimble.
Please note that ReFS does not implement the feature to trigger Nimble space reclamation and a thin volume can use more capacity than expected. NTFS supports space reclamation, but the synthetic full enabled by the ReFS provides so many advantages that make ReFS a better option in comparison to NTFS.
HendersonD wrote: ↑Oct 14, 2020 1:16 pm
I am waiting on making the Nimble volume VeeamReplica to find out if the same Performance Policy (Veeam Backup Repository) should be used for it. This performance policy enables compression and caching on the Nimble volume
In case of replication, just select the 'VMware ESX 5' performance policy, the one you'd select for the source volume.