English

Backing up app data in rooted phones: what's your experience?

I passed yesterday’s afternoon testing a dozen backup apps and unfortunately only AppWererabbit passed all the tests. It’s the only app that recorded owner ID and system permissions correctly in a tar backup file, and the only that restored them correctly. Other apps won’t record them, will record them wrongly, or won’t restore them correctly:

(a) One app (can’t remember its name) recorded owner ID with shortened numbers, so the restoring function was broken.
(b) Backup + App backup & restore records the system info correctly but restores it with added wrong permissions. Restored apps may work but system integrity is compromised.
(c ) MyBackup, Flash-bak Backup & Restore, Super Backup & Restore, Application Backup Pro, Backup Your Mobile, and Oandbackup, like many other backup apps, record app data but don’t record system permissions and owners for each directory and file, so restored apps won’t work most of the time, and system integrity is compromised.
(d) Titanium restored partially incorrect permissions, so its app data backups weren’t reliable. Besides, it uses a totally unnecessary nonstandard backup file wrapping that makes manual repair of backed up system info be a nightmare. It also crashed my System UI when backing up, what would occasionally lead to random reboots.
(e) Helium showed to be intrusive, finicky and unreliable as an app itself, I didn’t even bother to test its backup files.
(f) Ultimate Backup (or App Manager) recorded wrong owner IDs. Unnecessary to say that its restore function always failed. Maybe this bug is the reason why it was pulled out from app depositories, it would have been a good app otherwise.
(g) Swift Backup is Google account dependent: straight to the trash bin.

One of the downsides for me of AppWererabbit is that it doesn’t have scheduling for app data backups, so I do it manually with my weekly TWRP system image backup. The UI is also confusing, for example, install app from SD, an important function, is hidden in a long-press menu. Another install option appears in the top-right dot menu but it’s a paying option (no clue about the difference between the two). Restore data is on the general top-left menu list, instead of integrated with install app from SD. Messy, really. But at least it works.

I find it to be unacceptable that the Android platform offers such poor capabilities regarding backup management, and I put all the responsibility on Google for making it hard for users and developers to use anything else than their own servers to store user information. :rage:

3 Likes

Do you backup your apps to the internal storage and copy them to an external storage afterwards? I find this a little cumbersome. An option to directly export the backup to any URI would be perfect. As far as I can see, this is not possible with AppWererabbit, is it?

Although since you have to move the TWRP backup manually either, that’s indeed not too much extra work…

1 Like

My policy is to always have TWRP images and app data backed up in the SD card, job done for example by AppWererabbit, and on top of that I use SyncMe Wireless to incrementally transfer all backup files overnight from my SD card to my personal server, so I have a double layer of protection and keep a file history. Some files are stored incrementally on the server, for example, I have now an apk library with 2 thousand files that go all the way back to 2011.

2 Likes

Take into account that Android is quite a weird OS that —even based on Linux— can’t be considered plain Unix. In fact, filesystem Unix owners should not be backed up because they are specific of the current installation. These users are generated automatically when installing an app, and have the form uX_aY where X marks the Android user ID and Y is the app ID, by installation order. (This is right from Android 4.4)

So, you’ll se the trouble with this example: if I, main Android user of my Android phone (u0), backup an app (e.g. a79) and then restore it in a secondary Android user (e.g. u2) of another phone with more apps installed (e.g. 100)… then folders and files will be assigned to a Unix user (u0_a79) that doesn’t match what it should (u2_a101), opening up a door for potential security vulnerabilities (or, more probably because of SELinux/SEAndroid, instabilities and crashes).

TL;DR: Unix users for app data should be calculated at restore-time because they are generated at install-time depending of the system state.

Unix groups are permission-dependant, so same thing: should be calculated at restore-time.

App backup are a pretty hard thing to implement right because of platform architecture changes between Android versions and portability. That’s why some solutions use specific formats (like Titanium Backup) or append a manifest/log (like Oandbackup), IMO.

3 Likes

Thanks for this info. I’ll make a copy for my own reference. It appears then that different backup policies will lead to success or failure depending on the use of the backup, and it explains why many backup apps just choose to employ a generic owner with full permissions - this way the app will probably work in any device. But this is not really a good solution, it appears that some more specialized apps, for example with databases, won’t work unless the owner ID and permissions match some record that’s probably in the database or some other file. So the generic approach mentioned above doesn’t work, not to talk about compromising system integrity through generalized permission granting.
Having this in mind I’ll stick to AppWererabbit, at least I know what it does and I know that it always works on the device of origin, as long as app ordering hasn’t changed. If I need to change user, device, or do a full reinstall with new installation numbers, I can always change the relevant file info manually to fit the new installation.

Oandbackup work good on normal backups but do not work on special updates like Account and SMS. In my Opinion Oandbackup should Backup on both ways on the Filesystem and in the API way, so Oandbackup could use an alternate restore way if the preferred Way not work.

At moment, it seems that the development of Oandbackup is discontinued.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.