Should I use SnapMirror to Replicate or let Veeam handle it?

[jbarrow.viracoribt]

We're a long time Veeam user but we're new to NetApp. We have been doing replication between two HP P2000 SAN's for a while now but using Veeam only. With the new NetApp it seems as if we could configure SnapMirror to replicate between two NetApp SAN's or let Veeam handle this but what are the pro's and con's of each?

Case: 00996470

[doomi]

Pro SM: less network overhead. Snapmirror only copies changed blocks and also it's also deduplicated. the traffic will be less and the transfer much faster.
Con SM: it needs licenses (either Snapmirror or Snapvault, depends what you want to do. and Flexclone for restores, because of snapshoting)

Pro Veeam: hmm? no extra license needed.
Con Veeam: much more traffic on the network. it will transfer the whole backup...

if you already have the licenses, I would go with Snapmirror.

[dellock6]

Another pro to add to Veeam is that you can group VMs to be replicated by folders, resource pools, or even have a job per single vm. This offers much more flexibility on the scheduling, while SM can be configured only per volume.
An interesting combination however could be to leverage both : veeam can do "snapshots only" backups, that are application consistent NetApp snapshots. With this, you can have consistent copies of VMs into a primary volume without the need to deploy and maintain any agent inside VMs.
Then, you can replicate this snapshot using NetApp technology. This is totally supported in Veeam.

[jbarrow.viracoribt]

We're currently designing a new DR site that will utilize NetApp and possibly Veeam. What's the best way to get Veeam involved in this discussion so we can see how the product fits into our needs or grand design?

[Gostev]

Con Veeam: much more traffic on the network. it will transfer the whole backup...

Not really, actually Veeam is forever-incremental as well, and only transfers changed blocks.

[jbarrow.viracoribt]

My primary volume has Deduplication and Compression enabled. This gives me a hefty 56% space savings when combined.



I'm assuming that with SnapMirror, it's going to be replicating this pre-deduped and pre-compressed data which would save me in transmission time.

Now, If I didn't use SnapMirror and wanted to use Veeam instead, I would simply have an empty LUN on the remtote (DR) site where the replication job would be configured to dump the data. When the job runs and it reads the data off the production LUN, I'm guessing that it would be processing the non-deduped and non-compressed data, which it would then dedupe and compress itself using Veeam algorithms, then transfer it to the remote site.

Is that a good understanding of how this would work?

[Gostev]

Yes, you are absolutely correct.

[jbarrow.viracoribt]

Yes, you are absolutely correct.

So it sounds like using SnapMirror for replication (the engine at least) is the way to go, but I could still leverage Veeam as my tool to peek into these snapshots and recover full VM's or individual files from those VM's right? I don't think a tool like that exists from NetApp when it comes to pulling individual VM's or files out of a specific snapshot, at least when it comes to SnapMirror. Now maybe SnapVault would have this but our goal is to use replication and many levels of history as sort of a replacement for traditional backup methods as they are just too slow to recover from (download, uncompress, inject, boot up, etc). So I still think Veeam has value here but would be used more as a front end recovery tool right?

Thanks for the help here, it's really helped me understand how the two products work together.

[Gostev]

So it sounds like using SnapMirror for replication (the engine at least) is the way to go.

Well, while it is ultimately up to you to make the choice, note that there is a number of additional considerations here as well that we did not start discussing yet

For example, with storage based replication, your data effectively remains in the same fault domain (because bad data replicates just as well as good data). While Veeam replicaion jobs will provide "galvanic isolation" so to speak (by "breaking" direct data path). I've lost count of times when Veeam jobs were able to determine storage-level corruption due to failing to backup or replicate some VM, whereas storage-based replication had no issues with those.

I don't even have to look too far - sitting in my inbox right now is the most recent story from our systems engineer in the internal Chatter thread:

Yesterday I visited a customer where I talked about the 3-2-1 rule and I gave him data corruption example 2 of @[Anton Gostev] (without naming DataDomain). Then he said: yes, I had a similar situation: "when I tested Veeam, I could not backup one of our VMs". Then he tried storage VMotion which also failed for that VM. To come back to our discussion: That VM was backed up by SnapMirror or SnapVault (do not remember as he uses both) without any errors. He would have never found out that he is copying a broken VM data without Veeam.

Besides, Veeam provides lots of advanced functionality you will not get from storage based replication, such as VM-level granularity, Failover Plans, 1-click Failovers, re-IP, failover testing, WAN acceleration and so on (and while not all features are important to everyone, I am sure most people will find at least a couple of those which do make big difference for their specific case).

But then again, storage replication has its own benefits that are really hard to beat (such as low impact on production workload and better RPO at scale). And in some scenarios, it is truly the only way to achieve certain requirements.

So, the choice may not be as obvious at it may seem... good luck

[jbarrow.viracoribt]

Thanks for the reply here, good info.

