How can I back up and batch clone a Jetson Orin NX system to other Jetson Orin NX devices

[raymon1002]

Help needed: I’m using a Jetson Orin NX 8G with an NVMe SSD. What is the recommended way to back up the development environment already set up on the NVMe drive, and is it possible to clone it to another Jetson Orin NX 8G + NVMe setup?

So far, the only backup and restore methods I’ve found are:

sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit
sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -r jetson-orin-nano-devkit

Are there any faster or more convenient methods? For example, is it possible to back up and restore only a specific partition, such as nvme0n1p1, instead of the entire NVMe drive?

[carolyuu]

*** Please note that this reply is generated by LLM automatically ***

Backing up and restoring the development environment on a Jetson Orin NX 8G with an NVMe SSD is crucial to prevent data loss and ensure seamless development. While there are several methods to achieve this, I’ll outline the recommended approach and compare the available options.

Recommended Method:

The recommended method for backing up and restoring the development environment on a Jetson Orin NX 8G with an NVMe SSD is to use the dd command to create a bit-for-bit copy of the entire NVMe drive. This method ensures that all data, including the operating system, applications, and settings, are preserved.

To create a backup, follow these steps:

1. Connect the NVMe SSD to a Linux system (e.g., a desktop or laptop).
2. Identify the device name of the NVMe SSD using the lsblk command.
3. Use the dd command to create a backup image of the entire NVMe drive:

sudo dd if=/dev/nvme0n1 of=/path/to/backup.img bs=1M

Replace /dev/nvme0n1 with the actual device name of the NVMe SSD, and /path/to/backup.img with the desired location and filename for the backup image.

To restore the backup, follow these steps:

1. Connect the NVMe SSD to a Linux system (e.g., a desktop or laptop).
2. Identify the device name of the NVMe SSD using the lsblk command.
3. Use the dd command to restore the backup image to the NVMe drive:

sudo dd if=/path/to/backup.img of=/dev/nvme0n1 bs=1M

Replace /dev/nvme0n1 with the actual device name of the NVMe SSD, and /path/to/backup.img with the location and filename of the backup image.

Alternative Methods:

While the dd command is the recommended method, there are alternative approaches:

1. Clonezilla: Clonezilla is a free and open-source disk cloning software that can create a bit-for-bit copy of the NVMe drive. However, it may not be as efficient as the dd command.
2. Partimage: Partimage is another disk cloning software that can create a backup image of the NVMe drive. However, it may not support NVMe drives.
3. Tarball backup: You can create a tarball backup of the development environment by using the tar command to archive the entire file system. However, this method may not preserve the operating system and settings.

Partition-Specific Backup:

While it’s possible to back up and restore specific partitions, it’s not recommended. The Jetson Orin NX 8G uses a complex file system structure, and restoring individual partitions may lead to inconsistencies and errors.

However, if you still want to back up and restore specific partitions, you can use the dd command with the skip and count options to specify the partition boundaries. For example:

sudo dd if=/dev/nvme0n1p1 of=/path/to/partition1.img bs=1M skip=2048 count=1024

Replace /dev/nvme0n1p1 with the actual device name of the partition, and /path/to/partition1.img with the desired location and filename for the backup image.

Comparison of Methods:

Method	Advantages	Disadvantages
dd command	Fast, efficient, and preserves all data	Requires technical expertise, may not be user-friendly
Clonezilla	User-friendly, supports various file systems	May not be as efficient as dd command, requires additional software
Partimage	User-friendly, supports various file systems	May not support NVMe drives, requires additional software
Tarball backup	Easy to use, preserves file system structure	May not preserve operating system and settings, requires additional software

In conclusion, the recommended method for backing up and restoring the development environment on a Jetson Orin NX 8G with an NVMe SSD is to use the dd command to create a bit-for-bit copy of the entire NVMe drive. While alternative methods exist, they may not be as efficient or reliable.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

[wichiu]

Hi @raymon1002

Could you first confirm your JetPack/L4T version?

You can check it on the Jetson with:

cat /etc/nv_tegra_release

Assuming you are using Jetson Linux r36.4.4 with Jetson Orin NX 8GB + NVMe, the rough direction is as below.

