A Nandroid backup is a complete image of your phone partitions. It captures the system and data and boot partitions in one operation. If a later change breaks the phone then you restore the backup. The phone returns to the captured state with apps and settings intact. That completeness is why Nandroid backups remain essential for modifiers.
Cloud backups and app backups cannot match this depth. They restore accounts and some app data but not the system itself. A Nandroid backup restores the operating system as it was. It is the closest thing to a time machine for your phone. Every serious flash should start with one.
What a Nandroid Backup Contains
The backup contains image files for each selected partition. System holds the operating system files and preinstalled apps. Data holds your apps and settings and personal files. Boot holds the kernel and boot configuration. Vendor and other partitions may appear depending on the device.
Some partitions are small and some are very large. Data is usually the largest because it holds your files. System size depends on the ROM and its included apps. Backup time grows with data size and storage speed. External storage often completes faster than slow internal storage.
Encryption affects what recovery can capture from data. If recovery cannot decrypt data then that partition may back up as raw encrypted content. Restoring such a backup still works on the same device setup. Moving it to another device may fail. Check decryption support for your build before you depend on data backups.
Preparing for a Clean Backup
Close nothing special before rebooting into recovery. Recovery runs outside Android so open apps do not matter. Charge the battery well and use stable storage with enough free space. A backup that runs out of space midway is useless. Free up room or choose larger external storage first.
Decide where the backup will live before you start. External SD cards are ideal when the phone supports them. USB drives work through OTG on many devices. Internal storage works but risks loss during a later wipe. A computer copy after the backup adds a second layer of safety.
- Check free space on the target storage before starting
- Select system and data and boot as the minimum set
- Add vendor and other partitions when recovery recommends them
- Name the backup clearly with date and ROM version
- Copy the finished backup to a computer for safekeeping
Creating the Backup Step by Step
Boot into custom recovery with the key combination for your model. Open the backup screen from the main menu. Select the storage location at the top of the screen. Then tick the partitions you want to include. Swipe to confirm and wait for the process to finish.
Do not interrupt the backup while it runs. Pulling the battery or forcing a reboot can corrupt the images. Watch the progress log for errors on any partition. A clean log with success messages means the backup completed. Note the folder name so you can find it during a restore.
After completion, verify the backup folder exists and has a sensible size. A tiny folder may mean partitions were skipped. A missing folder means the storage target failed. Fix storage issues now while the phone still works. A backup you cannot find during an emergency is no backup at all.
Storing and Managing Backups
Keep at least two backups when storage allows. One should capture a known good daily setup. Another should capture the state just before a risky change. Rotate old backups out as space fills up. Label folders so you never restore the wrong era by mistake.
Copy backups to a computer regularly for long term safety. Phones get lost and storage cards fail. A computer copy survives both problems. Use a clear folder structure with device codename and date. That structure saves frantic searching during a repair.
Backups also help when a phone enters a bootloop after a bad flash. Instead of rebuilding from scratch you restore a working image. You can read about recovering from bootloops with individual partition backups to see selective restore in action. Full backups and selective restores complement each other well.
Restoring a Backup Safely
Restoring is the reverse of backing up. Boot into recovery and open the restore screen. Select the backup folder you want to use. Tick the partitions to restore and swipe to confirm. The phone will overwrite those partitions with the saved images.
Restore only partitions you understand when mixing backups. Restoring system from one ROM and data from another can clash. Full restores from a single backup are the safest path. Selective restores suit cases where only one partition is damaged. When in doubt restore the whole set from one backup.
After restore, reboot and allow extra time for the first boot. Android may optimize apps and rebuild caches after a restore. A slow first boot is normal and not a sign of failure. If the phone loops after restore then recheck partition choices and backup integrity.
Common Backup Mistakes
The biggest mistake is storing the only backup on internal storage. A factory style wipe can erase that storage along with data. Another mistake is backing up after the problem already exists. A backup of a broken system restores a broken system. Always back up while the phone works well.
Skipping the boot partition is another common error. System without its matching boot image may not start. Include boot every time unless you have a clear reason not to. Also avoid renaming backup files inside the folder by hand. Recovery expects specific file names and a rename can break detection.
adb reboot recovery
adb pull /sdcard/TWRP/BACKUPS/device-id/backup-name ./backup-copy
adb shell ls /sdcard/TWRP/BACKUPS/The commands above show how to copy a backup to a computer over ADB. Paths differ by recovery and storage layout. Confirm the actual backup path in recovery before pulling files. A verified computer copy is the gold standard for backup safety.
Backup Strategy for Regular Flashers
Regular flashers should back up before every ROM change and kernel change. They should also back up before major module installs. Automated schedules do not exist inside recovery itself. The habit must be manual and consistent. A short checklist before each flash keeps the habit alive.
Pair backups with correct wiping for clean installs. You can review wiping system cache and data partitions correctly so restores and fresh installs do not clash. Good wiping plus good backups make flashing far less stressful.
Before a restore of a damaged system, also consider the broader repair path in restoring broken operating systems from saved image files for cases where a full backup is unavailable. That path covers image based repair beyond Nandroid folders.
Choosing Storage for Large Backups
Backup size surprises many first time users. A data partition full of photos and apps can span many gigabytes. Internal storage may lack room for a full backup plus daily files. External cards solve space problems on phones that support them. USB drives offer even larger capacity through OTG connections.
Speed also varies greatly across storage types. Fast external cards complete backups sooner than slow internal storage. Slow storage extends the window for interruption risk. A backup interrupted by low battery corrupts the whole set. Choose the fastest reliable storage available for large backups.
Storage reliability matters as much as capacity. Cheap cards can corrupt large files silently over time. A backup that looks complete may fail verification months later. Test restored backups occasionally on non critical occasions. Verification turns hope into confidence about backup health.
Backup Schedules That Actually Work
Recovery backups require manual boots into recovery. No schedule inside recovery automates that process. A personal routine must replace automation here. Tie backups to flash events rather than calendar dates. Every ROM change and kernel change deserves a fresh backup first.
Monthly baseline backups suit phones that change rarely. Capture a known good state on the first weekend each month. Store that baseline off the device for safety. Between baselines, back up before any risky change. That two layer routine balances effort and protection well.
Travel and major trips deserve an extra backup before departure. A phone failure far from home hurts more than one at home. A computer copy before travel adds resilience. Recovery from a travel failure then needs only a restore. Planning backups around life events beats rigid schedules.
- Back up before every ROM change and kernel change
- Keep a monthly baseline stored off the device
- Add an extra backup before travel or major updates
- Verify backup folders and sizes after each run
Verifying Backups Before You Trust Them
A backup folder that exists is not proof of a usable backup. Folder sizes and file counts give the first verification signal. Compare sizes with partition sizes for plausibility. A system backup far smaller than the system partition deserves suspicion. A data backup of zero size signals a failed capture.
Test restores on a non critical occasion when possible. Restore a small partition and confirm the phone still boots. That test proves the restore path works end to end. Testing during calm times beats testing during emergencies. Confidence comes from proven restores, not from backup folders alone.
Checksums for backup files add stronger verification when supported. Some recoveries generate checksums during backup creation. Verify those checksums after copying backups to a computer. A matching checksum proves the copy survived transfer intact. Mismatches mean the copy needs repeating before trust.
Backup Retention Decisions
Retention decisions balance storage space against safety depth. Keeping every backup forever fills storage quickly on large phones. Keeping only the newest backup risks losing a good older state. A practical rule keeps three backups at most times. Keep the newest backup plus the last known good baseline plus one pre change backup. Rotate the oldest out when a new backup proves itself. That rotation keeps protection current without endless growth. Review stored backups quarterly and delete obsolete eras confidently.
The steps above follow the approach described in the official developer documentation for this platform. That documentation explains partition imaging and backup concepts in general terms. It also covers storage handling that affects backup reliability. Combine it with recovery notes for your exact device build.
