May 5, 2010 at 12:48 pm
Hi All,
We have around 8 critical databases that are residing on a 2 node active passive cluster. we are taking regular backups.
Fullbackups every night and Tlog backups every hour.
Every night all these backups are copied on to a Tape Drive.
The data is on a SAN.
The backups are also placed on the same SAN. The RAID level is RAID 5
For a cluster , the single point of failure is the shared disk array.
So if the SAN goes down, since the backups and the data files are on the same SAN, I wouldn’t be able to get the point in time data.
Is my understanding right?
So I am thinking of having an another job that copies the backups from the drive to another share right after the backup completes. So incase the San goes down also, we have the latest backup copies .
Is this the right way or am I missing something?
Please Guide me.
May 5, 2010 at 2:59 pm
You are correct in your thinking - if you lose the SAN completely, you'll lose the transaction log backups which would be required to restore to a point in time.
Copying the backups to another location is a good move - and one that I would recommend if you have the storage and can keep additional copies on that storage. Another benefit to copying the files is that you could move the tape backup process to backup that location instead of your production server, moving the IO off the production SAN and reducing the impact of that process on your production system.
I would recommend looking at Robocopy to perform the copies - it works very well for this and xcopy is deprecated in later version of Windows.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
May 5, 2010 at 3:28 pm
Thank You Jeffrey for your valuable suggestion.
May 5, 2010 at 5:30 pm
I agree with Jeffrey, but not because I'd be sweating the SAN just going down. By and large those things don't go away. I'd do it because you never know what could happen to your building, fire, flood, meteor... better to have an off-site copy.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 5, 2010 at 7:35 pm
Grant Fritchey (5/5/2010)
I agree with Jeffrey, but not because I'd be sweating the SAN just going down. By and large those things don't go away. I'd do it because you never know what could happen to your building, fire, flood, meteor... better to have an off-site copy.
Even better - if I had my way, we would be backing up locally, copying to another local SAN and replicating that storage to the DR site half a country away. And then, copying those files to tape and sending those tapes off-site, you know - just in case.
And, on top of the backups we also have mirroring/log shipping (or SAN replication) to the DR site for immediate recovery.
The more options you have, the better prepared you are - and it is all about being prepared.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
May 6, 2010 at 8:05 am
Hi Grant,
We do have a tape backup that occurs every night and we move the tape to an off site location.
Thanks
May 6, 2010 at 8:08 am
vky3 (5/6/2010)
Hi Grant,We do have a tape backup that occurs every night and we move the tape to an off site location.
Thanks
Then, I'd say you're basically OK. You can get more paranoid if you want, but by & large, SAN systems, by their nature, are pretty stable & reliable. As much as anything is in IT. I would only start adding to the things you're doing if you need a higher level of DR.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 7, 2010 at 8:29 am
A SAN is one thing; how the spindles are grouped is a completely different thing.
Are the backups sharing any of the same spindles (EMC Raidgroups) as the main files? If so, two drives failing (probably manufactured at the same time, in the same production lot, and subjected to the same mechanical stresses; heat, vibration, voltage, etc.) prior to the raid group being restored fully is entirely possible, and would take both your primary database and your onsite backups with it.
SAN's have a lot of redundancy in the control components, but the drives are not magical; they're very standard enterprise drives.
May 7, 2010 at 8:58 am
Nadrek (5/7/2010)
A SAN is one thing; how the spindles are grouped is a completely different thing.Are the backups sharing any of the same spindles (EMC Raidgroups) as the main files? If so, two drives failing (probably manufactured at the same time, in the same production lot, and subjected to the same mechanical stresses; heat, vibration, voltage, etc.) prior to the raid group being restored fully is entirely possible, and would take both your primary database and your onsite backups with it.
SAN's have a lot of redundancy in the control components, but the drives are not magical; they're very standard enterprise drives.
Absolutely true. I tend to assume that you've already spoken with the SAN admins and have worked on intelligent configurations of the drives. That isn't necessarily the fact though, is it?
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 13, 2010 at 1:26 am
If the SAN goes down chances are the whole business is down too, while it's a good scenario to plan for it's more realistic that a disk in your array may fail. I would break the RAID 5 and replace it with a RAID 1 for better write performance and keep a spare drive. If the files are picked up to tape each night then you will be just fine.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply