Mobile Only: Week 28
Benjamin Robbins, an EMF member, is spending the next year working solely from a single mobile device. Each week he shares his thoughts and experience with us on what it means to be mobile-only.
Last week I catalogedthe different aspects of my mobile device that would need to be backed up to perform a complete restore. It was a more extensive list than I expected, but I wanted to be able to match the list with the solutions I’ll be looking at. In terms of being able to restore a device, the best-case scenario would be to take a brand-new device off the shelf and in a single process be able to restore the entire device’s experiences, apps to .zips (files).
With my device currently in a rooted state, I thought it would be an excellent time to look at native apps that can perform system restore. Many system restore apps require the device to be rooted. Rooted devices can grant Superuser (administrator) rights to apps on the device. This allows the device to have an elevated security context in order to perform low-level system functions. This is incredibly helpful when many of the settings that you want to back up and restore are low level in nature.
On Tuesday CyanogenMod announced a build of Jellybean for the Phablet, the Samsung Galaxy Note. These monthly builds, dubbed experimental, presented the perfect opportunity to take a native app or two for a test spin and see what the result would be. As well, I‘ve been itching to test out Android’s latest operating system, Jellybean, on my device. The combination of already being rooted and wanting to try out a new build was too tempting to pass up.
After a little bit of research, I decided to try out the app Titanium Backup Pro. This app, and others as well, allows users to back up such things as apps, system data, Bluetooth pairings, call logs, even alarms. The list of possible backup items is impressive to say the least. Backups can be done on-demand or scheduled. The backup can be automatically synced with cloud services such as Box or Dropbox. The backup files can be encrypted as well. This particular app even has a “Chuck Norris” mode, which allows the app to forcibly remove specially protected apps. (Sidebar… Favorite Chuck Norris joke: They named a street after Chuck Norris but had to change it because cause no one crosses Chuck Norris and survives. Honorable mention: Death had a near-Norris experience.)
From the app, I ran the backup for all apps and system data on my device. It completed in a few minutes. Once the backup was complete I gave the device to IT to flash it to Jellybean. Unfortunately, before we could even attempt to perform the restore on the new version there were several issues with the connection to the carrier that made it not a viable solution. With that short-lived update, the device was rolled back to the previous OS, a newer build of Ice Cream Sandwich.
Now that the rollback was complete, the moment of truth arrived. Could the app restore my device back to the state it was in or was I spending the next few hours/days being angry with myself for being so cavalier with flashing the ROM to another OS version? I selected restore and crossed my fingers. A few minutes later the process completed and suggested a reboot, which I did.
The result? All of my apps, data, and settings came back to life in the exact state they were previously in. It even prompted me to change my device ID to its previous one so that there wouldn’t be any issues with app and licenses. There was only one minor issue. The widgets I had set up on my home screen were not restored but could be quickly added back. I imagine I just missed a checkbox somewhere for this to happen.
So while my experiment was a success—I can wipe/lose a device and pick up right where I left off—it poses several challenges for the enterprise. First, this app is a point solution that is not managed globally. It is an app geared toward an individual device, specifically Android. Enterprises would need to identify other apps for each platform and manage them separately. This is time consuming and should be handled by a central administrative interface.
The second reason that an isolated app for backup and recovery doesn’t make sense for the enterprise is that this type of recovery is only possible on a rooted device. This is a red flag for the enterprise for several reasons. Android is fragmented enough. Enterprises don’t need the added headache of the variation presented by the number of available ROMs out there. Also, a rooted device gives the average user administrator privileges. This is not best practice. Rooting devices also takes a level of expertise that most organizations don’t have and shouldn’t support. Lastly, there are security risks for the unsuspecting user with that much access on their device.
So why bother exploring and discussing this option at all if it is out of bounds for the enterprise? It is important to examine because the functionality provided by these backup-and-restore apps has many real-world use cases that enterprise mobile management solutions should support. If this type of recovery represents the fullest kind of recovery, how close can other enterprise mobility management solutions come to replicating it? The fact that I didn’t lose any apps, configurations, or data meant I was productive with as little interruption as possible. There are lots of nooks and crannies in between apps and files that are worth trying to capture as part of your mobile backup/recovery strategy.
Benjamin Robbins is co-founder and Principal at Palador, a firm that focuses on providing strategic guidance to enterprises in the areas of mobility, apps, and data. You can follow him on Twitter. Mr. Robbins resides in Seattle and blogs regularly at http://remotelymobileblog.com
Mobile Backup and Recovery – The Nooks and Crannies
Mobile Only: Week 28
Benjamin Robbins, an EMF member, is spending the next year working solely from a single mobile device. Each week he shares his thoughts and experience with us on what it means to be mobile-only.
Last week I catalogedthe different aspects of my mobile device that would need to be backed up to perform a complete restore. It was a more extensive list than I expected, but I wanted to be able to match the list with the solutions I’ll be looking at. In terms of being able to restore a device, the best-case scenario would be to take a brand-new device off the shelf and in a single process be able to restore the entire device’s experiences, apps to .zips (files).
With my device currently in a rooted state, I thought it would be an excellent time to look at native apps that can perform system restore. Many system restore apps require the device to be rooted. Rooted devices can grant Superuser (administrator) rights to apps on the device. This allows the device to have an elevated security context in order to perform low-level system functions. This is incredibly helpful when many of the settings that you want to back up and restore are low level in nature.
On Tuesday CyanogenMod announced a build of Jellybean for the Phablet, the Samsung Galaxy Note. These monthly builds, dubbed experimental, presented the perfect opportunity to take a native app or two for a test spin and see what the result would be. As well, I‘ve been itching to test out Android’s latest operating system, Jellybean, on my device. The combination of already being rooted and wanting to try out a new build was too tempting to pass up.
After a little bit of research, I decided to try out the app Titanium Backup Pro. This app, and others as well, allows users to back up such things as apps, system data, Bluetooth pairings, call logs, even alarms. The list of possible backup items is impressive to say the least. Backups can be done on-demand or scheduled. The backup can be automatically synced with cloud services such as Box or Dropbox. The backup files can be encrypted as well. This particular app even has a “Chuck Norris” mode, which allows the app to forcibly remove specially protected apps. (Sidebar… Favorite Chuck Norris joke: They named a street after Chuck Norris but had to change it because cause no one crosses Chuck Norris and survives. Honorable mention: Death had a near-Norris experience.)
From the app, I ran the backup for all apps and system data on my device. It completed in a few minutes. Once the backup was complete I gave the device to IT to flash it to Jellybean. Unfortunately, before we could even attempt to perform the restore on the new version there were several issues with the connection to the carrier that made it not a viable solution. With that short-lived update, the device was rolled back to the previous OS, a newer build of Ice Cream Sandwich.
Now that the rollback was complete, the moment of truth arrived. Could the app restore my device back to the state it was in or was I spending the next few hours/days being angry with myself for being so cavalier with flashing the ROM to another OS version? I selected restore and crossed my fingers. A few minutes later the process completed and suggested a reboot, which I did.
The result? All of my apps, data, and settings came back to life in the exact state they were previously in. It even prompted me to change my device ID to its previous one so that there wouldn’t be any issues with app and licenses. There was only one minor issue. The widgets I had set up on my home screen were not restored but could be quickly added back. I imagine I just missed a checkbox somewhere for this to happen.
So while my experiment was a success—I can wipe/lose a device and pick up right where I left off—it poses several challenges for the enterprise. First, this app is a point solution that is not managed globally. It is an app geared toward an individual device, specifically Android. Enterprises would need to identify other apps for each platform and manage them separately. This is time consuming and should be handled by a central administrative interface.
The second reason that an isolated app for backup and recovery doesn’t make sense for the enterprise is that this type of recovery is only possible on a rooted device. This is a red flag for the enterprise for several reasons. Android is fragmented enough. Enterprises don’t need the added headache of the variation presented by the number of available ROMs out there. Also, a rooted device gives the average user administrator privileges. This is not best practice. Rooting devices also takes a level of expertise that most organizations don’t have and shouldn’t support. Lastly, there are security risks for the unsuspecting user with that much access on their device.
So why bother exploring and discussing this option at all if it is out of bounds for the enterprise? It is important to examine because the functionality provided by these backup-and-restore apps has many real-world use cases that enterprise mobile management solutions should support. If this type of recovery represents the fullest kind of recovery, how close can other enterprise mobility management solutions come to replicating it? The fact that I didn’t lose any apps, configurations, or data meant I was productive with as little interruption as possible. There are lots of nooks and crannies in between apps and files that are worth trying to capture as part of your mobile backup/recovery strategy.
Benjamin Robbins is co-founder and Principal at Palador, a firm that focuses on providing strategic guidance to enterprises in the areas of mobility, apps, and data. You can follow him on Twitter. Mr. Robbins resides in Seattle and blogs regularly at http://remotelymobileblog.com