January 22, 2010 at 10:09 am
subs99 (1/22/2010)
...So when you "do a SQL backup", does this often mean you actually do TWO backups -- 1. a backup within SQL Server that creates backup file(s), then 2. a Tape backup that pulls those files to tape (which are then stored somewhere safe)???
SQL backup to local disk, a job to move the files to a central server, then backup from that server to tape. This provides a multi-tiered approach. If necessary, files from one of the locations may be deleted.
And then what? Do I delete the backup files just after they've been pulled to tape? Or do you normally leave a full-restore's worth of files (the latest full + diff + logs) on disk so you could restore from that disk, and not have to go find tapes in your off-site archive?? So do you, for example, Sunday night do a FULL backup, then just after that delete all the old backup files??
If necessary, files from one of the locations may be deleted. However, having a certain number of backups available on disk helps to provide for quicker recovery in the event of a failure.
And then Microsoft warns over and over that you really don't have any backups unless you TEST YOUR BACKUPS! Wow, now that's a project! Does everyone actually test their backups? (ya, right!) Do you document up an entire Backup and Restore Strategy? (ya, double-right!!)
It is true that you do not have a backup until you have tested a restore. Restoring every backup is not a common practice. However, having a process to test the backup and restore process is necessary. Part of that process dictates how frequently you will test backup and restore.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
January 22, 2010 at 2:37 pm
Another thing to consider is what is meant by local storage. Local storage can be direct attached - in that box or a SAN. The SAN can be in the same rack - or across the data center.
With that many databases, I would be pushing for storage on an Enterprise level SAN for the database files (mdf/ldf) and backup files (separate SAN if possible).
That gives you another level of separation where you can lose the server and/or rack - but still recover to point in time because the SAN is still okay.
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
January 22, 2010 at 3:15 pm
subs99 (1/22/2010)
And then Microsoft warns over and over that you really don't have any backups unless you TEST YOUR BACKUPS! Wow, now that's a project! Does everyone actually test their backups? (ya, right!) Do you document up an entire Backup and Restore Strategy? (ya, double-right!!)
As a best practice, a DBCC check should be performed before every Full Backup. This makes sure that you have a Backup that is not corrupt...:w00t:
Testing backups on a periodic basis is a good practice and if your application is Mission Critical then a DBA can do himself a favor and TEST restore frequently.
Any good company Documents entire Backup and Restore Strategy...:-)
Personally I have been involved in two Test DR's that were part of our BCP.
Hope this helps..
The_SQL_DBA
MCTS
"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."
Viewing 3 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply