HPE Storage Users Group

I've been tasked with coming up with a backup strategy to resolve issues with an ageing D2T procedure that is causing lots of issues. Obviously there are lots of variables, RTO's, RPO's etc but I'm just canvassing for opinion really and to see what you folks might be doing with your backup approach.

We will shortly be getting 2 x 7400 arrays, one at prod site, one at DR. The prod one has been specced with a bias on performance (5% SSD, 65% 15K FC, 30% NL) and the DR one has been specced more for capacity (40% 10K FC, 60% NL - usable space is considerably more than the prod array). We will have the replication suite licenses and a decent 1Gb circuit between the sites.

We are mainly running Hyper-V VMs on the storage, some MS SQL database VMs, some physical database servers also using the primary array for their storage.

My opinion is to remove all the tape backup from prod site. Async replicate all critical data to DR array and backup to tape from there for long term retention but otherwise keep 7 days of snapshots on the primary array for quick recovery and maybe 30 days worth on the DR array.

For MS SQL I was going to suggest using SQL scripted backups to an area on the NL CPG which can then also be snapshotted (sp?) and replicated to DR for longer retention snapshots and tape backup.

For recovery I was looking at Veeam v7 for integration with the 3PAR and direct recovery from the snapshots. Tape backup at DR site will be NetBackup with software dedupe.

Whadya reckon? What are you doing?/would you do with 2 3PARs?

We just implemented something similar. We D2D2T and the daily and weekly backups were driving more IO into the array that regular workload was. We are completely virtualized on vmware and AIX VIO. We run in guest agents for things like SQL, Oracle and basic shared files system data (home dirs, shared data drives, etc), because we have to retain that monthly data for 7 years. Everything on the source array is replicated to the destination array. What I have doen is set up scripts that snap all the VMs starting at 7pm, it goes a cluster at a time, enumerates all the datastores, then one datastore at a time it snaps the VMs and then snaps the array volume with an expiration of 14 days. Since we start all backups and I schedule replication via scripts to run only during the evening for most things, I then on the destination array run a a script that snaps all the volumes by name syntax just before replication kicks off so the destination array should have a clean copy of the previous days data snapped, also retained for 14 days. This has been working great and removed a huge backup load from the infrastructure.

Thanks for the reply. So you have 14 days of snapshots at both sites. Your restore process is to present the virtual copy to a spare host and manually copy VM files back into your production datastore? I'm hoping for something a bit more integrated, which is why I was looking at Veeam.

Also I want to backup to tape from snapshots taken of the DR array's replicated copy of the primary's data. Not sure how to achieve this yet, NetBackup doesn't appear to support 3PAR hardware integration.

Yes we keep 14 days of snaps on both sides. On the source side I have a Powershell script that goes through a cluster and enumerates datastores and a datastore at a time snaps each VM then snaps the 3par LUN then deletes the VM snap. I will be adding capability to trigger the RC Group at the same time so the snapped VM can make it to the other side, but there are a few scenarios where that causes problems. Since we do most of our replication through the night starting at 7pm, on the destination side at 6pm I snap all the VVs related to the cluster via the ascript using the 3par CLI. This way the snaps on the target side represent basically the systems from the day before.

To restore files we have a Win7 VM that we just keep running and if we need individual files we have a process of mounting the snap and just attaching the needed VMDK to the Win 7 system and grabbing the files. If an entire system is needed then we delete the current VM, mount the snap, scan datastore and add the vmx to inventory. We power up the VM and once it is stable we then Storage vMotion the VM back to original datastore. Works great, and since our Commvault backup software was licensed by capacity it is 40TB less we back up so we saved on software costs as well.

Next step is to update script so it sends email when there is an issue and saves list of what it snapped off to a file so we can have an audit trail. We have been on this process for about a month now.

Sounds like you have a good solution going but as a short-term contractor working on a specific project I'm reluctant to build too much bespoke scripting and manual process into the solution as no matter how well something like that is documented it's always problematic for someone other than the designer/implementor to come along and pick it up, hence why I'm looking at stuff like Veeam.

Now it seems if I 'm to go down that route then I might be better off not using SAN replication for the bulk of the solution at all and sticking to replicating using Veeam instead. It also hooks into the 3PAR to manage and backup from the storage snapshots, which is a nice feature and the restore process is much slicker doing it all from within the one management GUI but it means I'm doing the backups from the primary array and not the DR one, which is what I'd hoped to do.