I’ve seen things
Terrible things. I mean, not just working here (which, as I write this, I’m three days away from the two year mark, fingers crossed!), but also out there on the internet.
Once you leave the safe confines of Brent Ozar Unlimited, you’re subject to the ravages of space. Strangers. Radiation. Strangiation. Your bones will scream. It’s bad!
So let’s talk about backup strategies
First and foremost, they need to match your RPO and RTO goals. So, go ahead and get those in writing first. The ‘in writing’ part is important, so no one can turn around and say GOT YOUR NOSE when things get wonky.
Backup schedules are like carefully woven spiderwebs, engineered to be safe, stable, and catch any potential bugs. We all know what happens to spiderwebs when our eight legged friends are exposed to less-than-legal substances.
Let’s play a game
I’m going to list out some of the worst backup schedules I’ve seen, and you get to tell me what you think caused such a lapse of cognizant reality. Please try to limit it to what’s in the medicine cabinet or liquor cabinet, or at least what’s under the kitchen sink.
Oh, forget it. I know you people, and I don’t wanna know what’s in your medicine cabinets.
Assume all the recovery models are Full.
Web 1
- Full backups every four hours, log shrink job every morning that failed
Web 2
- VSS snaps every 15 minutes that froze I/O for 30 seconds
Web 3
- Full backups every night, log backups every 30 minutes that stop between 5pm and 8am
Web 4
- Set database to single user, take a full, diff, and log, set database to multiuser (daily)
Web 5
- Set database to Simple, take a full backup, shrink the log, set database to Full (weekly)
This place has everything
If any of these apply to you, now’s the time to start fixing them. If not, put down the Endust filled paper bag and let me know what you think was on someone’s mind when they designed these.
Thanks for reading!