You will see many partitions listed if you run “sudo gdisk -l /dev/mmcblk0”. The “APP” GPT label (mmcblk0p1) is the rootfs and will be almost the entire disk…the rest will contain a number of partitions supporting boot, e.g., device tree and U-Boot. Cloning gives you both a loopback mountable 30GB “.raw” partition copy, plus the (essentially) compressed non-raw sparse image.
The cloned image can be loopback mounted, files copied, edited, and restored with edits back into the APP partition. The sparse image is much faster to restore, but cannot be mounted or edited. I throw this one out and save a “bzip2 -9” compressed version of the raw image.
The clone is an exact bit-for-bit copy of the APP partition…this is exactly what you’d get with a dd copy of the partition if the partition is not mounted during the dd (this is the trick of backing up any rootfs…copying it while it is changing is problematic and typically done under a rescue disk boot…clone is essentially a rescue disk for some limited operations).
The rootfs may have some dependencies on boot environment. Thus the other smaller partitions from one release of L4TG may not mix with a given rootfs. If you cloned from an R28.1 Jetson, then you can be guaranteed to restore to an R28.1 Jetson will work. If you cloned from an R28.1 Jetson, then you can bet there will be unknown problems restoring into an R28.2 Jetson…those other partitions will no longer match as a unified release revision. This is not useless because you can still copy the loopback mounted clone’s non-boot information (say for “/home” or for “/usr/local”) into the “rootfs/” subdirectory and each flash will get those updates even with the newer revision.