System backup of Jetson nano orin?

I have spent much time installing the system with Jetpack 6/Ubuntu, and various pieces of software, on a Jetson Nano Orin with an SSD of 512 GB. I need to backup/clone the entire system together with all apps, and I searched the Internet but couldn’t find how to do it. I could easily clone the SSD in a separate cloning device, but as I understand it, that is not enough, because some software would also need to be reflashed to the eMMC? How do I proceed? I would hate to do it the hard way again, if the system crashes or the mains power line is hit by a lightning stroke :-)

Understand that Jetsons do not have a hardware BIOS, but do have the equivalent in software. That content is all “standard” so far as the flash software goes. If you have the SSD clone, and you were to flash again with the same release, but use the clone SSD, then this should restore. You had to do some extra steps to set up the SSD, and you’d simply repeat that and substitute your SSD (you would have performed an initrd flash). A partition or disk UUID might or might not require an edit, but a clone of the SSD would include all of the parts which are valuable.

You could also view the README file in “Linux_for_Tegra/backup_restore/README_backup_restore.txt”. There are scripts which do back up not just the rootfs, but all of the other content as well. Whatever you choose, do test it out.

1 Like

Thanks a lot for your quick and fine response, and sorry for being ignorant. So, as a beginning, if I buy an SSD NvME cloning device and clone the SSD, that I presently have in the Orin, then I should be sort of safe. Alternatively, I could buy an external USB SSD enclosure and then clone the Orin SSD using the Orin itself. To try it out, I would need to get another Orin, and then reinstall it and add the SSD? Is all that correctly understood?

In Windows, one can basically clone a HDD and keep it directly as a backup. It will work right away if you swap the HDDs. For the Jetson Nano Orin, one has to reinstall the operating system the hard way, and then add the cloned SSD? Is that correct?

The backup image would work on any same unit which has been flashed with the same L4T release. FYI, L4T is just what you call Ubuntu after it has the NVIDIA content added (JetPack/SDK Manager is just the flash front end software). You can find the L4T release with “head -n 1 /etc/nv_tegra_release”. Then you can go here to always get that exact release of flash software:
https://developer.nvidia.com/linux-tegra

If you use a newer JetPack/SDKM for the flash, then you can start it like this to see other releases:
sdkmanager --archived-versions

The trick is that if you then flash the new Jetson (or the same Jetson) in exactly the same way that you flashed the old one, then the disk will be interchangeable with the old one. An exception might be that you need to do a bit more work to set up the UUID for finding the partition. If your clone system recreates not only the content, but also the disk and partition UIDs, then you should be able to just interchange those disks.

Let’s say though that you ran into trouble. You could still flash the Jetson normally and then use rsync or a lot of other possible mechanisms to put the content back on to the running system. A clone is valuable even if it can’t directly boot (and with not too much effort it should be possible to directly boot your clone). Just don’t overwrite your clone.

So for the Jetson Nano Orin, more or less you do have to flash the old hard way, but you can then substitute your disk if the disk and partition IDs are correct.

That reminds me of something: On your running system you might want to save a copy of this output for future use to aid you in any restore (this is more than you would normally need, but trivial to get):

  • head -n 1 /etc/nv_tegra_release (very important, although this same info would be on the clone)
  • uname -r (useful when working on matching kernels).
  • lsblk -f -t (this will show all the UIDs).
  • A copy of “/boot/extlinux/extlinux.conf”.
  • Either ifconfig (older command I like better) or “ip -a -s addr” (newer command). This is for MAC address. Sometimes there are udev rules for networking which depend on MAC address. This wouldn’t change on the same Jetson, but it could change on a new Jetson. Very unlikely to need the info, but you might as well put it in a document and save that.

Thanks so much for the help (seems like you are a real person and not a bot :-) ). If I understand you correctly, the conclusion is that to use a cloned NVME SSD one must flash the same Jetson model with exactly the same version of L4T = Ubuntu+Jetpack/SDK.

With all due respect, maybe NVidia should think of an easy way to make a system backup, which is something all users need. I know an 80 years old lady, that herself easily migrated from one iPad to another. I am not suggesting anything like that for NVidia, but wouldn’t it be useful if one could easily clone the SSD and (re-)install L4T and the SSD?

Yes, if you flash a Jetson with the same exact release (and also the same flash parameters, e.g., an initrd flash naming the NVMe if that is the original flash), then this sets it up to use the same rootfs (and the rootfs is the o/s).

There is a backup and restore script. This script does back up the non-rootfs components too. Check this file:
Linux_for_Tegra/tools/backup_restore/README_backup_restore.txt

The clone of just the rootfs though is in fact useful and does not require the same storage space as backup of all of the non-rootfs content.


Long Trivia: Most of this difficulty and complication is due to not having an actual hardware BIOS. I have no doubt that a hardware BIOS would have (A) required more electrical power, (B) more physical size/space/volume, and (C) more cost. At the time the first Jetson came out (around 2013), this would have been more extreme than it is now (consider die size back then more problematic than now, but even now a smaller die size is more expensive). Before this NVIDIA also made other Tegra devices (I have an old Tegra 3 sitting here; the t30), and up until that point in time they only sold reference systems typically used by vendors to build their own system. The TK1 was something of an accident as it had originally been sold with the intent that it was for other people building their own designs (“other people” being businesses and not individuals). All of the Tegra products used U-Boot (or something a third party created), none had ever had a real BIOS, individuals did not buy any of the products directly from NVIDIA except if they were an NVIDIA partner or building their own custom NVIDIA-based product. The Jetson TK1 ended up being available on NVIDIA’s web site, and you didn’t have to be an NVIDIA partner (or even a business) to purchase one; it was an accident that so many non-business-integrators suddenly appeared as a market (this is prior to RPi, but similar to why and how RPi began its demand). The key point of all of that trivia is this: NVIDIA has reused parts of each of its Tegra systems since the first one, including the non-BIOS boot system (which was popular back in the beginning for most micro-controllers). By changing only parts of a die and keeping other parts which did not need an upgrade the same the time to market got shorter and the quality increased (those parts of the die could be considered a “unified driver” development).

And sometimes I do feel like a bot! I’m just glad AI has not yet discovered coffee. Java does not count.

One thing I will agree with is that if NVIDIA added a user-accessible actual hardware BIOS, then everyone’s life would be easier. Except of course more power would be consumed and cost would go up, and size would increase; however, we are at a point in the tech where this might be acceptable.