You’ve heard me talk about this many times, in so many different ways, but it’s worth repeating: SQL maintenance lifecycles are important.
People who disagree, disagree because they spend too much time firefighting and don’t have time to really think about it. Don’t know anything about SQL maintenance lifecycles? Let’s touch on a couple of points…today, we’ll cover SQL backup.
SQL maintenance lifecycles: Backups
Backups have the biggest lifecycles of all, because the uses for backup files are so varied.
They’re used for restoring databases to the original server, sure. But here’s a short list of the other kinds of things you need to do with backup files:
- Restore to development, QA, etc.
- Send to vendor
- Initialize replication
- Initialize Availability Groups
- Restore to a secondary server to run CheckDB
A backup is not a single event
A database backup isn’t a single event. But unfortunately, nearly every vendor out there – and most DBAs – treat backups as a single event that has a start and a finish. “Look, I took a SQL backup and produced a file, and now I’m finished!” But that’s not remotely the case. We use and shuffle SQL backup files around all day and all week long on our various servers.
This is why I’m so against those tools that I call “network backup tools”. You know the ones: Backup Exec, AppAssure, etc. Your network admin loves those tools, because he doesn’t understand SQL and he wants the same backup utility for the whole shop.
Continue reading on MinionWare.net.