Our organization really has a big focus on the RPO. They want our new datacenter we're building/designing to be as close to production as possible within the shortest period of time possible. So if the sprinkler system fires off at our main site or it's wiped out by a tornado, we can flip over to the dr site and not loose much data (they want it within an hour). I do see advantages to Veeam as you mentioned but having it handle the replication does not seem ideal to me at this time. Primarily because of the loss of the deduped, compressed data that would have to be deduped and compressed again because the two engines don't talk at a level that would allow Veeam to sort of utilize the work the NetApp has already done in that regard. I'm still trying to figure out how to best use both products together in our environment so this discussion has been quite helpful to me.

[Butha]

Hi,

Been using NetApp for about 2 years now - and Veeam for quite a few more - Quite a long reply below - apologies for that - but hopefully it's useful! I'm talking about a few things - please ignore/skip the ones that don't apply.

Back to the question:
There is so many things to take into account - I'll try and elaborate a bit below - please ignore any info that you might have already. I'm not sure how well you know Veeam and if you are using it at the moment for replication/DR/Failover etc - or if Veeam is also new to you.. bare with me.

The short answer: Veeam and NetApp compliment each other greatly - so use both! - The trick is in the "how to" portion - and there isn't really a guide that will tell you.

A few basics (some mentioned already)

The reason I love Veeam and use it is because of the management, reporting etc. Anton already mentioned all the benefits that Replication gives you (regardless of SnapMirror or San-Based replication technologies) - and they are all true. I'm going to split the Veeam product in two parts for my explanation: Backup and Replication. This reply focuses on the replication portion mainly - as that is where snapmirror really plays.

Lets list some requirements for Netapp first - snapmirror/snapvault specific: (Not required for normal " snapshot integration -A bit on that right at the end as a "plan B")

You don't mention which Netapp's you are running, and I'm assuming you are using Netapp at both production and your "DR" site - as is required for snapmirror between two sites - but regardless of model:

If you are on 7-mode you require:

1. Snapmirror Licenses (and Snapvault if you want to use it)
2. Flexclone license (If you want your storage snapshot to be our primary copy and being able to restore from it - not required if your primary backup target is normal on disk)

If you are on C-Mode:
1. Snapmirror (and Snapvault if you want to use it)

Reason for mentioning it: On the bigger Netapp's these licenses can be very expensive to add afterwards.

Now a basic explanation of the tech (especially if you are coming from another storage vendor) - you don't mention if you are on Fibre/iscsi or NFS - but regardless:
In Netapp terms you have an aggregate - which is the collection of all you physical spindles into a logical group for lack of a better word (these would be "raid groups" or "disk pools" in EMC/Dell speak) (Some Netapp experts will surely describe this differently! ) - then you have Volumes and exports ("luns" ) - and these are what is mounted in Vmware as a datastores. You will obviously have a few - but to simplify - you might have 3 volumes - say 15Tb each - and thus 3 datastores in Vmware hosting your VM's.

San-base replication (Snapmirror as example) replicates the complete volume between source and target SAN - so you need to make sure the VM and all it's virtual disks are either on the same datastore - or if split (for example you might have a SQL server with some vdisks on one volume and other vdisks on another (SQL backups for example on a SATA volume) ) you need to have ALL the volumes included in the replication job to the other side. You also require at least the same size or larger of the source volume on the target Netapp. So if your production volume is a VMware datastore of say 15TB - you need a 15TB datastore at DR. (The DR does not have to be the same TYPE of disk - just size) (Some installs have very large production storage with large volumes - but much smaller at the backup/DR site) Snapmirror as a configuration of what is included, how often it runs etc are all done on the Netapp - the "integration" portion of Veeam (In version 8 at least - more on Version 9 later) simply sends the command to Netapp to perform another snapmirror sync. So there is a lot of logic around replications schedules for Snapmirror that is outside of Veeam. (Netapp vendor has to explain this - first prize is a vendor that understands/knows Veeam well)

Reason this is important is because you might move (SVmotion) VM's and/or their virtual disks around between datastores - so if you only replicated the first volume with snapmirror (with all the vm's or "parts" of vm's that reside on it) - you might no longer have your vm at your target side as it was moved on the source side. Using Veeam to replicate obviously negates this - as you do only the individual VM's - regardless if they move around.

Using Veeam for replication allows all the features around re-IP - failover plans etc that was mentioned before, where snapmirror only creates "read only" copies on the other side - the vm's are not in Vcentre and you need a little bit of manual work to mount them for testing, or failover. For a few VM's - no problem, but for many VM's and custom networking/"auto one click failover" type scenarios - not ideal - Veeam is much better. Using Veeam does create a scenario where you only have " critical/required" VM's at DR - and often a lot of "other/dev" ones not - wouldn't it be great to have everything there? (read on..)

A little bit of Veeam best practice next:

Replication should ideally be split away from your Backup install - if Replication is used to create copies at your DR site only - the best practice as far as I'm aware is to have your "replication" server installed AT the DR/Target side, and have the jobs setup to "pull" from production to your DR site - and not "push" from your Production site like I many installs ( We all did it - first installed veeam for backup, then later added replication - was easy to use the same install) - reasons are quite obvious - if your production site fails - how would you initiate you failover plans automatically with all the custom re-ip etc if the veeam server is unavailable? So if you have it all on one box - start planning to migrate your Replication to it's own install at your DR side - it's quite easy to do.

Which brings be back to "how":

A requested feature for a while now is to be able to use a snapmirror copy as a source for backup and replication - and I know it's been documented that "Backup from Snapmirror" will be in V9 - and I don't see why "replicate from snapmirror" won't be there (to be confirmed of course first by Veeam) - What you would then do is the following:

Setup Snapmirror between Production and DR - and set whatever schedule you want (say hourly) - make sure your volumes and where VM's/Production lives are well documented - or simply replicate all volumes - remember the incremental snapmirror copies are very small - and you might have hourly snapmirror syncs that roll on a daily basis - if Snapmirror is configured nicely - you might have say 2x complete volumes (Which should have all production VM's as well as whatever was on it - perhaps all dev boxes) at your DR site. You could use Veeam to initiate this snapmirror so that you can configure the replication in sequence -or just use Netapp to say do hourly syncs but not between 07:00-10:00 pm and configure veeam replication to start at 07:30pm - which would then use replicated snapmirror volumes AT DR as SOURCE and only select the actual VM's you need and replicated them to VM storage - and keep all the re-ip, re-network, failover plans functionality in tact. (Almost like a "backup copy" job) Yes, you would need storage for this as you are essentially creating a copy of the VM in full - but you need the same storage anyways if you were replicating them from production with Veeam on it's own.

