This blog post applies to situations where DR does not involve instant fail-over.
Having been brought up in a mainframe environment I was never in doubt that Disaster Recovery (DR) was never the same as backup. However we can’t always impose mainframe standards on everybody else. Sometimes, but not all the time.
The dilemma lies in:
- backup formats
- SPOF avoidance
- geographical separation
In the case where an IT department sticks to the purist definitions of DR, it will never confuse a DR copy with backups. Or should I say ‘file backups’. In the case of re-loading the primary data, the DR copies may not lend themselves to selective file restore. But more importantly, the DR copy is not there to used except for the real thing or testing the real thing. Then there is ensuring that things are always kept in separate locations. When a primary site is rendered useless and the DR copy needs to be invoked, it is likely that the site is 2 steps closer to a single point of failure (SPOF). The 2nd step is taken when DR copy is transported away from its secure vault.
The reason why these considerations applies is because of file backup software forming the basis of the DR process.
I have had many discussions recently where backup vendors on the one hand simply states that a file based mechanism is the complete solution to DR, while others sniff at the mere suggestion that file backups is not the same as DR.
If I put my mainfame hat on, then I would adopt the purist attitude to high standards. However in the SMB market formats, SPOFs and geos are often compromised in a dangerous blend. For the purpose of sizing the DR market in the Cloud, I suspect Rainmaker will have to compromise somewhat in its definitions. We will make articulate this and and the consequences.
Image credit: carljohnson