On the first day of DBA hell, the server gave to me
A database with damaged system tables and no good backups (1)
On the second day of DBA hell, the server gave to me
Two databases with widespread corruption, no backups (1, 2)
On the third day of DBA hell, the server gave to me
Three suspect databases, no backups (1,2,3)
On the fourth day of DBA hell, the server gave me nothing, cause I didn’t have a job any longer…
How does one end up with a critical production database that has no backups? I could kinda understand if the backups were damaged, if the corruption went undetected for long enough that it was in the backups as well, but to have no backups at all? Of an important database?
The only excuse for having no backups is if the database can be trivially and completely recreated from another source with minimal impact to the users. This is not the normal scenario.
There’s an immense amount of information available on backup and restore strategies.
- “Introduction to backup and restore strategies” on MSDN
- Paul Randal’s Technet article “Understanding SQL Server backups“
- Paul Randal’s presentation to the SQLPass DBA Virtual Chapter “Building the Right Backup Strategy” (not available for download at this point, check back in a few days)
That’s just a quick list, there’s far more information available than that. Enough that there’s really no good excuse to not have backups when they’re needed.
As Steve Jones (blog|twitter) is fond of saying “Good backup, good resume. You only need one”
Or as another modernized quote goes:
“Those who do not archive the past are condemned to retype it.” – Garfinkel and Spafford
I think this may become your catch phrase:
“Why the hell don’t you have a DB backup?”
haha
As Paul Randal pointed out in his presentation to the SQLPass DBA Virtual Chapter “Building the Right Backup Strategy” backups are good but the ability to restore is more important.