A nandroid backup is a full device backup – so you could ask the same question about a full backup of your PC: After restoring the backup, you'd be at exactly the state the device was in when you performed that backup – all changes done between making the backup and restoring it are lost.
Reading between the lines of your question, you're rather asking how a Nandroid backup works or what its pros and cons are. There were some changes in the past years, and I don't know to which custom recoveries they apply (I can only speak for clockworkmod for long-term and twrp for, say, the last year. So let me sum up:
In the past …
- Nandroid backups were created as partition images
- there was one image per partition (relevant partitions only, of course)
- those image files were uncompressed 1:1 blockwise copies of the corresponding partitions
2012 example from my Motorola Milestone 2:
-r-xr-xr-x 1 8388608 Apr 29 2012 boot.img
-r-xr-xr-x 1 10560 Apr 29 2012 cache.img
-r-xr-xr-x 1 346287744 Apr 29 2012 data.img
-r--r--r-- 1 288 Apr 30 2012 local.prop
-r-xr-xr-x 1 132 Apr 29 2012 nandroid.md5
-r-xr-xr-x 1 301956864 Apr 29 2012 system.img
2010 example from my "good old" HTC Buzz:
-r-xr-xr-x 1 2883584 Okt 23 2010 boot.img
-r-xr-xr-x 1 12672 Okt 23 2010 cache.img
-r-xr-xr-x 1 112421760 Okt 23 2010 data.img
-r-xr-xr-x 1 222 Okt 23 2010 nandroid.md5
-r-xr-xr-x 1 4325376 Okt 23 2010 recovery.img
-r-xr-xr-x 1 213227520 Okt 23 2010 system.img
These two have been created by CWM. So you see, at least from 2010 to 2012 this was what Nandroid did.
As these were full disk images ("physical copies", 1:1 block-wise), restoring them of course meant all contents on the target lost and replaced by the backup, which was restored block-wise as well. Both above nandroids were created by CWM.
Nowadays …
… things are a little different:
- Nandroid backups are mostly created as tarballs, i.e. logical copies of all files of a partition
- There's one tarball per (relevant) partition, often with the exception of
/boot
which remained an image copy
- those archives are uncompressed
2015 example from my LG P880, created by CWM as well:
-r-xr-xr-x 1 10485760 Mai 29 22:48 boot.img
-r-xr-xr-x 1 0 Mai 29 22:50 cache.ext4.tar
-r-xr-xr-x 1 23040 Mai 29 22:50 cache.ext4.tar.a
-r-xr-xr-x 1 0 Mai 29 22:49 data.ext4.tar
-r-xr-xr-x 1 650801664 Mai 29 22:50 data.ext4.tar.a
-r-xr-xr-x 1 390 Mai 29 22:52 nandroid.md5
-r-xr-xr-x 1 10485760 Mai 29 22:48 recovery.img
-r-xr-xr-x 1 136590 Mai 29 22:52 recovery.log
-r-xr-xr-x 1 0 Mai 29 22:48 system.ext4.tar
-r-xr-xr-x 1 947858944 Mai 29 22:49 system.ext4.tar.a
2015 example from my Motorola Milestone 2, this time done with TWRP:
-r--r--r-- 1 247035904 Sep 6 23:14 data.ext3.win
-r--r--r-- 1 48 Sep 6 23:14 data.ext3.win.md5
-r--r--r-- 1 104 Sep 6 23:39 _original_dir_name
-r--r--r-- 1 184842 Sep 6 23:14 recovery.log
-r--r--r-- 1 287747072 Sep 6 23:15 system.ext3.win
-r--r--r-- 1 50 Sep 6 23:14 system.ext3.win.md5
In both cases, we now have .tar
files for normal partitions (don't ask me why TWRP names them .win
), and disk images for /boot
and /recovery
. Note that TWRP forgot to backup these two partitions; I'd count that a bug, but specific to the build used here (I didn't decide to switch to TWRP, it simply came with the CyanogenMod ROM).
Other notes
The original "physical copies" (aka "disk images") had a big advantage: if you accidentally deleted something from your device, you could use file-carving technologies on the Nandroid images to get it back (see our data-recovery tag-wiki). This no longer works with tarballs. But tarballs can be restored even after partition resizing – while restoring an image file results in the same partition size (and fails if e.g. the partition got smaller). Also, switching to tar made the backups somehow "independent" from the file system – so you could back-up ext3 and restore to ext4 without having the partition put back to ext3.
On the other hand, there's one thing which got easier with tarballs: Looking inside them to retrieve a file or easily evaluate the structure on your PC. Not that I'd count this as a "big pro": with the correct tools (here: TestDisk) one can do the very same with images. It just takes a little longer, as TestDisk needs to investigate the structure (partition type, file system) before contents can be accessed.
As for restore, there should be almost no difference from the "users experience with results":
- restoring an image overwrites the entire partition, restoring each block as it was before (including "bad blocks")
- just unpacking a tarball wouldn't overwrite "new files", so this could result in a mess; I'm confident Nandroid takes care for this by wiping the target partition first
- another minimal pro of the tarballs: restoring such a Nandroid implicitly includes a "defrag", with files being written sequentially and without any delete in between ;)
My personal opinion is: Nandroids are backups. Backups are meant to be restored from in cases of emergency. Thus, while the Tar archieves have their conveniences, disk images are preferable – as one can use file-carving to even restore deleted stuff. But pros and cons are rather subjective.
Verdict
Though there might be "subtle differences" (as e.g. the now "defrag'd" partitions if your Nandroid used tarballs), there are no differences the "normal user" should notice. As Nandroid backups always include the entire partition, everything gets backed up and such restored – including "root and his files".