This week, some of my Twitter followers were kind enough to chime in on a topic near and dear to my heart: the proper caretaking of SQL Server. Here is some of what we said.
Me: Common scenario: A company has databases, but no “assigned” DBA. So, broken backups, no maintenance, no disaster recovery. Guys? I can help.
@wnylibrarian But they’re backing up the VM that the databases are on. That’s enough, right?
Me: If you don’t mind giant logs, no DR…
Me: Pop quiz, my people: Tell me WHY RAID isn’t enough. (Hold off on answering, if you’ve written a book about this…)
@SQLBob because a disaster is way more than just a drive failing!
Me: DING DING DING DING! Winner!! Other answers accepted…
@williamweber DB corruption, I choose you!
Me: Well done, have a cookie.
@AirborneGeek My usual short/sweet answer is: Data redundancy is not data backup.
@wnylibrarian Because its not a true DB backup. There are consistency issues.
@adamhill Time to rebuild failed drives and soft failures during the rebuild that cause rebuilds of the rebuilds on very large HDDs?
Me: Well done [@AirborneGeek]. You also get a cookie. Also @wnylibrarian & @adamhill
@crummel4 b/c sometimes a second disk fails before ops can swap the first. Like two failures w/in 5 minutes.
Me: Right. Or, you know, power fails. Or the building catches fire, or is swept away in a natural disaster. Whatevs.
Me: Actual quote from DBA, during a DR discussion years ago: “But, we’ve never had a disaster *before*!”
@DaveSchutz You can have multiple drives fail, network errors causing DB corruption, many other problems that muck up your DB.
@GFritchey It isn’t a book, but here’s why backups are important: https://t.co/IIhMqc6peW
Thank you, Grant, and thank you, everyone. You’ve illustrated the point perfectly.