Android Backup in 2026: Local, Encrypted and No-Cloud Options

Google’s built-in backup is convenient, but it sends your app data, call history, contacts, and device settings to Google servers by default. For users running privacy-hardened ROMs, de-Googled devices, or anyone who simply does not want their data on third-party infrastructure, the question becomes practical: how do you back up an Android device reliably, with strong encryption, storing everything locally? In 2026 the answer is better than it has ever been - but the tooling is still fragmented enough to require deliberate planning.

Why “no cloud” is harder than it sounds on Android

Android’s backup architecture is deeply tied to Google’s services. The BackupManager API, which app developers use to persist settings and data across reinstalls, routes through Google’s servers by default. When you set up a new phone and restore from a backup, Google is acting as the broker.

On stock Android (AOSP builds, Pixel, Samsung One UI, etc.), you cannot fully bypass this without root. The system-level backup hooks simply do not expose a local target. The adb backup command, which used to be the standard power-user workaround, was formally deprecated starting with Android 12 (API level 31) and has had progressively reduced scope with each release since. As of Android 14-15, many apps explicitly block adb backup via the android:allowBackup="false" manifest flag or the newer android:dataExtractionRules mechanism.

This is not a dead end - it just means the strategy depends on what ROM you are running and whether you have root access.

SeedVault: the FOSS benchmark

SeedVault is an open-source, end-to-end encrypted backup application created by Torsten Grote and maintained by the Calyx Institute. It is the closest thing Android has to a privacy-respecting system backup, and it ships as the default backup provider on GrapheneOS, CalyxOS, and DivestOS.

Key properties:

• Encryption: AES-GCM-256 authenticated encryption. The backup key is derived from a 12-word BIP-39 mnemonic that you control entirely.
• Storage targets: USB flash drive, USB hard drive, or a Nextcloud instance (self-hosted). No Google, no Dropbox.
• Scope: installed apps and their data (via the standard BackupManager API), contacts, call log, device settings, Wi-Fi passwords.
• Verification: each backup is verified against a stored digest. SeedVault will warn you if a backup fails integrity checks on restore.

The limitation worth knowing: SeedVault relies on the same BackupManager hooks that Google uses. Apps that set allowBackup="false" - including most banking apps and many Google apps - will not be included in the backup. You get app data for cooperative apps, not a full partition image.

If you are on GrapheneOS or LineageOS, enabling SeedVault takes about three taps: Settings - System - Backup - Change backup provider - SeedVault. Point it at a USB drive, generate the mnemonic, and run your first backup. The mnemonic is the only key that can decrypt your data; store it offline in a physically separate location from the device.

ADB-based backup for stock Android users

For users on stock Android who cannot install SeedVault as a system app, adb backup still works in a reduced capacity as of Android 14-15, and adb pull remains fully functional for the /sdcard (shared storage) partition without root.

What you can pull without root:

# Back up shared storage (photos, downloads, documents)
adb pull /sdcard/ ./sdcard-backup/

# Export a specific app's shared storage directory
adb pull /sdcard/Android/data/com.example.app/ ./app-data/

This does not touch private app data stored in /data/data/. For that you need either root or a developer-mode backup from apps that explicitly enable it.

adb backup (legacy, limited):

adb backup -apk -shared -all -f backup_$(date +%Y%m%d).adb

The resulting .adb file is AES-256 encrypted if you set a password when prompted. However, many apps will be skipped. Treat this as a supplementary tool, not a complete solution. See our ADB commands guide for power users for the full syntax reference.

Encrypting what you pull:

Any data extracted via adb pull is unencrypted on your workstation. Pipe it through encryption before writing to external storage:

tar -czf - ./sdcard-backup/ | gpg --symmetric --cipher-algo AES256 -o sdcard-backup.tar.gz.gpg

Or use age (a modern encryption tool with a cleaner CLI):

tar -czf - ./sdcard-backup/ | age -p > sdcard-backup.tar.gz.age

Neo Backup: root-required, maximum coverage

For rooted devices, Neo Backup (available on F-Droid) is the most capable local backup tool available. It is a fork of OAndBackupX, actively maintained as of 2026.

Neo Backup requires root because it reads directly from /data/data/ (private app storage) and /data/app/ (installed APKs). This gives it scope that neither SeedVault nor ADB can match.

Features worth noting:

• Per-app backup scheduling (daily, weekly)
• Backup targets: local storage, external USB, or SFTP (self-hosted)
• AES-256-GCM encryption with a passphrase you set
• Batch restore with dependency ordering
• Differential backups (only changed files since last run)

The security caveat: root access is a significant attack surface. If your threat model includes malware that attempts privilege escalation, rooting introduces risk that may outweigh the backup benefits. For most privacy-focused users who are already on a hardened ROM, this tradeoff is acceptable - but it is worth reading through the Android privacy hardening checklist before deciding.

Comparison: backup methods at a glance

Method	Root required	App private data	Encrypted by default	Storage target	Stock Android
SeedVault	No (system app)	Partial (allowBackup=true only)	Yes (AES-GCM-256)	USB / Nextcloud	No
Neo Backup	Yes	Full	Yes (AES-256-GCM)	Local / SFTP	Yes (with root)
adb pull	No	No (/sdcard only)	No (manual step)	Workstation	Yes
adb backup	No	Partial	Yes (AES-256, password)	Workstation	Yes
TWRP full image	No (recovery)	Full	Optional	SD card / USB	Rarely

TWRP and full partition images

For devices with an unlocked bootloader and a TWRP-compatible recovery, a full NANDroid image (a complete copy of all partitions) is still the gold standard for disaster recovery. TWRP writes the image directly to external storage during recovery mode, bypassing the running OS entirely.

In 2026, TWRP device support has narrowed - the project has had intermittent maintenance activity and many recent Snapdragon 8 Gen 3/4 devices do not have official TWRP builds. OrangeFox Recovery is a maintained alternative for some devices. Check the TWRP device list and OrangeFox’s device database before assuming your device is supported.

A full partition image backup gives you byte-for-byte restoration capability but has practical limits: images are large (typically 20-80 GB depending on device storage), they are tied to the specific Android version and ROM they were made on, and restoring to a different ROM version requires careful partition matching.

Verification: a backup you have not tested is not a backup

This point is worth stating explicitly because it is where most backup strategies fail silently. Before you depend on any backup:

1. Restore to a secondary device or a factory-reset test environment.
2. Confirm that your key applications launch and retain their data.
3. Verify that encrypted archives actually decrypt with your stored passphrase - not from memory, but from the written/stored copy you would use in an emergency.

For SeedVault, the verify function is built into the UI. For ADB or Neo Backup archives, decrypt and extract to a temporary directory and spot-check a handful of app data directories.

Recommended workflow for privacy-focused users in 2026

If you are running GrapheneOS or CalyxOS: enable SeedVault pointing at a USB drive, schedule weekly backups, and store the mnemonic offline. Supplement with Neo Backup if you are rooted and need full app data coverage. This covers the vast majority of use cases.

If you are on stock Android without root: use adb pull for shared storage on a regular schedule, encrypt the output with age or GPG, and accept that private app data is not recoverable without a device restore from Google’s servers. The tradeoff is inherent to the stock ecosystem.

If you are on a rooted stock ROM: Neo Backup gives you full coverage. Combine with adb pull for shared storage to keep backup jobs fast (Neo Backup on shared storage is slower than direct adb pull).

Regardless of method, store at least one backup copy offline on physical media (USB drive kept away from the device) and one copy on a self-hosted server you control if your threat model permits network storage. The 3-2-1 rule (3 copies, 2 media types, 1 offsite) applies to Android backups as much as it does to any other data.

For further context on sideloading and managing apps outside Google Play as part of a privacy-oriented setup, the sideloading security guide covers APK verification and install hygiene that pairs well with a local backup strategy.

FAQ

Does SeedVault back up all apps, including banking apps?

No. SeedVault uses Android's standard BackupManager API, so any app that sets android:allowBackup="false" in its manifest - which includes most banking apps and the majority of Google's own apps - will be excluded. You get full coverage only for apps that explicitly opt in to the backup API. For complete app data coverage on cooperative apps, SeedVault is reliable; for banking or high-security apps, you will need to set up those accounts manually after a restore.

Can I use Neo Backup on a non-rooted phone?

No. Neo Backup requires root access because it reads directly from /data/data/ (private app storage) and /data/app/ (installed APKs), partitions that Android's permission model blocks from unprivileged processes. If your device is not rooted, your options are SeedVault (if your ROM includes it as a system app), adb pull for shared storage, or the limited adb backup command for apps that allow it.

Is adb backup still usable on Android 14 and 15?

In a reduced capacity, yes. The command was formally deprecated starting with Android 12 (API level 31), and each subsequent release has narrowed its scope further. Many apps block it via android:allowBackup="false" or the android:dataExtractionRules mechanism. As of Android 14-15, adb pull for /sdcard shared storage remains fully functional without root, but private app data in /data/data/ is not accessible through adb on a non-rooted device.

What is the safest way to store the SeedVault mnemonic?

Write the 12-word BIP-39 mnemonic on paper and store it in a physically separate location from the device - ideally fireproof and not in the same building. Do not store it digitally on the same device or any cloud service, since the mnemonic is the sole key that can decrypt your backup. Losing it means your encrypted backup is permanently unrecoverable. Some users keep a second paper copy in a separate secure location as an additional precaution.