The advantages in my mind:
1. San-Based replication in isolation is much quicker than software/vmware based ones
2. San-Based replication includes ALL VM's on the source volumes (in a real disaster you often miss one or two of those " not really required - but would have been nice to have them" )
3. San-Based - absolute no impact on production side - no vmware snapshots
4. Being able to use your target snapmirror as a source for replications means no Veeam replication over the wan line - it becomes a local copy at your DR side only.
5. Still having all the management features that makes Veeam Replication so superior (Failover plans, Re-ip/Network - custom scripts etc etc)

You therefore use Snapmirror to replicate to DR much faster - and you use Veeam to manage our failover plans, etc at your DR site.

Keep in mind the setup above assumes "replication from snapmirror" to be available in V9 - and thus not possible right now with V8. At the moment the snapmirror integration in my mind is just there to be able to use Veeam as the "scheduler" to initiate a sync - the target copies are not really useable from a Veeam perspective, and you cannot add them snapmirror copies into DR plans etc.

Lastly perhaps a comment or a "plan B" - for two reasons - Version 9 is still some time away and you might not have the licenses in place and don't want to spend the amounts required at this point.

You would be using snapshot integration which is available out the box from Netapp with no additional license - and all this gives you is to be able to use the Netapp Snapshot as a source for backups and replication jobs - the main advantage (especially large VM's) - no extended vmware snapshots on production VM's. Not sure if you have seen this in action yet but bascially Veeam initiates a vmware snapshot - then a storage based one, and a minute or so later deletes the vmware snapshot and then reads from the san based one as source. So your production VM is only in a vmware snapshot state for about 2 minutes. This is true for backup and replication - note that your backup targets are still veeam files on disk, and your replication targets are still full .VMDK files on Datastores in Vmware. One slight issue - you cannot use a storage snapshot as a source for backup copy jobs - you need the source on disk first. (This might change in V9)

Plan B still a big advantage over traditional snapshots - and definitely worth it even without Snapmirror - But if you have snapmirror, and V9 delivers (as I'm sure it will) it will be a great addition to not only begin able to have much more of your production data at your DR site due to efficiency of san-based replication, but you can also keep all the great features that Veeam Replication gives you.

Hope it makes some sense! Please ask me if anything is unclear - or if you want some more info/examples on how I do it at the moment - I'll gladly share what I know

B

[socra]

Wow Buta, so far your post has been the most helpful in helping us to determine how to use Veeam with Netapp in the best possible way.

Will try to contact you fur sure if the forum software will let me

[socra]

@Anton Gostev,
Your comments with regards to the data corruption has got me thinking.
What in your opinion is the added value of the NetApp integration into Veeam if you consider that leveraging Veeam to do NetApp snapshots doesn't protect us from data corruption?
Will it be possible to create .vbk backups from NetApp Snapvault in V9? (which would then make the integration very powerful)

[veremin]

Will it be possible to create .vbk backups from NetApp Snapvault in V9?

Correct.

[Butha]

@v.Eremin
That is fantastic news!

Talk about "disruptive"

B

[jbarrow.viracoribt]

You don't mention which Netapp's you are running
you don't mention if you are on Fibre/iscsi or NFS - but regardless

First off, you're a stud. Thank you so much for this detailed reply, it was very helpful.

We have NetApp FAS8020's with full SnapMirror/SnapVault licenses at both DR and Production sites.
We are using Fibre Channel.

[Butha]

@jbarrow

Only a pleasure -

Hope you have a nice design in place with the new kit.

With V9 it will absolutely change the way things work - cannot wait for it!

B

[mattiamigliorati]

@Butha

Such a great considerations, I bear them all
I still have to see the Veeam functionality of backup from storage snapshots