Data pro­tec­tion must change in the vir­tu­al­iza­tion age

Backup has never been as easy or re­li­able as it should be, and vir­tu­al­iza­tion just makes it worse

InformationWeek - - Opinion -

y first job in the stor­age mar­ket was work­ing for a backup soft­ware man­u­fac­turer in the late ‘80s. We were one of the first com­pa­nies that started ad­vo­cat­ing the idea of back­ing up data across a net­work to an au­to­mated tape li­brary. For a lot of rea­sons, it was very com­pli­cated and failed more of­ten than it worked. Fast for­ward al­most 25 years later and, over­all, the data pro­tec­tion process still doesn’t work very well. Why is this the case? Why is backup the job that no­body wants? Why do you even have to think about back­ups? Great ques­tions. While backup soft­ware and the de­vices we back up to have made sig­nif­i­cant im­prove­ments in ca­pa­bil­i­ties and ease of use, they still fail al­most as of­ten as they work.


The sin­gle big­gest chal­lenge to the backup process is not the size but the quan­tity of data. The size or amount of data that you have to pro­tect is clearly an is­sue, but it’s some­thing we have dealt with for years. Ad­dress­ing it means the con­stant up­grad­ing of net­work con­nec­tions, as well as faster backup stor­age de­vices.

The big­ger chal­lenge is the num­ber of files that need to be pro­tected. We used to warn cus­tomers about servers that had mil­lions of files; that is now com­mon­place. Now we warn cus­tomers about bil­lions of files. Back­ing up these servers via the file-by-file copy method com­mon in legacy backup sys­tems is al­most im­pos­si­ble. In many cases, it takes longer to walk the file sys­tem than it does to ac­tu­ally copy the files to the backup tar­get.


Vir­tu­al­iza­tion of servers, net­works, stor­age, and just about ev­ery­thing else brings sig­nif­i­cant flex­i­bil­ity to dat­a­cen­ter op­er­a­tions. It has also led to the cre­ation of an “app” men­tal­ity among users and line-of-busi­ness own­ers. Ev­ery­thing is an app now, and that means yet an­other vir­tual ma­chine cre­ated in the vir­tual in­fra­struc­ture. The growth rate of VMs within an or­ga­ni­za­tion af­ter a suc­cess­ful vir­tu­al­iza­tion roll­out is stag­ger­ing. All of these VMs, or at least most of them, must be pro­tected. While most, if not all, backup so­lu­tions have re­solved the is­sue of in-VM back­ups, few are deal­ing with the mas­sive growth of VM count. Of­ten each VM needs to be its own job, and that means man­ag­ing po­ten­tially hun­dreds of jobs.


These re­al­i­ties are com­pounded by the fact that user ex­pec­ta­tions are at an all­time high. They now in­ter­act with on­line ser­vices that ap­pear to never be down, and they ex­pect the same from their IT. In other words, re­cov­ery has to be in­stant. Even the time to copy data from the backup server may take too long.


The fix for all this may be to make pri­mary stor­age more ac­count­able for its own pro­tec­tion. Clearly it does that to some ex­tent al­ready, pro­vid­ing pro­tec­tion from drive and con­troller fail­ure. But given all the above chal­lenges, it also needs to pro­vide longer term, point-in-time data pro­tec­tion, so that if an ap­pli­ca­tion cor­rupts, you can roll back to a ver­sion you made a copy of an hour ago, in­stantly.

At the same time, data pro­tec­tion needs to change. We’ve seen in­tel­li­gence added to sys­tems so they can rapidly back up large file stores. We’ve also seen in­stant-re­cov­ery prod­ucts that al­low for a VM to run di­rectly from a backup. But there are chal­lenges with in­stant re­cov­ery that need to be ad­dressed, like how well that in­stantly re­cov­ered VM will per­form from a disk backup de­vice and how that VM will be mi­grated back into pro­duc­tion.

Ge­orge Crump

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.