DataBackup for Android: a root-only backup tool built on a shell script

What DataBackup solves that Google's own backup does not

Android's built-in backup covers a narrow slice of app state, and the README does not claim otherwise for the platform. DataBackup takes the opposite position: it works at the level of the app's private data directory, which normally requires root to read and write. That is the whole point of the project. If you have ever moved to a new phone and found that a game save, a chat history or a locally stored database did not come along, that is the gap this targets.

The audience is correspondingly narrow. The first feature bullet in the README says root is needed, and it names Magisk, KernelSU and APatch as the supported root solutions. There is no non-root mode described. A second bullet lists multi-user support, which matters on tablets and on devices with a work profile. The project is written in Kotlin and licensed GPL-3.0, so anyone shipping a modified build takes on the copyleft obligations that come with that licence.

The lineage matters for judging the app. The README states it is based on speed-backup, a shell script by the CoolApk user 落叶凄凉TEL, and that the application was born with that author's consent. DataBackup is therefore a graphical front end over an approach that already existed as a script, not a new backup format invented from scratch. If you have used speed-backup, the mental model carries over.

How the backup and restore mechanism is put together

The repository layout is the clearest evidence of the architecture. There are two source trees, source/ and source-next/, plus top-level dex/ and build/ directories. A dex directory in an Android project usually means prebuilt or generated DEX artifacts are shipped or consumed rather than compiled from the Kotlin sources alone. That is consistent with a design where the heavy lifting happens in a privileged shell context and the Compose UI in source/ (the topics list compose) drives it.

The practical consequence is that DataBackup is not a self-contained sandbox. It depends on the root manager granting it elevated execution. The README lists Magisk, KernelSU and APatch as the supported options, and that list is a hard boundary: a device rooted some other way is not covered by the documentation.

Compression is the other visible mechanism. The repository topics include zstd, which indicates the archive format used for the backed-up payload. That choice favours speed over the maximum compression ratio you would get from a slower codec, which fits the project's stated emphasis on being fast. The README's claim of "100% Data Integrity" is a marketing line, not a specification; the README does not define how integrity is verified, so treat that bullet as a claim rather than a guarantee you can audit from the documentation alone. The cloud bullet is similarly terse, and the README does not describe which providers are supported.

Installing DataBackup and taking a first backup

There is no build-from-source tutorial in the README. Installation is presented as a download step: the README points to IzzyOnDroid and to F-Droid for the com.xayah.databackup.foss package, and says you can alternatively get the APK from the Releases page. The F-Droid link in the README is the zh_Hans listing, though the package itself is the same. No adb install command, Gradle task or version number is given in the README, so the honest instruction is to install the APK through one of those three channels and grant it root when the root manager prompts.

Once installed, the flow is app selection, then backup. Because the README does not document a command line, there is nothing meaningful to put in a shell block; the interface is the Compose UI shown in the screenshots under fastlane/metadata/android/en-US/images/phoneScreenshots/. What you should expect to see is a list of installed packages with their data sizes, and a per-app or bulk selection step before the archive is written.

If you prefer to confirm what you are installing before you run it, the repository gives you the material to do so: source/ and source-next/ hold the Kotlin, dex/ holds the prebuilt artifacts, and CHANGELOG.md records what changed release to release. Reading CHANGELOG.md before upgrading is the cheapest way to avoid a surprise, since the README does not maintain a compatibility matrix for archive versions.

The documentation site at DataBackupOfficial.github.io is where the README sends you for usage detail. The README itself is a feature list and a download page, and it does not cover restore procedure, archive compatibility or error recovery.

Where DataBackup is the wrong tool

The root requirement eliminates most users immediately. On a stock, locked-bootloader phone, DataBackup cannot run at all, and the README offers no fallback. If your goal is to move data off a device you cannot or will not root, this project is not a candidate, and the related searches about restoring from a Google backup describe a different mechanism entirely.

The second limitation is scope. DataBackup operates on apps and their data, not on a full block-level device image. If you want a bootable snapshot you can flash back after a failed ROM update, that is a recovery-image workflow, and nothing in the README describes DataBackup producing one. Multi-user support is listed, which helps on shared devices, but the README does not say how archives from one user profile behave when restored into another.

The third issue is verification. The README claims 100% data integrity but does not explain the check. There is no documented rollback procedure if a restore fails partway, and the README does not mention archive format versioning or forward compatibility. A backup tool whose restore path is undocumented is a tool you should test on disposable data before you rely on it, and the documentation gives you no way to skip that step.

DataBackup compared with script-based and ADB-based backup

The most direct alternative is the project DataBackup is derived from: speed-backup, the shell script by YAWAsau. The README states the app is based on it and was built with the original author's consent. The difference is the interface and the packaging, not the underlying idea. A script runs in a terminal, is edited as text, and can be dropped into automation. DataBackup wraps that into an APK with a Compose interface, which is easier to hand to someone who does not want to type commands, but harder to script or patch without rebuilding the app.

The other common approach is ADB-based backup, where a desktop pulls data over a USB connection using the platform's own tooling. That path does not require root, which is its main advantage, but it is also why it cannot reach the same private app directories. Choosing between them is really choosing between root access and desktop tooling; DataBackup sits firmly on the root side, and the README's first feature bullet makes that explicit.

One practical difference worth noting: because DataBackup uses zstd for its archives, the output is a compressed payload rather than a browsable file tree. The README does not document how to extract an archive outside the app, so if your recovery plan assumes you can open the backup on a laptop without DataBackup installed, that assumption is not supported by the README.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-19. The most recent release listed is 2.0.12 from 2025-09-20, preceded by 2.0.11 on 2025-08-21 and 2.0.10 on 2025-08-10. Those three releases span roughly six weeks, which suggests a period of frequent point releases, but the README does not describe a support policy, a release cadence or a deprecation window. The gap between the latest release and the most recent commit is something you can check yourself in CHANGELOG.md and the release list.

Upgrade cost is the real question for a backup tool. Installing a new version is cheap; trusting it with archives written by an older version is not, and the README says nothing about archive compatibility across 2.0.10, 2.0.11 and 2.0.12. The safe reading is that you should keep an archive you have already verified until you have confirmed the new build restores it.

The licence is GPL-3.0. If you fork DataBackup and distribute your build, the copyleft terms apply to what you distribute; if you only run it on your own devices, that obligation does not arise. This is a description of the licence, not legal advice, and the LICENSE file in the repository is the authoritative text. There is also a .gitmodules entry at the top level, which means at least one dependency is pulled in as a submodule and you will need to initialise submodules if you build from source.

Editorial conclusion

Adopt DataBackup if you already run Magisk, KernelSU or APatch and you need per-app data rather than a whole-device image. Do not adopt it if your device is unrooted, if you want a desktop-side backup pipeline over ADB, or if you need a documented rollback path, since the README does not document one. Before trusting it with anything irreplaceable, verify on your own device that the restore step actually writes back to the app you selected, and check the CHANGELOG.md for the behaviour changes between 2.0.10, 2.0.11 and 2.0.12.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. XayahSuSuSu/Android-DataBackup on GitHub