A Nandroid backup is a full snapshot of the device's partitions taken from custom recovery, distinct from a cloud backup or an ADB pull of app data. It is the safety net that makes flashing a new ROM or kernel low-risk: if the flash goes wrong, restoring the Nandroid puts the phone back to exactly the working state it was in before, down to the partition level.
By default TWRP offers separate checkboxes for each partition, and it matters which ones are ticked:
adb reboot recovery if already rooted and running a custom recovery).TWRP stores backups under /sdcard/TWRP/BACKUPS/<device-serial>/ by default. Copy this folder off the device immediately after backing up — a Nandroid stored only on internal storage does not survive a full data wipe, which defeats the entire purpose of having taken it in the first place.
On seamless-update A/B devices, TWRP support is inconsistent between manufacturers, and a Nandroid taken on one active slot can fail to restore cleanly if the device has since switched slots following an OTA update. Before restoring on an A/B device, check which slot is currently active with fastboot getvar current-slot and, where TWRP's build for that device supports it, restore to the matching slot rather than assuming slot A by default.
The EFS partition stores IMEI, baseband calibration data, and radio provisioning specific to that individual physical unit, not to the firmware version. Restoring an EFS backup taken on a different physical device, or restoring one after a factory reset that corrupted the current EFS, can result in loss of cellular signal or an invalid IMEI. Back up EFS separately from the general Nandroid workflow and treat it as a distinct, higher-stakes operation — not something to restore casually alongside System and Data.
The most common restore failure is running out of free space on the Data partition mid-restore, because TWRP needs enough temporary space to unpack the backup archive before writing it in place. If a restore aborts with a "failed" status, check available free space first with TWRP's file manager before assuming the backup itself is corrupted; a partial restore in this state can leave the device unbootable, at which point restoring again from the same backup (once space is freed) resolves it in the large majority of cases.
On Android 10 and later using file-based encryption, restoring a Data backup taken under a different lock screen credential (PIN, pattern, or password) than the one currently set can leave some app data encrypted and inaccessible until the original credential is re-entered. Where possible, restore a Data backup only onto a device using the same lock screen credential it was taken with.
Copying a large Nandroid folder over a slow file manager transfer is unnecessarily painful; ADB pulls the same folder much faster over USB:
adb pull /sdcard/TWRP/BACKUPS/ ./local-backup-folderThis works from either TWRP's own ADB sideload mode or a normally booted device with the folder still present on internal storage, and is generally the fastest way to get a multi-gigabyte Data backup off the phone without needing a card reader or cloud upload step.
A Data partition backup can approach the actual used storage size of the phone, so a device with 100GB of installed apps and media needs roughly that much free space available to TWRP for the backup itself, on top of whatever internal storage the phone already has in use. Attempting a full backup on a nearly-full device is a common cause of a backup that reports success but is actually silently truncated, since TWRP does not always surface a clear out-of-space error mid-write on every build.