Tell me more ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.
up vote 3 down vote favorite
2

Following Situation:

  1. You have a Database with very high transactions, the Database is about 4100 GBs
  2. The Recovery Modell from your Database is full
  3. Every week you make a full backup from your database
  4. Every day you make a diff backup from your database
  5. You make hour a Backup from the log

Now bad things happens: Your Server is down (lost power connection) , your emergency power supply is far away :/ What should the experience dba do, so that the database is going as fast as possible back online.

share|improve this question
Need more details about the current DR solution (are backups going off-site?). – Jon Seigel Jul 30 '12 at 20:13
you have no access to the backup, the server hw and the os looks okay... – ElDoroCapitano Jul 30 '12 at 20:14
2  
The experienced DBA should make sure they have access to the backups... – Thomas Stringer Jul 30 '12 at 20:19
1  
If there's no way to access either production or backups, you're out of luck. – Jon Seigel Jul 30 '12 at 20:20
this is the hard real world ... :D – ElDoroCapitano Jul 30 '12 at 20:28

1 Answer

up vote 10 down vote accepted

Remember: you do not have a recovery plan until you tested your recovery plan...

The theory is simple: on the disaster recovery machine you have prepared for such cases you restore the most recent full backup, then you apply the most recent diff backup (if any) and then all the hourly log backups taken after the most recent diff (or after the most recent full if no diff was yet taken since the last full). Since you were not able to backup the tail of the log, you will loose up to one hour of transactions. Since your whole recovery schedule was based on a plan to be able to restore within the maximum allowable downtime, your restored server will be up and running (including all jobs, migrated logins etc etc, and the application will be redirected to it...) within the allowed downtime, because you tested this before and is a known procedure, and the operator follows the well know checklist you have set in place for such an event (and had tested it!). And btw, if the maximum allowable downtime is shorter than the physical time required to do a full restore a 4.1Tb DB (which is measured in hours), then some warm or even hot standby (mirror, log shipping) is ready to take on the work...

What happens in the real world is that usually this is the moment when the power of hope (let's hope this never happens...) hits the hard wall of reality...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.