When writing a Business Continuity plan, one of the first metrics to you need to nail down is your Recovery Point Objective, or RPO. This seemingly simple metric can have a major influence on how you need to design your application infrastructure
For disaster recovery your RPO is the point before disaster that you want to be able to recover to. Another way of looking at it is as the maximum amount of data you are willing to loose in a disaster.
So an RPO of 15 minutes would mean that in the event of a major incident, you are willing to accept losing up to 15 minutes worth of data. Depending on when the distaster occurs, you may recover to within 4 minutes or to the full 15 minutes.
Surely every company wants a recovery point objectice of 0 don’t they? Well yes, that would be the golden RPO. But achieving that is a huge task that will have massive implications on the architecture and infrastrure behind their application. And an RPO for one system may not fit another system if they vary massively in workload or size.
Taking our example 15 minute RPO above for a SQL Server based application, this could be achieved with the following:
- Take Transaction Log backups every 15 minutes
- We can now recover to within 15 minutes.
- Backups done to a remote server
- We ensure that we have the backups if we lose the entire SQL Server box
So far so simple. Now, what if the Business wants an RPO of zero? (ie; no loss of any committed data). Is that doable? Yes, but it’s going to cost you:
- 2 SQL Server instances running in Synchronous Mirroring mode (High-Safety)
- So that’s a doubling of physcial hardware costs, and a near doubling of licensing costs as well.
- Plus your system is now more complicated to administer (compare to a single box).
And that’s assuming your disk systems at either end, and the network connection between your servers can keep up with your transaction throughput. If they can’t then you will be looking at beefing them up as well, with all the associated costs that goes along with that.
You can now see that the RPO you set can have a huge impact on the costs and complexity of designing a new solution. And that forcing an unrealistic recovery point objective onto an existing solution can lead to a possibly painful restructuring and redesign. This is yet another reason why a Disaster Recovery plan should be written during the design phase of a new project rather than as an afterthought.