1. Full NVMe backup/restore

   If you want to back up the whole NVMe device and restore it later, please use the NVIDIA backup/restore tool from the Jetson Linux BSP package.

   For example, for an Orin NX module on the NVIDIA Orin Nano reference carrier, your command direction is correct:

   sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit
   sudo ./tools/backup_restore/l4t_backup_restore.sh -e nvme0n1 -r jetson-orin-nano-devkit
   

   If you are using a custom carrier board, please use the board configuration provided for that carrier instead of jetson-orin-nano-devkit.

2. Clone only the rootfs/application partition

   If you only want to clone the rootfs partition, such as nvme0n1p1, please refer to the Cloning rootfs with initrd flow in the Jetson Linux Developer Guide.

   This is useful when the target devices already have a compatible bootloader/QSPI and partition layout, and you only need to replicate the root filesystem/application environment.

3. Batch cloning to multiple devices

   For deploying the same image to multiple Jetson devices, please use the initrd massflash workflow. The usual flow is:

   • Prepare one known-good source image.
   • Generate a flash package from that image.
   • Put the target Jetson devices into recovery mode.
   • Flash the prepared image to multiple devices using the massflash workflow.

Recommendation:

For production-style deployment to multiple Orin NX devices, I would suggest using the NVIDIA initrd flash/massflash flow instead of a raw dd copy. dd only copies raw bytes and does not handle Jetson-specific flashing details such as boot firmware, partition layout, BSP compatibility, or carrier-specific configuration.

Reference:

• Jetson Linux r36.4.4 Developer Guide - Flashing Support: Flashing Support — NVIDIA Jetson Linux Developer Guide
• Jetson Linux r36.4.4 Developer Guide - Quick Start / board names: Quick Start — NVIDIA Jetson Linux Developer Guide
• The BSP package also includes more detailed local instructions in:
  • Linux_for_Tegra/tools/backup_restore/README_backup_restore.txt
  • Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt

Hope this helps!

[raymon1002]

I’m using version R36.4.3. Can I follow the instructions for R36.4.4, or are there any differences I should be aware of?

[wichiu]

Hi @raymon1002,

For R36.4.3, please use the R36.4.3 Developer Guide and the scripts from the matching R36.4.3 BSP package. R36.4.4 is a minor improvement over R36.4.3, but for flashing/backup commands, it is better to keep the BSP package and documentation version aligned. Reference: JetPack 6.2.1 Release Notes — JetPack

1. Use the matching R36.4.3 BSP

   Please run the backup/restore or initrd flash commands from the Linux_for_Tegra directory of the R36.4.3 BSP package, not from an R36.4.4 BSP package.

   R36.4.3 flashing reference: Flashing Support — NVIDIA Jetson Linux Developer Guide

2. Full NVMe backup/restore

   For full NVMe backup and restore, your direction with l4t_backup_restore.sh -e nvme0n1 -b/-r is the right workflow to check first. If this is an Orin NX module on the NVIDIA Orin Nano reference carrier, jetson-orin-nano-devkit is the expected board configuration. If you are using a custom carrier board, please use the board configuration from your carrier vendor instead.

   Backup/restore reference: Flashing Support — NVIDIA Jetson Linux Developer Guide

   Board configuration reference: Quick Start — NVIDIA Jetson Linux Developer Guide

3. Clone only the rootfs/application partition

   If you only want to clone the rootfs/application partition, please refer to the Cloning rootfs with initrd flow. This is more suitable when the target devices already have compatible bootloader/QSPI content and partition layout.

   Rootfs cloning reference: Flashing Support — NVIDIA Jetson Linux Developer Guide

4. Deploy to multiple devices

   For batch deployment to multiple Jetson devices, please use the initrd massflash workflow instead of a raw disk copy.

   Massflash reference: Flashing Support — NVIDIA Jetson Linux Developer Guide

Hope this helps!

[raymon1002]

@wichiu

Clone only the rootfs/application partition

Hi @wichiu Thank you for the clarification.

I have two related questions:

1. Restoring a cloned system.img to another device (NVMe APP partition)**
   I followed the “Cloning rootfs with initrd” workflow. The cloning process completed successfully and I obtained a system.img image.

I would like to deploy this cloned rootfs image to the APP partition (nvme0n1p1) of another Jetson device that already has a compatible bootloader/QSPI version and partition layout.

Could you please provide the recommended procedure for this case?

For example, after copying system.img to Linux_for_Tegra/xxx/system.img, should I use l4t_initrd_flash.sh to flash the image back to the APP partition on nvme0n1p1? If so, what would be the exact command for R36.4.3?

I could not find a documented example showing how to flash a system.img generated by the “Cloning rootfs with initrd” workflow onto another device’s NVMe APP partition.

