Nick Dyer

Stop Caching & Compressing Your Backup Repository!

Blog Post created by Nick Dyer Employee on Mar 4, 2015

Hello all,


I thought i'd write a quick blog post based on a recent observation i've seen across my customers when performing Infosight analysis; the subject today is using Nimble Storage for Backup Repositories.


When creating a backup repository (from the likes of Veeam, Commvault, Symantec etc) there are few things to watch out for in order to ensure performance is kept the same for other workloads on the array.


Nowadays, host side backup tools as mentioned above have built in data reduction technologies such as deduplication and compression, which is performed on the proxy server before being sent to the repository.


However the trend i've seen recently is the repository is given a standard Application Policy on the Nimble array, or a policy which has caching and compression enabled. The problems that have arisen from this are:


  1. The backup repository is being placed into SSD cache - something which shouldn't be done as the backup data is rarely read back.
  2. The array is attempting to compress the backup repository as data is being written, however this data is already compressed at source, meaning CPU cycles are being burnt for no gain on the array itself.


Here's an example taken from Infosight (customer data removed). Four backup repositories are created (one for each country), yet each volume is being cached (one at 95%!).


Screen Shot 2015-03-04 at 11.51.132.png


This is because the volumes have been allocated a policy called "Veeam", which has compression AND caching enabled. Notice the Compression stat at 0.97x, which is 0% reduction.


Screen Shot 2015-03-04 at 11.51.36.png


This in turn started to burn CPU cycles and cache (notice the CPU and cache increase from the end of December onwards, when this was configured).


Screen Shot 2015-03-04 at 11.50.35.png

To rectify this issue, create a new policy - I created one called Backup-Repository. I kept it at 4KB, however I turned OFF compression (as it's being compressed at source) and caching (as I don't want to serve backup data through flash cache).

Screen Shot 2015-03-04 at 12.19.45.png

I can then change the Application Policy allocation on the fly for any already created volumes on the array, and any new data being written to the system will a) NOT be compressed and b) NOT be cached. Exactly what we want!


Screen Shot 2015-03-04 at 12.32.04.png


Hope this is useful to you all. We've also just released a new Best Practice Guide which focuses specifically on Veeam Backup & Replication, which is available to download here: