roger.plowman (3/12/2013)
I don't know if I'd want backup information in the database or not. On the one hand I could see it, and you're right, having information about the backup in the database is a seductive idea. At least for the backup portion of the instructions...But...what happens when the database is corrupted? Where are the restore instructions? Same database? Then how do you restore?
And if you put the restore instructions in the instance instead of the database, does that really buy you anything? Because then you have to split the backup and restore instructions and now you've introduced a huge confusion new DBAs are going to fall into.
Not a good idea with backups.... 😀
Since you (presumably) know where your backup files are stored and you will need to bootstrap at least that far, the first backup will restore most of your detail work. That is a good thing. Basically this is no different really from ANY significant SQL server failure, regardless of where the backup details are stored.
Because certain information needs to be outside the backup (you do have a DR manual, don't you? Keys and passwords saved someplace accesible?) does not really change the value of incorporating much of the pedestrian detail into the backup itself. There is lots of detail information that benefits from encapsulation, it certainly would be awful nice if, once you restored a database, all your backup jobs were ready to go.
...
-- FORTRAN manual for Xerox Computers --