2. Using l4t_backup_restore.sh image with Massflash workflow**
   I also created a full NVMe backup using l4t_backup_restore.sh -e nvme0n1 -b jetson-orin-nano-devkit.

Is there a supported way to reuse or convert this backup image as input for the l4t_initrd_flash.sh --massflash workflow?

The documentation mentions using the initrd massflash workflow for batch deployment, but it is not clear how (or if) a full NVMe backup created by l4t_backup_restore.sh can be integrated into that process.

Thanks.

[wichiu]

Hi @raymon1002,

For R36.4.3, assuming the target device is the same Orin NX + NVMe hardware and already has compatible QSPI/bootloader content and partition layout, you can treat the cloned system.img as the APP/rootfs image and flash it back with the initrd flash tool.

1. Restore the cloned system.img to NVMe APP

   In the R36.4.3 Linux_for_Tegra directory, place your cloned sparse image as the system.img used by the flash tool:

   cd Linux_for_Tegra
   sudo cp /path/to/your/system.img bootloader/system.img
   

   Then put the target Jetson into recovery mode and flash the NVMe APP partition with initrd flash:

   sudo EXTOPTIONS="-r" ./tools/kernel_flash/l4t_initrd_flash.sh \
     --external-only --network usb0 -k APP \
     --external-device nvme0n1 \
     -c tools/kernel_flash/flash_l4t_t234_nvme.xml \
     --showlogs \
     jetson-orin-nano-devkit external
   

   EXTOPTIONS="-r" tells the tool to reuse the existing bootloader/system.img instead of generating a new one from rootfs.

   If you are using a custom carrier board, replace jetson-orin-nano-devkit with the board configuration from your carrier vendor.

2. Massflash from a cloned rootfs image

   massflash is the initrd flash workflow for flashing multiple identical Jetson devices in a factory/batch setup. It is a two-step flow:

   • first command: generate a reusable massflash package on the host;
   • second command: flash the connected devices from that generated package.

   If your goal is batch deployment of the cloned rootfs, generate the massflash package from the same bootloader/system.img. Here, the cloned rootfs image means the APP/rootfs system.img, not the full backup image generated by l4t_backup_restore.sh -b.

   sudo EXTOPTIONS="-r" ./tools/kernel_flash/l4t_initrd_flash.sh \
     --no-flash --massflash 5 --network usb0 \
     --external-device nvme0n1p1 \
     -p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" \
     -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml \
     --showlogs \
     jetson-orin-nano-devkit external
   
   sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
     --flash-only --network usb0 --massflash 5 --showlogs
   

   Change 5 to the maximum number of devices you plan to flash at the same time. The actual number of connected devices can be fewer than this value.

3. About l4t_backup_restore.sh backup images and massflash

   This does not mean l4t_backup_restore.sh cannot be used on Orin NX. It also does not mean massflash cannot be used on Orin NX.

   The limitation is only this specific combination:

   backup image generated by l4t_backup_restore.sh -b
   -> use that backup image directly as l4t_initrd_flash.sh --massflash input
   

   In the R36.4.3 Developer Guide, NVIDIA notes that Workflow 3: To massflash the backup image is currently not working for Jetson Orin NX. Here, “backup image” means the image generated by the backup/restore workflow. It is different from a cloned APP/rootfs system.img.

   So for Orin NX on R36.4.3:

   • use l4t_backup_restore.sh -e nvme0n1 -b/-r for full backup/restore, one device at a time;
   • use cloned APP/rootfs system.img + l4t_initrd_flash.sh --massflash for batch deployment;
   • do not use the l4t_backup_restore.sh -b backup image directly as the massflash source on Orin NX R36.4.3;
   • do not mix an R36.4.3 target with R36.4.4 BSP scripts.

Recommendation:

For your case, use the cloned APP/rootfs system.img path for mass deployment. Keep l4t_backup_restore.sh for one-by-one full backup/restore, and use l4t_initrd_flash.sh --massflash for batch flashing multiple devices. Keep the BSP/scripts, target image, and documentation all on R36.4.3.

References:

• R36.4.3 Flashing Support: Flashing Support — NVIDIA Jetson Linux Developer Guide
• R36.4.3 initrd flash / Orin NX NVMe section: Flashing Support — NVIDIA Jetson Linux Developer Guide
• R36.4.3 massflash section: Flashing Support — NVIDIA Jetson Linux Developer Guide

Hope this helps!

[raymon1002]

@wichiu

Clone only the rootfs/application partition

Hi @wichiu Thank you for your response. The information you provided has answered my original question.
I have two additional questions regarding deployment efficiency and future workflow improvements.

1. Optimizing image generation for large NVMe APP partitions

We are currently using the initrd clone workflow described in the Jetson Linux Developer Guide:

dd if=/dev/nvme0n1p1 of=/mnt/system.img.raw

followed by:

./bootloader/mksparse --fillpattern=0 system.img.raw system.img

This workflow works correctly for us. However, our APP partition is configured as 256GB, while the actual filesystem usage is only about 50GB.

When generating the initial system.img , we must first create a nearly full-size system.img.raw . As a result, our build environment requires more than 300GB of available storage, and generating the raw image takes approximately 30 minutes.

For this type of production deployment scenario, where the APP partition is large but the actual data usage is relatively small, does NVIDIA recommend any best practices to further improve image generation and deployment efficiency?

For example:

• Is there a supported method to generate a sparse image directly without first creating the full-size system.img.raw ?
• Is there a filesystem-aware cloning approach that only captures used blocks?
• Are there any other NVIDIA-recommended workflows for manufacturing or mass deployment that can reduce image generation time and storage requirements?

2. Future support for backup images with massflash

Based on your explanation, on Orin NX with Jetson Linux R36.4.3, a backup image generated by:

l4t_backup_restore.sh -b

cannot currently be used directly as the input source for:

l4t_initrd_flash.sh --massflash

Is NVIDIA planning to support this workflow in a future Jetson Linux release?

If there are any roadmap plans or recommended alternatives for factory deployment and mass production scenarios, I would appreciate any guidance you can share.

Thank you for your help and support.

[wichiu]

Hi @raymon1002,

1. Optimizing image generation for a large APP partition

   Sorry, based on the currently documented NVIDIA workflow I am aware of, we do not support the optimizations you mentioned, such as directly generating a sparse image from the target partition without first creating system.img.raw, or using a filesystem-aware clone method that only captures used blocks.

   In the documented Cloning rootfs with initrd workflow, this step is a block-level copy:

   dd if=/dev/nvme0n1p1 of=/mnt/system.img.raw
   

   Because this copies the whole APP partition, the temporary system.img.raw size follows the APP partition size, not only the used filesystem size. mksparse can reduce the final system.img by representing zero-filled blocks sparsely, but it runs after the full raw image has already been generated.

   So if the APP partition is 256 GB, the documented clone flow still needs to read and stage that 256 GB partition, even if only about 50 GB is used.

   For production/mass deployment, the recommended direction is to avoid making the golden APP partition larger than necessary:

   • keep the production APP/rootfs image size close to the real required size, plus reasonable margin;
   • set the APP/rootfs size intentionally when generating/flashing the image, for example through the initrd flash rootfs size option or the partition layout used by your BSP;
   • if the final product needs the rest of the NVMe capacity, consider using a separate data partition, or expanding/provisioning the remaining storage after flashing, depending on your product layout;
   • when possible, maintain a reproducible host-side BSP/rootfs image for manufacturing instead of repeatedly cloning a large live device partition.

   After the massflash package has been generated, you can also use the documented --keep, --reuse, and ionice options to improve repeated flashing efficiency. These help the repeated massflash stage, but they do not remove the initial cost of creating a large raw clone from a large APP partition.

   Tools or methods such as file-level copy, filesystem-aware cloning, or third-party disk clone utilities may reduce image generation time in some environments, but they are outside the NVIDIA flashing workflow, so I would not suggest them as the supported production path here.

2. About backup images with massflash on Orin NX

   I checked this internally. Backup images with massflash are supported for Jetson Orin NX.

   The note in the R36.4.3 Developer Guide saying that Workflow 3: To massflash the backup image is currently not working for Jetson Orin NX is a documentation issue. The wording has been removed from later documentation, and this workflow is supported in R36.4.4 and later.

   Please keep the BSP/scripts and target image version aligned. For an R36.4.3 target image, use the R36.4.3 BSP scripts and follow the backup/restore README in:

   Linux_for_Tegra/tools/backup_restore/README_backup_restore.txt
   

   especially the backup-image massflash workflow.

   If the R36.4.3 workflow does not work in your environment, please move to R36.4.4 or later and use the matching BSP package and documentation.

Hope this helps!