Best practices with Netapp?

[doomi]

is there any documentation about the best practice settings with Netapp storage?
I know how to configure the basics, like snapshotting and snapmirror/snapvault transfer.

but what about the advanced settings? I could not find any documentation or white paper about it.
so I have the following questions:

1. as Netapp snapshots are always by volumes, should I add datastores to the backup job instead of VMs? this would make more sense...
are there any drawbacks on this? I noticed, that I cannot select individual VMs anymore in the "Application-Aware Processing Options",
but I don't think that's any different than a standard job.

2. if the backup repository is on a Netapp, should I use "Align backup file data blocks" ? or is this not relevant for Netapp?
(I suppose this setting has been implemented for HP)

3. I've seen that vPowerNFS is using NTFS links to local repositories. so should I use a local repository on the same Windows partition
instead of a CIFS share to get better restore performance? both the CIFS share and the VMDK would be on the same Netapp.
or is there no noticeable performance impact when using a CIFS repository? (network is 10GbE)

4. which storage optimization (block size) should be used on Netapp? Local target, LAN or WAN?
Netapp is always using 4k internally, so this may not have an impact on storage space/dedup rate anyways?
(I know it has an impact on the network performance/throuput).

thanks for you answers!

[dellock6]

Hi Dominic, some answers:
1. there is a limit of concurrent snapshots per datastore when using regular backups, but if you are talking about BfSS, this limit does not apply and we try to consolidate all VM snapshots in that datastore before taking the storage snapshot. There are so no best practices on this other than what you prefer to use. Just don't group too many VMs into the same job belonging to the same datastore, otherwise the job will wait for all vsphere snapshots to be created before the storage snapshot
2. not relevant to NetApp, it's more for deduplication appliances
3. in both cases, vpowerNFS is executed in the configured repository. I'm not sure I've understood the part related to vmdk: the backup file is always mounted from the vpowerNFS service, and exposed as a simulated datastore to the hypervisor, regardless the backup file is stored in a local repository or a CIFS share.
4. you mean when using a NetApp machine as a target? LArger block sizes have better performances because Veeam proxies have to process fewer larger blocks, and also in terms of writing those to the final destination, it means a single write will write a larger block to the storage.

[rennerstefan]

Hi Doomi,

thanks for your post.
As Luca already answered your questions I will add some things in my mind to point 1.

First of all there are two different ways to use our integration. As Luca wrote there is BfSS (Backup from Storage SnapShot) and SnapShot only.
Depending on your Volume/LUN/VM relation you can either choose the datastore or the VMs.
If you have f.e. 50 VMs in a dastasore but you only like to backup 10 of them with BfSS it's better to choose the VMs itselfs.
If you like to backup all it's better to choose the datastore for sure.
As we are using NetApp SnapShots you know that a SnapShot is performed on a Volume level. Meaning when you use SnapShot only option to save a SnapShot on the NetApp it is a common way to group the VMs based on the required backup level in different volumes.
F.e. you can have a volume for Applicaiton-Consistent backups, one for VMware SnapShot Backup and one for Crash-Consistent only to build a easy Datastore based job design.
But you can also say my 50 VMs datastore contains 5 VMs which needs to be Application Consistent so you choose the 5 VMs (or f.e. a VM Tag) and as the whole volume will be snapshottet you have at the end the 5 VMs consistent and the other 45 VMs crash-consistent.

At the end the design depends on your environment and lots of other dependencies.

If you have any question just let us know.

[doomi]

thanks for your answers!

about point 3, I may have to clarify the question:
is there a big performance impact, if the repository is on a CIFS share?
because vpowernfs needs to redirect the incoming nfs request to the cifs share,
instead of just accessing the (hardlinked) local repository (inside the same vmdk).

addon question related to 1:
if I want to backup SQL transaction logs periodically, is there a way to do this with Netapp SnapShot only?
as soon as I select 'Netapp SnapShot only', I don't have anymore the options for periodically sql log backups.
it works when doing BfSS, but I don't like to have the whole VM in the repository. I would like to have
the the VM in the Netapp Snapshot and only the sql logs in the repository.

[dellock6]

3. why you say vmdk? are you going to have the Veeam repository as a virtual machine? In the same netapp you are protecting? if so, bad practice, keep it separated, if you loose the array you've lost both production and backup copies

1. If I remember correctly SQL transaction logs cannot be protected using snapshots only, but thanks for the feedback/feature request.

[rennerstefan]

To 1.:
No right now, SQL Transaction Logs cannot be proceeded with NetApp SnapShot only backups. I will forward the request. Thanks

[doomi]

3. why you say vmdk? are you going to have the Veeam repository as a virtual machine?"

yes. but don't worry, it's on a different Netapp than the production VMs.
and we're using snapshots/vaults by default, this repository would only be for special occasions (like periodic sql log backups).

but you didn't answer my question

[dellock6]

I was waiting first for a clarification about the vmdk

Some amount of additional network traffic can be expected with SMB (don't call if CIFS please...) since indeed datamover is not local to the storage, and in general SMB is a "chatty" protocol, but I've never done extensive tests to be able to tell you how much is this difference. If the repository is a local resource, for sure you are at least saving the network traffic to connect to the remote share.

[doomi]

thanks for the answer.

don't call if CIFS please...)

sorry! I know it's called SMB since a long time now. Netapp's commandline SMB commands are still called cifs, so I'm used to call it CIFS