In my last post in this series, I presented a financial model for backup and restore, The Backup/Restore Cost Model:
TotalAmountOfMoney = (1/ (RPOFrequency * TimeForOneBackup)) *
(Size(D)*CostPerByte+RTO*DownTimeCostPerSecond)
Before I consider the implication of the model as a whole, I want to focus on one of the terms:
(Size(D)*CostPerByte+RTO*DownTimeCostPerSecond)
This term says that the cost of a copy of data is the cost of storing the data and the cost associated to making the data available when you need it. The first part is a real quantifiable dollar amount. The second part is funny money because it does not come out of a budget, but comes out of someone's bonus check while an application is down.
But I think you need to combine both to determine the true cost of a copy. If the restore time is not part of the cost of a copy of data, then you can end-up with some truly absurd optimizations. For example, why keep a copy around at all? The cost of a copy that does not exist is 0.
What I find most useful about this term, is that it captures exactly why disk-to-disk backup became popular outside of the traditional tape backup infrastructure. The backup team is held accountable for creating a copy of data and storing it cheaply. The applications team is held accountable for application down-time. For the backup team, it is essential to optimize Size(D)*CostPerByte. The applications team, however, wants to optimize RTO*DownTimeCostPerSecond. Tape works great for the backup team's priorities. Disk can work great for the application team's priorities.
I was walking to Brown University from my in-laws house, when I had a brain wave....
It's precisely that tradeoff between cost of storing the data and the restore time that is the arbitrage of backup.
And in fact, one could say that The Backup Restore Cost Model really defines an equilibrium point, the Backup-Restore Equilibrium. What I mean, is that for any given infrastructure with a CostPerByte to store the data and RTO, you can only store so many backup images given financial constraints. The number of backup instances you choose to store on the infrastructure is the equilibrium point.
Given that the number of backup copies forces you to use infrastructures with different costs we can say that a backup architecture really consists of a set of infrastructure components that satisfy different Backup-Restore Equilibriums with a financial constraint and a number of copies constraint. The backup and application architect challenge is how to optimize the total amount of money to get the right equilibrium for each kind of infrastructure.
Next post, I will have some better math to make sense of this insight.
Comments