Recovery Scenarios for E2K7…..III
This is the last of a few blogs about designing for availability and resilience… The first two are here:
Recovery Scenarios for E2K7…..I & Recovery Scenarios for E2K7…..II
So after understanding what the types of failures we might encounter, and the cost associated with deploying protection against each type, the next step is to make sure that our chosen solution meets our service level agreements…
Example SLA’s defined as recovery objectives are as follows:
Component Failure
Recovery Point Objective: 5 minutes
Recovery Time Objective: 15 minutes
Datacentre Failure
Recovery Point Objective: 5 minutes
Recovery Time Objective: 2 hours
So lets compare the various components of the solution against our recovery objectives…
| Scenario | Estimated Recovery Time | Recovery Objectives met? |
| Data Centre Failure (Loss of an entire data centre) | <2 hours | Yes |
| Server Hardware Failure (Component failure e.g. motherboard) | <15 minutes | Yes |
| Storage Failure (Access to all or a part of a volume\LUN – not including single disk failure) | <15 minutes | Yes |
| Mailbox Database Corruption (Physical) (Most likely as a result of hardware failure) | <15 minutes | Yes |
| Mailbox Database Corruption (Logical) (Data corruption may be as a result of faulting application or virus) | <2 hours | No |
| Mailbox Deletion within Deleted Mailbox Retention period (<30 days) (A result of an administrative or procedural error) | <15 minutes | Yes |
| Mailbox Deletion beyond Deleted Mailbox Retention period (>30 days) (A result of an administrative or procedural error or returning employee) | <8 hours | No |
| Email or Item Deletion (<14 days) (User mistakenly deleted an item –administrator intervention required only if item hard deleted) | <15 minutes | Yes |
| Email or Item Deletion (>14 days) (User mistakenly deleted an item –administrator intervention required) | <8 hours | No |
| Identify if and when a particular email was sent\received (<30 days) (only message route required) | <15 minutes | Yes |
| Identify if and when a particular email was sent\received (>30 days) (only message route required) | <2 days | No |
| Identify if and when a particular email was sent\received (<14 days) (entire message required) | <1 hour | Yes |
| Identify if and when a particular email was sent\received (>14 days) (entire message required) | <1 hour | Yes |
So once we understand exactly where our design meets or falls beneath the service we expect as defined by our service level agreements, we can then decide whether to go ahead into the next phases of the design or concentrate on solutions where SLA’s are not met.
I hope these few blogs have been of some use. If nothing else following through this exercise will help in understanding a bit more about how Exchange 2007 works and how it can be designed to work most appropriately in your organisation…