Data Backup and Recovery

Virtual Storage Console backup jobs

Digriz60
4,021 Views

I don't run SnapCenter. We run VSC only for the backup function. With that said here's my scenario:

 

We used to run our snapshots and snapmirrors through OnCommand. Because the volumes we have are so large, and at the time we had a 3mbps MPLS, our jobs constantly were lagging and interfering with each other.

 

So I decided to use VSC and backup/snapmirror individual servers on the same volume. But when I look in OnCommand, the jobs still seem to be running into each other. We now have a 20mbps AVPN to our backup site, and I was wondering when a snapmirror is executed, is it only transferring that one server's backup job, or the entire volume? I have each server firing off a SnapMirror update, is that too often?

 

I have turned off all snapmirror schedules to 'on demand' on OnCommand. I'll also note, the Snapmirrors are being sent to our satellite office for DR purposes, and we're using SRM. I just wanted to make sure this scheme is actually working or best practise. I do bring up the SRM test about once a month, and I test the freshness of the data by logging into the SRM database and run a query against a table I know is updated constantly. As long as I come up with data from that day, I think we're ok and current on our data.

 

Thank you for your perspective, I appreciate it.

1 ACCEPTED SOLUTION

TMADOCTHOMAS
3,993 Views

Hi Digriz60,

 

We use VSC for backups as well. When you say "individual servers" do you mean you have separate jobs for each VM? If so I wouldn't do that unless it's necessary (I actually didn't even know you could do that). We back up each entire datastore with VSC. You can still restore individual VMs if you do it that way.

View solution in original post

3 REPLIES 3

TMADOCTHOMAS
3,994 Views

Hi Digriz60,

 

We use VSC for backups as well. When you say "individual servers" do you mean you have separate jobs for each VM? If so I wouldn't do that unless it's necessary (I actually didn't even know you could do that). We back up each entire datastore with VSC. You can still restore individual VMs if you do it that way.

Digriz60
3,987 Views

Huh, I see! We did have a dormant job that covered the whole volume...it's just that doing the whole volume at once had us lagging for days.I broke it down to individual VMs so I could stagger the snapmirror jobs. I should clarify our snapshots are fine, it's the snapmirroring that takes a long time to push the entire volume to our DR site. I'll create a job and try out the whole volume and see if we still encounter that lag. Or, if I'm going to do a whole volume, should I just do it in OnCommand?

 

Yes, I know snapmirrors are supposed to be the deltas, and considerably smaller than the baseline, but these snapmirrors really take a long time. In fact, looking at OnCommand, all the jobs that fired off are still busy, and two snapmirroring are still running, one from the other day and one from last night.

TMADOCTHOMAS
3,937 Views

Of course it depends on your bandwidth as far as how long they take. If they take >24 hours it will interfere with the next running of the job. What you can do to alleviate that partly is not kick off SnapMirror from the VSC jobs, and schedule SnapMirror jobs separately. Just be sure to schedule SnapMirror at least 5 or 10 minutes after the snapshot is generated by VSC.

Public