Backup as a Service: Fire-fighting of the Past, Present, and Future

Last weekend a fire broke out in my Boston apartment building (below). Of course it was the middle of the night. And of course it was cold and rainy outside when we had to evacuate. When the alarm went off at 3AM, I contemplated shoving a pillow over my head to drown out the noise and going back to sleep, thinking that in all likelihood it was some college prankster (thinking back to my own college days, when a fire alarm was pulled nearly every weekend). But, being new to Boston, I thought it best to heed the alarm and exit the building…after all, my apartment building is over 100 years old, and a dense, urban environment does catch fire every now again (much different than the mostly suburban environments I lived in before). So, in the middle of the night, I trekked to the street in sweats and watched the whole ordeal of fire trucks, firefighters, and spectators unfold from a safe (but still visible) distance.

This made me think of backup and recovery (actually it did!). It’s like the Boston Fire Department. Taken for granted unless it’s an emergency and you need it. And like the Boston Fire Department, if implemented well, can really cover you *aaS in case of a disaster. And when I say *aaS, I mean all the cloud-based services you may be offering to your customers or consuming yourself. Backup as a Service (BaaS), like the Boston Fire Department, can serve as the protection you need in order to survive–whether this means continuing to meet the SLAs in place with your customers or within your own IT group, or meeting recovery time objectives (RTO).

Give me some leeway with the Fire Department parallel here and I will blow your mind. Before the Fire Department and the sophisticated alarm systems we have rigged up today, there was word of mouth. This meant that when a fire broke out, the only way someone would be notified was via a third-party, who was assigned the responsibility of announcing the emergency. The third-party often was unreliable and took too long to deliver the message; once the message was delivered, you had to go to the well, wait to draw water and then, and only then, try to put the fire out. Moreover, imagine if the well was dry or if there wasn’t enough water? Only part of the fire could be put out in this case. So, think of this as tape backup. Tape backup (legacy backup) typically has long backup windows and recovery times less than ideal, waiting for the messenger to go to the data “well” to retrieve your backup for you. Sometimes you would get your backup in a less than ideal state, since it’s difficult to verify the functionality of a remote tape backup. This is like trying to put out a fire from a nearly dry well.

Then enter disk. It’s more effective that tape in terms of backup emergencies, making backup windows quicker. Dedupe technology allowed you to store the same information once, but available to every application that may have written the same data. Backup to disk, with dedupe, can be likened to the next evolution of fire-fighting, where there is a more sophisticated, automated process of detection, message dissemination, and attack. This would be akin to our modern-day Fire Department, where the Department is automatically hooked in to a given alarm system, and responds immediately, equipped with the proper tools to address the workload disaster.

(Courtesy of the City of Boston)

I bet you can already see where this is going. We’ve covered fire-fighting (backup and recovery) of the past and present, but what about the future? Stay tuned for the “future of fire-fighting,” coming later.

Chandra Jacobs is Senior Marketing Associate, EMC Backup Recovery Systems. You can follow her at; http://thebackupwindow.emc.com/emc-backup/