October 24, 2011 at 1:25 pm
dajonx (10/24/2011)
Also since you're using the EMC version of SAN-to-SAN replication, are you not doing full backups and just doing transaction log backups?
Actually, the SAN to SAN replication is completely outside our SQL database backup scheme. Our SAN is replicated to an offsite DR repository. We do a cycle of backups (Full, Differential and Log) locally to disk and then to tape. Periodically the tapes are rotated offsite via Iron Mountain. The SQL backups don't go to the DR site.
I have been working on transitioning to only Log backups. The idea is to use log shipping to restore the backups to a secondary server (at our primary site). This would give us immediate feedback on whether the backups were valid. As the saying goes, "if you haven't done a restore, then you don't have a backup." However, this would be strictly for local backup and have nothing to do with our offsite Disaster Recovery.
Essentially, they are for different purposes. The SAN replication gives us a real-time copy of our entire primary site infrastructure. If our building is destroyed (hopefully while I am elsewhere) we can bring our essential services back online at our DR site.
The onsite backups are for those times when someone needs a copy of the production database restored to a specific point in time.
You might be best off keeping your SAN replication separate from the current backup and restore scheme. You might need another server, but that is a part of Disaster Recovery. I'm not sure what will happen to your full backups when your bandwidth is restricted. Have you tested this with a limited-bandwidth pipe? It might actually work OK.
October 24, 2011 at 1:50 pm
Thank you, David, for explaining your environment!
After reading your response, I do have to agree with you that SAN to SAN replication is outside of the backup and restore scheme, but it does give me an extra level of protection. Perhaps a better list for Disaster Recovery is:
1) Database Mirror
2) SAN Snapshot (database snapshot)
*3) SAN Replication
4) Full/Differential/Transaction Log Backups
I have Full/Differential/Transaction Log Backups forth because I may not have it on-hand if I decide to just burn it onto DVD and have it mailed to me whereas the SAN Replication could be up and running pretty "quickly".
I have not tested the backup transfer with a limited pipe, but it does take six hours to transfer with a 100 Mbps pipe we have here so I'm guessing that it would take quite a while if I have a 15 Mbps pipe. 😛
I am also looking into WAN optimization vendors and hoping their products can reduce traffic for our limited bandwidth. I'm curious to know if anyone has any experience with them though.
Edit: Oops, the list is still the same.. I guess it's not a better list afterall... 😛
October 24, 2011 at 9:50 pm
dajonx (10/24/2011)
Thank you, David, for explaining your environment!After reading your response, I do have to agree with you that SAN to SAN replication is outside of the backup and restore scheme, but it does give me an extra level of protection. Perhaps a better list for Disaster Recovery is:
1) Database Mirror
2) SAN Snapshot (database snapshot)
*3) SAN Replication
4) Full/Differential/Transaction Log Backups
I have Full/Differential/Transaction Log Backups forth because I may not have it on-hand if I decide to just burn it onto DVD and have it mailed to me whereas the SAN Replication could be up and running pretty "quickly".
I have not tested the backup transfer with a limited pipe, but it does take six hours to transfer with a 100 Mbps pipe we have here so I'm guessing that it would take quite a while if I have a 15 Mbps pipe. 😛
I am also looking into WAN optimization vendors and hoping their products can reduce traffic for our limited bandwidth. I'm curious to know if anyone has any experience with them though.
Edit: Oops, the list is still the same.. I guess it's not a better list afterall... 😛
We're implementing the following for DR:
1. Sql backups to disk (daily fulls, hourly logs)**
2. Bare metal/file system backups go to a Unitrends backup appliance (30TB internal HDD storage, does compression/de-duplication)
3. backup appliance "vaults" (aka, copies) the data to an identical appliance at the DR site. They claim lower bandwidth usage compared to SAN replication, but I haven't seen any actually performance numbers yet.
4. We'll keep a 45 day window in the appliance, with monthly fulls going to a tape library at the DR site and then offsite for permanent archiving.
Supposed Advantages:
1. faster restores as all recent data is on disk, not tape.
2. lower bandwidth between DR and primary site
3. greatly reduced labor as the daily tape shuffle goes away.
** the appliance supports VSS snapshot backups of sql server if you want to go that route. We haven't dug into it enough to say whether it makes sense for us.
October 25, 2011 at 6:18 am
Thank you, SpringTimeDBA!
The SAN Snapshots that I've implemented actually uses VSS and the SAN flushes and freezes all transactions to the database for a split second and takes the snapshot. I was worried about the freezing part, but so far, users have not noticed anything nor have any of our application jobs failed.
Blue Coat and Riverbed have both mentioned that their appliances work well with SAN Replication, but we haven't tested it out yet.
What is the point of moving full backups to tape versus DVD or on an external hard drive?
October 25, 2011 at 2:43 pm
I wasn't involved in that decision, but my guess is the size. I believe our corporate full backups are 10-15 TB.
October 25, 2011 at 7:55 pm
dajonx (10/21/2011)
Right now on our 100 Mbps WAN connection, it takes about six hours to transfer the full SQL backup to the backup site....
...
...
Does anyone have any suggestions?
Yep... "snail mail" a tape and have someone mount it. Nope... I'm not being silly. It's a tried and true method that I've used many times. Fed Ex and other companies can do trully remarkable things and, unlike long haul file transfers, they get it right the first time. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 26, 2011 at 7:01 am
IIRC, CDs only handle about 750MB... it would take quite a few to handle a 200GB backup. Single layer DVDs can hold a bit over 4 GB. Double layered and double sided DVDs can hold a bit over 8GB.
The advantage of tape is that you can buy systems that will hold all 200GB on one tape and so requires very little operator interaction. The disadvantage might be the cost but I don't know for sure because it's been a long time since I've priced a tape backup system.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 26, 2011 at 8:10 am
After dwelling on it and reading other people's concerns over tape backup, perhaps it would be better to use an external hard drive and ship it back and forth (using more than one external HD). I would then move the full backups off of the external HD when I receive it.
What do you guys think about that idea?
October 26, 2011 at 12:31 pm
Here's an update:
I was told that I could use the SAN Snapshots/SAN Replication to restore the volumes and perform a full SQL backups on the backup server which may just eliminate the tape/external hard drive/snail mail idea.
Do you guys see anything "iffy" about this?
October 26, 2011 at 2:16 pm
Nope... I was going to suggest it but didn't think it would work in your situation... I though you were doing long haul stuff.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 27, 2011 at 6:44 am
It is a "long" distance, but not like on the other side of the world. We are looking into WAN optimization vendors that say that they work well with our SAN's replication so we will still have to test it in that aspect, but I believe that if the WAN optimization works out well then doing SQL backups via the SAN Snapshots/SAN Replication will solve snail mailing hard drives back and forth. 😀
I still need to test it out thoroughly, but I'm excited! :w00t:
Thank you for all your help!! I'll let you guys know how it turns out and hopefully it could help someone else out there!
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply