So I've got my LG34C (KitKat) all tarted up with daishi4u's boot and recovery images. And I've installed Link2SD, so now the bulk of my apps are installing to the Ext4 partition on the external SD card, which greatly extends the useful capacity of the internal storage. And I can do Nandroid backups and write them to the external SD card, even if the internal storage is jam-packed full.

So alles gezeichnet, ya? Wunderbar, except now I don't know whether Nandroid is following the links to the apps and data files the OS has stored on the Ext4 partition on the external SD, thinking it's internal, or do I now have to take extra measures to back up what the OS is storing in that partition? Which would be a PITA, because the Ext4 partition is not visible over a USB connection, even from a Linux PC.

I didn't deliberately keep the old backup so I could make this comparison, I just happened to not have deleted it. The "before" archive is the one on the left. "After" is on the right. Can you tell from this image (or your own personal knowledge) whether Nandroid is following those links?

The "after" backup obviously has quite a few files the "before" backup does not ('cache.*' and efs?.emmc.*). And the two seem to show more differences than I would have expected -- considering the installed apps in both cases are probably ~80% identical -- if it weren't following the links. Then there's the size. The "after" backup is slightly the larger, despite the fact there's on the the order of 1GB less in internal storage than there was "before."

So does this all add up to my external Ext4 partition being covered by the Nandroid back-up, or do I need to look to other measures to make sure both partitions on the SD card are protected?

No morbius, your backups are not including sdext2 partition. This version of TWRP does not know how to access it. I unpacked the recovery image, and sdext is not included in ramdisk/etc/recovery.fstab. The line to include would look something like:/dev/block/mmcblk1p2 /sd-ext ext4 defaults recoveryonlyBut I beleive that after altering, the image would either need to be re-bumped, or possibly completely compiled from source (and bumped?).

Thanks again for educating me, ibub. I wouldn't have known where to look for confirmation. Mercy beer cups!

I 'solved' my dilemma using Root Explorer's 'tar' function.

The problem was that, after adding daishi4u's boot image specifically so I could write Nandroid backups to the external SD card, I also installed Link2SD and moved all the apps I could to the SD card. Which essentially "broke" the Nandroid backup, because none of the apps that were moved to the SD card were included in it.

The question then became how to back up the app and data files that Link2SD had moved to the external SD card. That partition is not visible by USB, not through Windoze and not through Linux. So I was thinking the only way would be to remove the SD card from the phone and plug it in to a card reader on my Linux PC and let it read (and back up) the Ext4 partition natively. And turning off the phone to remove the SD card every time I wanted to make a backup didn't seem too conducive to keeping comprehensive back-ups.

Then I had a face-palm moment. "Bonehead!! Android is a Linux OS. Use the native back-up tools, you moron!!" So I used the 'tar' command (which happened to be BusyBox's) and wrote a tarball of /data/sdext2 (which is how my phone has named the Ext4 partition on the external SD card) to the Fat32 partition. Great! Wunnerful. Except, why is the (compressed) tarball ~3gb when the raw files are only about half a gig?

So I tried again using Root Explorer's 'tar' function. The down-side was it wrote the tarball to an internal folder, which means that process is forever dependent on the internal SD having a significant amount of free space. The good news is it was only ~300mb. I just moved it to the Fat32 partition and then transferred it to long-term storage via USB connection.

So for as long as I can manage to keep, say, 1/2 gb free space in internal storage (which is looking pretty good right now, because there's close to 1 gb free, and this is what I'd rate as a "mature" installation), I'm golden.

WOW! Now I'm learning from you. I wonder about the 3gig tar file. Might use tar --h to see a list of available options and switches. Some other archive tools (gzip, etc.) will both create archive, or extract, depending on the switch used. I am suspecting that the busybox tar may have actually "extracted" your sdext partition. The other possibility might be that it saved a whole lot of zeros by copying the whole partition.EDIT: Yeah, here are all the options for the busybox tar: u0_a101@w3c:/ $ tarBusyBox v1.23.1-Stericson (2015-02-06 13:50:32 EST) multi-call binary.

1|u0_a101@w3c:/ $I think you could use something like: tar -cz /data/sdext/* /storage/external_SD/twrp/backups/123abcxyz/sdext.tarOr something similar. You also will not have an md5 file for this part of your backup, so a successful restore would require you to not use checksum option (unless you can make one in the format used by your recovery).EDIT: OOPS, the path that I used into twrp folder will not allow twrp (as it is) to restore this partition. But you know what I meant. Guess I really need to find time to add this feature and recompile recoveries.