What is the difference between VDP and VSC? Which should I use?

[CarIt]

Hello,

Turns out we have a multitude of backup solutions running for our VM environment. We're running vCenter 6.0, VDP 6.1, VSC 6.2P1, SnapManager for SQL and SnapMirror jobs set up in OnCommand 3.1.2.

I'm going insane trying to unravel the necessity of having all these products running backups and snapmirroring the data. Bottom line, our SnapMirrors for one or two particular Volumes take f o r e v e r....And that is impacting my SRM testing (when using Data Replication).

I'm in the process of cleaning up, honing down, consolidating, re-scheduling and fretting about all these solutions. And in the middle of my panic, I thought "Are these all doing essentially the same thing? Snapshotting and SnapMirroring data?"

So, my question to the community is, what is the difference between these solutions, or are they all basically doing the same thing? Are they clashing, vying for bandwidth and stumbling over each other to achieve the same thing? Right now my plan is to suspend all jobs from everything except VSC and SnapManager for SQL, and do all of it from VSC. That means suspending jobs in NetApp's Oncommand.

I am not the admin for VDP, that is my co-worker, so he installed that independently of my work. Is it even necessary?

What led me to all this, besides the failure of SRM to do a data transfer (SnapMirror on demand in a reasonable amount of time) was noting the deltas for our Snapshot jobs are always huge at certain times of the day. For example, our biggest data hog has a Snapshot fire off at midnight, and it is consistently 71GB. That leads me to believe it is a job of some sort, since it's predictable. The net effect is the SnapMirror jobs take days, lag times are several days, and the transfers never really stop.

We are planning on upgrading our pipe between our Protected Site (HQ) and our DR Site (Satellite Office) from 50mbps to 100mbps. We have 100 out of our HQ and 50 into our Satellite right now, so we want them both to be 100. Perhaps that would solve the issue, but I still would rather be efficient.

If you need further details, let me know, and I'll fill you in, or at least make something up so I sound like I know what I'm talking about.

TIA!

Steve

[Nick_Andreev · Accepted solution]

The reason why you're doing SnapMirror replication is DR. This is not a backup solution. If you stop all your SnapMirrors in OnCommand Unified Manager and your storage array at production fails, you no longer have a DR.

What VSC does is, it creates snapshots of your NetApp volumes, which you can use for short-tern backup/recovery. Snapshots are not a true backup solution, though. If someone deletes a volume on the NetApp, snapshots of this volume won't save you as they won't exist anymore. But they are still valuable in many scenarios, such as Microsoft Previous Versions feature for CIFS.

The goal of SnapManager is to perform application consistent snapshots for software such as MS SQL in your case. Basic snapshots won't give you such capability, as they do not trigger VSS quiescing. Plus SnapManager for SQL gives you point in time recovery capability for your databases from SQL transaction logs, which none of the above solutions provide. However, as SnapManager creates snapshots, you need to make sure you have dedicated LUNs for you SQL VM, otherwise you'll be snapshotting the same volumes twice.

And now VDP is what actually does backups in your environment. It supports long term retention, as snapshots generally are not kept for longer than a week or a month maximum. Make sure that data is backed up to a volume separate from where your VMs are. Or ideally to a destination external to your storage array.

Hope that clears things up a bit. The bottom line is, what you have is perfectly fine.

[CarIt]

Hey Nick,

I appreciate the clarification. We're not having the best of luck with VDP and may be considering Veem, but that's a different issue. It looks like I'll need to do some further investigation as the VSC jobs are continuing to run all over each other and that may have something to do with VDP's scheduled jobs throughout the day. I see many of my VSC jobs I set up are failing throughout this morning, stuck at 89%.

Based on what you suggested, I still need to dig deeper and figure out why the snapshots are so large on several of these volumes, as I can't imagine every day we create 71GB of deltas, so I need to figure out the reason behind the large data changes.

Thanks!

Steve

[Nick_Andreev]

For VSC jobs you can see details of why the job has failed. You can configure notifications in the VSC console and when there is an issue, it will send an email with the link to the detailed logs.

If snapshots grow 71GB every day, then you do generate 71GB of deltas. There's just no other reason why that would happen. It's not easy to determine which VM generates the delta, though.

[CarIt]

Exactly. I find it unusual to have that many deltas, even our DB server doesn't process THAT many transactions daily.

If I could throw another question out, based on your info. If VDP is for longer term backup retention, would it make sense to run that less often, say as weekly jobs, and keep our VSC jobs to multiple dailies like they are now? Then I could turn those jobs off on the weekend while VDP does it's thing, and they don't clash. Even so, those VSC jobs (which are instructed to run a SnapMirror job right after) are all running into each other and eating up bandwidth. I've tried changing the schedules multiple times, hoping to find a sweet window they can trade off...but that's going to take a lot of trial and error.

In terms of the large delta on at least one job, my gut tells me (since it's the same amount every day, give or take a few GBs) it's a SQL job -or some other daily task- firing off and making those changes, like a backup from SQL, which would erase the files and recreate them. That happened last year, and I turned the job off since we use SnapManager for SQL.

Anyway, sorry for rambling, I appreciate you helping me out. I promise I won't keep peppering you with questions.

Oh, those alerts, I have them set to email me "Always" and the link doesn't launch for some reason...and the url is in IPV6 for some reason. Nevertheless, when I paste the link in my browser and change the IP to the FQDN of the server, it says that backup log doesn't exist. I'm sure the log is kept somewhere on the C: drive.

[Nick_Andreev]

You can run VDP jobs weekly and VSC jobs daily, but you have to understand that VSC is snapshot-based. There are certain scenarios where it may not be able to recover data, such as volume deletion or array failure.

Generally I would recommend to run normal incremental backups daily and full backups weekly or monthly. Run VSC jobs daily as well. And you can add additional normal snapshot schedules for your CIFS volumes if you have any.

I tend to think of VSC as an add-on tool for easy and quick data recovery, such as you can use VSC to recover a particular VM from a volume snapshot by mounting it to an ESXi host. But I wouldn't count on it on it's on. As snapshots is not a "true" backup solution.

I also have a few VSC blogs. I wrote them quite a while, but they help to understand how VSC works. You can find them here if you wish:

• Magic behind NetApp VSC Backup/Restore
• NetApp VSC Single File Restore Explained