November 1, 2002 at 9:53 am
My boss needs me to come up with a plan for an offsite disaster recovery plan for our servers. Besides the obvious of log shipping etc.. anything from experience that I would need to include in the details of the plan. We have to bring it to the board so I would as detailed and professional as possible. Thanks
November 1, 2002 at 2:31 pm
You need to decide costs and look at the options, and the acceptable downtime and data loss.
Simplest.
Backup to tape periodically
On Failure restore to standby server.
Next step
Backup db and logs
and restore as above.
Next
Backup db and logs
Transfer to standy server
Restore in event of failure (does not require files/tapes to be sourced)
Replication
An option but complex, requires schema to be compatible, makes main setup complex, wouldn't touch.
Next
Log Ship
Also what events disaster recovery should encompass all failures, disk, cpu, memory, network, fire, bomb.
Do have a new site? What connection do you need, especially if transfering files. ISDN backup might be good for running app, but transfering a xGb backup could take days
Simon Sabin
Co-author of SQL Server 2000 XML Distilled
http://www.amazon.co.uk/exec/obidos/ASIN/1904347088
Simon Sabin
SQL Server MVP
http://sqlblogcasts.com/blogs/simons
November 1, 2002 at 4:04 pm
You need to get an idea of the solution taht will alow you the closest duplication of data within reason of data loss.
Major consideration I would add is size of data, number of databases, and if more than one DB is there a different concenr over each.
I currently have 32 databases on my server. 7 of which are not an issue as the data can be recovered from other sources (we do a full backup once a week to tape, forunately these are the largest databases and don't require all the data to be available within commitment time). Then all the rest but one only require a daily copy to be available so daily transactions do not matter as they can be rekeyed (full backup to tape nightly and a copy to drive on another machine). Then the final one is under transactional replication as it needs a 24/7 copy (not uptime) of the entered data to be available.
With this in mind we have decided only the one needs to be backup and running with a short period (for us 12 hours as the major concern has a backup process the users follow until available again). The others have a 48 hour commitment.
In our transactional replication only the tables are copied and sent over in the snapshot. We have all the rest scripted to bring the database operational within a few hours.
Now if you do consider a replication I will add this warning. If the server is highly utilized then purchase a third machine to use as distributor. If not then aim for a seperate distributor if you have an option (makes a great local recovery server as well and you can replicate to it too as a subscriber).
As for the rest, you have to determine as stated "the cost and option that will meat your downtime and data loss requirements."
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply