I have a Jetson Orin Nano with a 128GB nVME and I would like to backup the entire drive in case I screw something up so I can quickly restore to the last working state.
Ideally I’d like to backup the drive over a USB cable connecting the Jetson Orin Nano to a host machine with Ubuntu 20.04 and then I can restore it with the same method.
Was also thinking to detach the nVME drive from the dev board and stick it to an nVME reader and dd the entire drive with above host machine, not ideal but will that work?
Check your L4T release version with "`head -n 1 /etc/nv_tegra_release`". L4T is Ubuntu plus NVIDIA drivers, and is what actually gets flashed. Then go to the URL for your L4T release:
[https://developer.nvidia.com/linux-tegra](https://developer.nvidia.com/linux-tegra)
When you install the flash software (JetPack/SDK Manager are front ends to the flash software) it will create: ~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/
Note that if you need an earlier release of L4T a newer JetPack/SDKM can see it via: sdkmanager --archived-versions
So on the case of ‘dd’ - will a host machine with Ubuntu 20.04 see all the partitions of the nVME drive if I boot the Jetson Orin Nano into recovery mode with the jumper pins? Essentially use the Jetson Orin Nano on a dev board as a USB3 nVME reader?
Sorry, I think I was seeing a different thread at the same time (that was an accidental paste from another reply). However, you do want the same L4T release in any flash since the NVMe is not the only software flashed. The --archived-version still applies when flashing clones (the L4T flash software release does not much matter while cloning, but it should match during restore).
Additional information related to what @DaveYYY is mentioning: The actual boot software, along with the “equivalent” of what a BIOS does, won’t exist on the NVMe itself. In the case of eMMC models this would be in other eMMC partitions. In the case of dev kits which have the SD card on the module itself that content is in the QSPI memory of the module. Drivers for the NVMe must exist in those early boot stages in order to load from the NVMe. Quite often the early boot code will load the Linux kernel from some device it understands, and then load an initial ramdisk (initrd) which contains a very minimal rootfs (one that includes NVMe and filesystem drivers). It then becomes the job of the Linux kernel and initrd to pivot to the new NVMe rootfs.
The key to that last paragraph is that the kernel and initrd itself are not necessarily from the NVMe. It can often be done, but JetPack itself might not be set up for that extra initrd customization.
You can back up the NVMe, that isn’t much of an issue. This won’t guarantee boot. To also guarantee boot you have to be able to reflash all of the other content that isn’t on the NVMe. To do that you must use command line most of the time, and it is a separate step beyond NVMe.
If you want to back up the entire drive’s content I recommend rsync (I can offer ways to use it). If you want the actual partition, as it would be flashed, then you can put the drive in read-only mode and then dd to another device (possibly over ssh, or possibly to something like a USB drive). Content can be turned into a partition, but takes extra steps.