Luis Cazares (10/17/2012)
I'm not an expert in this area (I'm just learning) but an advice I've read says that you shouldn't have a backup plan. You should have a recovery plan
So very very true.
pdanes (10/17/2012)
Yes, I've read that sort of advice as well, and it's certainly true, but it's difficult to restore something without first having backed it up.
Which kind of misses the point about the above advice (having a recovery plan). Recovery plans aren't about restoring the databases. Recovery plans are about "How much data can you afford to lose?"
Before you design your backups, you need to know the following:
1) How long can the database be down (and non-functional) while you are restoring?
2) How many minutes, hours, or days behind can your data be once you have restored? (I.E., how much data can you afford to lose?)
3) What kind of system (OLTP, OLAP, etc.) are you planning backups for?
4) How much your data changes over the course of a day, a week, and a month?
5) Is the database-read only or read-write?
6) How big is the database?
These are all very important questions to know the answer to before you decide what kind of backups you do, how often you do them, and how many backups you keep. If you don't know the answers to these questions, you're just guessing and guessing can get people into trouble.
Recovery strategies are very important. If you need to be able to do Point-in-Time restores, for instance, the database recovery mode is going to be set to FULL (or should be). If your database is in the Terabyte / Petabyte size range, you might be doing file / filegroup backups instead of full backups. Or you might be doing partial backups. If your database is read only, you don't need to back it up every day. Whereas if you're running a highly active transactional database where data gets updated on a minute to minute basis (think airplane companies or hotels), you might need differentials and complete / full backups along with transaction log backups.
Remember, a good strategy isn't about restoring a database. It's about optimizing your time and data protection. You don't need a backup to start with a recovery strategy. But if your databases aren't getting backed up at all, set up complete / full backups and transaction log backups with FULL recovery mode on until you do get your recovery strategy set. That's the safest bet to cover your bases.
Then sit down with your business users and establish a reasonable recovery plan SLA before Bad Things<tm> start to happen.