When Protecting Mobile Devices, We Need More Zombies

If you're backing up Android and iOS phones and tablets using the same paradigm as PCs, you're not using your brains.

Kurt Marko, Contributing Editor

July 13, 2012

5 Min Read

Charged with backing up smartphones and tablets? We've seen this movie before, and it made The Walking Dead look like wholesome family fun. Protecting client devices has always been a miserable, thankless task. Sure, products like Backup Exec, Retrospect and Acronis have brought the situation somewhat under control with PCs, but data management, especially when dealing with thousands of systems, is still mind-numbing.

And now along comes a sequel even more terrifying than the original.

Mobile devices are becoming as common in the office as laptops and gradually filling with work-related information. Our most recent InformationWeek Mobile Device Management Survey found that in 55% of the responding organizations, more than half of the employees use smartphones. While tablet adoption still lags, it's catching up. Our report on the new iPad found 42% of respondents plan to increase use of Apple products, which in the enterprise primarily translates to the iPhone and iPad, while 22% think their end users will want one of the new tablets. In sum, at the current trajectory of adoption, expect the proliferation of mobile devices to reach Windows-like levels of saturation in the next few years.

Data protection vendors are replaying a strategy they perfected with PCs more than a decade ago by treating smartphones and tablets as just another set of target devices and modifying client backup suites to fit their peculiarities--in other words, trying to perpetuate the traditional PC backup approach using a client-server architecture with a local software agent on each device, feeding data to central servers and storage arrays. But the problem is, backup technology for smartphones and tablets is far from mature, as our recent report on backing up Android and iOS devices found. Choosing any of these products involves compromise, and none is a great fit for every situation.

Perhaps there's a better, simpler, sort of "less is more" way.

Disposable Devices Don't Need Backing Up

In a prior life as a senior IT engineer at Hewlett-Packard, we faced a similar set of client management and data protection problems as the company replaced terminals and minicomputers with networked PCs and client-server applications. Trying to support thousands of systems on one large site, much less many times that worldwide, was a daunting task. Given the pathetic state of centralized PC management and backup software at the time, no doubt reinforced by HP's engineering, DIY culture, we ended up developing our own system architecture and automation tools--a project known as PC-COE, which the company even toyed with commercializing. While dreams of productization soon died, the design philosophy seems apt for today's MDM and backup conundrum.

PC-COE essentially treated every system as disposable. We built and deployed standard system images--every new machine got reimaged before the employee ever touched it--and carefully segregated all system customization and employee data from the base OS and core applications. Everything that made a PC unique, from the employee's login profile to user files, lived on central servers, meaning (a) we never had to back up local machines, and (b) we could quickly replace failed hardware without disrupting the employee's day, just by reimaging a disk and remounting the file shares.

In other words, the device's central nervous system is intact, but the intelligence is elsewhere.

This client management and data protection model is an even a better fit with mobile devices in our consumerized, bring-your-own-device era. Here, IT has no control over the client OS, meaning if an employee loses or bricks a device, it's up to the carrier (typically for Android phones) or hardware vendor (Apple devices and Android tablets) to provide the base OS. The role of MDM or automation software (like Apple's Configurator [PDF]) is simply to quickly deploy standard configurations, not entire systems.

But what about data? Here the PC-COE philosophy means keeping all corporate data off the client. This is easy for email and calendars, the two most commonly used enterprise apps on mobile devices, but in reality, it shouldn't be any harder for other application categories like business intelligence, CRM or collaboration, given that multitier software architectures already segregate access and display from application logic and data. Sure, employees will download file attachments and may even have persistent local copies, such as when an iPad user copies a PDF from the Mail app to iBooks, but that doesn't mean IT needs to back it up, since the originals are still sitting on a central server. Yes, there may be corner cases when an employee modifies or annotates a local copy without emailing or sharing it (in which case the modified version would once again be centrally stored) and then loses the phone, but does guarding against such exceptions justify deploying an entire new backup system?

Thus, one solution to the mobile backup problem is to eliminate it, an approach that has several ramifications:

-- Ensuring that mobile-enabled enterprise applications don't locally store information;

-- Having some method, either a full-blown MDM system, Exchange ActiveSync or Configurator-like automation tools, of rapidly and consistently customizing device configurations;

-- Ensuring that VPNs work with mobile clients (L2TP is the most broadly supported); and

-- Configuring a means of wiping lost devices, either remotely via MDM or a simple service like Find My iPhone, or locally using OS self-destruction after so many invalid PIN attempts.

Maybe the smartest way to protect mobile devices is to just make them disposable.

Read more about:

20122012

About the Author(s)

Kurt Marko

Contributing Editor

Kurt Marko is an InformationWeek and Network Computing contributor and IT industry veteran, pursuing his passion for communications after a varied career that has spanned virtually the entire high-tech food chain from chips to systems. Upon graduating from Stanford University with a BS and MS in Electrical Engineering, Kurt spent several years as a semiconductor device physicist, doing process design, modeling and testing. He then joined AT&T Bell Laboratories as a memory chip designer and CAD and simulation developer.Moving to Hewlett-Packard, Kurt started in the laser printer R&D lab doing electrophotography development, for which he earned a patent, but his love of computers eventually led him to join HP’s nascent technical IT group. He spent 15 years as an IT engineer and was a lead architect for several enterprisewide infrastructure projects at HP, including the Windows domain infrastructure, remote access service, Exchange e-mail infrastructure and managed Web services.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights