{"id":2778,"date":"2011-02-11T16:31:23","date_gmt":"2011-02-11T06:31:23","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=2778"},"modified":"2011-02-11T16:31:23","modified_gmt":"2011-02-11T06:31:23","slug":"pumping-data","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2011\/02\/11\/pumping-data\/","title":{"rendered":"Pumping data"},"content":{"rendered":"

\"Pumping<\/a><\/p>\n

The age-old consideration in backup is the most simple one: how to pump the required data through in the required time frame in such a way that it can be readily recovered. This challenges us to constantly find the best way to achieve the data throughput required. What worked 10 years ago was not always applicable 5 years ago; what worked 5 years ago is not always applicable now. Consider for instance the adage:<\/p>\n

Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.<\/p><\/blockquote>\n

(Andrew Tanenbaum, 1996.)<\/p>\n

What surprises me, to a degree, is that still, in 2011, we’re having discussions about data throughput where people focus on the wrong thing<\/em>. I would humbly respect, that you shouldn’t give a flying fracas about how fast \u00a0you can back your data up when compared to how fast you can recover it<\/em>.<\/p>\n

That’s right: when talking feeds and speeds, the only one to give a damn about in backup is how quickly you can recover the data once it’s been captured.<\/p>\n

This is, in fact, why the terms RPO and RTO were invented. In particular for the topic of “pumping data”, RTO \u2013 Recovery Time Objective \u2013 is most important. How quickly do you need<\/em> to get the data back?<\/p>\n

In this scenario, Andrew Tanenbaum’s caution about a station wagon full of tapes hurtling down the highway is entirely appropriate. In fact, so much so that when companies start talking about how fast they need to backup<\/em> (or how fast they can<\/em> backup)\u00a0without reference to recovery, I unfortunately go into this loop:<\/p>\n