THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Argenis Fernandez

DBA Best Practices: A Blog Series

This blog has moved! You can find this content at the following new location:

Published Monday, November 12, 2012 9:11 PM by Argenis

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Dale said:

One of the issues that I've had is not that I have a good backup, and a good restore, it was that the data seemed correct, or non-corrupt, but there was no way to verify it was good and relevant data.

Looking forward to reading more.

November 13, 2012 1:12 AM

TedS said:

It depends!

The start to any backup strategy is a good long healthy discussion with the people who 'own' the data (DBA you protect the data, somebody else owns it)..

Their knee jerk reaction is that all data is scared and should have the best possible backup, but on deeper examination you can find ways to protect the data and minimize IO and CPU cycles.

Always a tightwire act isn't it!

November 13, 2012 9:48 AM

Karthik said:

It is very important that all the parties involved ( Business and Technical folks) know their RPO and RTO. Depending on that a suitable backup and restore strategy can be built.

November 13, 2012 12:29 PM

SQLFinn said:

One thing I personally consider important is an up to date documentation of your backup and restore processes. No matter how good the plans are, but they wont be much of a use if the procedures exists only in your head and someone else would need to perform the restore actions.

I also agree with previous comments, DBA's dont own the data and dont necessarily understand the business requirements or possible laws and regulations regarding the data. Good communication with the business/data owners is a must thing.

November 14, 2012 1:45 AM

Leave a Comment

Privacy Statement