Veeam & Netapp Best Practices for ASA

[Salzi]

Hi all,

is there a best practice or recommendation in regard of compression settings using a NetApp ASA-C800. (mostly VCenter snapshots over a Hardened repository Server using the NetApp dedupe)
So far i red mostly 2 opinions in regard of compression level.
Either "None" or "Dedupe-friendly"

Tested "Dedupe-friendly" for a smaller Job(~10TB) and it seems to save additional ~1TB. (according to Veeam Job Properties)

I would like to avoid Backup issues due to misconfiguration.

[Andreas Neufert]

The difference is not that relevant in the total picture.

You can run it basically in 3 modes with some variants to it.

Use Veeam Compression (default value) and disable uncompression on the repository to keep the data compressed. Use inline deduplication.
This will reduce the data amount the most upfront before it hits the storage (which increases storage performance by 2x), but later the post dedup processing can not reduce the data a lot additionally as the data is compressed. Use ReFS/XFS with fast cloning option to write tot he storage block volume. The Data reduction as seen on the storage is the worst but in total I think this model works very well as fast performance and relatively large data reduction in total (Veeam + NetApp). That said it will show you the worst data reduction on the NetApp itself as Veeam has done most of the reduction during compression and fast cloning. Use it for fastest performance. It is relatively fair data reduction until your reach 80 restore points long backup chains (the overhead is usally less than 20% there but 2x the performance).

Use Veeam compression dedup friendly and let uncompression on the Repository setting disabled. Dedup-friendly compression will remove removes whitespace only to keep the data friendly for deduplication).
Veeam Inlince Dedup can be enabled or disabled. I recommend it to be enabled.
This will remove whitespace (zeros) from the backup files before it hits the target storage. As well it reduces some additional data with Veeam deduplication upfront. On the other side the data will land uncompressed (besides large areas with zeros) at the backup target (NetApp) and the deduplication can work effectively. Use XFS/ReFS for fast cloning. In total this will be data flow optimized and backup deduplication optimized. Data reduction on the NetApp is shown not ideally as some data is reduced upfront before it hits the NetApp. So the total reduction is still based on a combination of Veeam and NetApp to be calculated. This is a bit better performance from the storage compared with the last solution. I would go with this if you want to do long term backups with chains longer than 80 days.

When you want to see the highest data reduction on the NetApp storage console then use the following:
Enable Compression (default) in the Job
Enable uncompression at the backup target.
Disable fast cloning.
Disable inline deduplication.
This will lead to any backup data be transported to the target storage and the target storage can deduplicate it as much as it is capable to. As shared this comes with a performance impact as the target storage has to handle more data as needed, just to "show" in the console the higher deduplication values.
I would not recommend to use this unless you have to justify the investment by showing off data reduction values at a single console.

[Salzi]

Thank you for all the input.

We are looking for the best mix between storage efficiency and performance.
We were told to not use the Veeam dedup(inline deduplication) to max out the NetApp dedupe efficiency. (for the best efficiency)
Maybe this was to meet the NetApp dedupe ratio to get disks delivered. (remediation - don't know the contract)
But with your explanations, it seems option 1 or 2 are most fitting for us.

Are there any benchmarks for whats best?
Veeam dedupe + compression + NetApp dedup
only Veeam dedupe + compression
only NetApp dedupe + compression
only NetApp dedupe

sry for my confusion.

I guess i try it out by creating 3-4 Jobs with different settings and the same Fileserver(VM).

Does it make any difference how we added the NetApp Storage to Veeam?
This is our config on NetApp side:
- created 6 LUN's a 100TiB
- created 2 Volumes a 300TiB (since NetApp Volumes have a 300TiB Limit)

Hardened Repository:
- the 6 LUN's/Data-Volume are using XFS
- Data-Volumed are configured with multipath

On Veeam side:
- Created Scale-out-repository
- added all 6 LUN's to the Scale-out-repository

[Andreas Neufert]

I would say the setup is ideal from performance and best practices.
Always prefer block over SMB/NFS.

Performance depends on data amount that you send to the storage.
If you allow Veeam to reduce the data with compression, then the storage has to only process half or less of the data, means if the target storage is the bottleneck, your backups can run twice as fast.

Same for Veeam Inline Dedup and Compression in Dedup friendly mode, it will reduce the data (not that high as compression) so that you have less to process on the storage. In this case the storage can fully dedup the data (no real compression used).

In total yes, when you disable compression and Veeam inline dedup, then the data reduction is better on the storage, but as you need to process twice amount the data, the performance is less.
But in the end you will likely have the same amount of data on real disk consumption after deduplication in most of the cases (beside the one that you use compression).

Yes, do some testing to see how it goes and check as well on the bottleneck analyze in the job statistics. If your source is the bottleneck in all cases, then you might want to go with the uncompressed backup method to have better deduplication on the storage.

[Salzi]

Did some Testing.
I know it's not 100% accurate. (There are other Jobs running, VCenter Storage has different load, etc.)
NetApp dedupe may affect the backup size since it's the same volume the jobs writing to.
And the test jobs are containing the same 3 VM's

Do you have some recommendations with this data?



Is the "Backup size", given by veeam backup properties, accurate?
Or can i only get valid data direct from the repository server?
Referring to the really used space on disk/volume.

[Andreas Neufert]

Backup Size is what we store in the backup target. The backup target does in your case some additional compression and or deduplication.

You see from the numbers, that with dedup friendly compression we remove 18GB of whitespace (zeros) from the backup data before the storage can deduplicate the backups on the storage without issues.

You can see as well on the numbers that the bottleneck is likely your source storage (primary storage under VMware) not the backup target. So you can go with the second option in your list without issues.

Veeam inline deduplication advantages are usually only come to play when you do incremental processing over time, this is why you do not see so much effect from it here.