In information technology (IT) and software engineering, operators and DevOps folk define their "backup" systems and policies. However, they infrequently or never state their data restoration service levels. The only measurement that an end-user cares about is: how quickly, and from which times in the past, can you successfully recover the state of my data? And, if no data restores are needed, how do you test that your recovery service levels are met or exceeded as my data volume grows?
Making many copies (backups) of data frequently and storing all of those copies (or differences) costs a significant amount of network, compute, and storage, especially for longer retention periods. Therefore, the IT or DevOps team should discover and deliver only the restoration requirements their end-users need, and for which they are willing to pay or be cost-allocated.
We are in the recovery business, not the "backup" business. I consider the term "backup" to be a terrible word because it normally means only "untested, expensive copy." Therefore, I personally never use that word and instead talk about our recovery capabilities and service levels. And I always try to implement an automated test system that verifies these data restoration service levels are correct.
No comments:
Post a Comment