If you are using Linux, then this is trivial. The “dd” tool can copy and restore exact images from one SD to another. The image can be loopback mounted and edited if desired (for example, a pure clone would have the same user accounts and passwords…perhaps you don’t want that…or if there was a network customization based on MAC address, then you’d need a new MAC address for each Jetson).
As background, if you have a disk drive or other bulk storage device, then there will be a corresponding device special file for the disk (or SD card) as a whole, and for each partition. If we were speaking of an ordinary SATA drive, then you would see entries from this:
…where “sda” is the first disk, “sdb” is the second disk, so on. “sda1” is the first partition of the first disk, “sda2” is the second partition of the first disk. “lsblk -f” would give information about UUIDs and filesystem types of the whole list of detected block devices, “lslbk -f /dev/sda” would limit the response to the first SATA drive.
SD cards tend to have a naming convention like “/dev/mmcblk0” (first SD) or “/dev/mmcblk1” (second SD), or “/dev/mmcblk0p1” (first partition of first SD).
One could create a perfect bit-for-bit exact clone of the entire first SD via:
sudo dd if=/dev/mmcblk<b>0</b> of=clone_of_SD.img bs=512
(“bs” is block size, and isn’t critical, but can change how fast reads and writes go…512 is just the smallest block size of any disk, you could use a much larger value if it speeds things up)
This would restore the image to the second SD card:
sudo dd if=clone_of_SD.img of=/dev/mmcblk<b>1</b> bs=512
This would mount the clone for examination or editing:
sudo mount -o loop clone_of_SD.img /mnt
# Examine, edit, whatever you like:
# Exit the mount area, else you cant unmount (umount):
“dd” can be slow for production, but as mentioned the “bs” (block size) can speed things up somewhat. There isn’t much you can do about slow SD cards being slow.
NOTE: You do not want to clone a mounted filesystem which might be written to during the clone.