You are right that it is nice to have a restore point. This is basically a database function, and backup software usually has an ability to restore to either the content of a full backup, or some incremental backup at a given date. The software which does this does not do so with a single binary file, and does what rsync does…restoring in pieces.
The difference is that if you have a single set of backup files in an rsync database on the host PC, and you perform an rsync backup to the same database each time, then you lose the increments. If you were to perform rsync to a timestamped subdirectory, then you could also restore to this. Rsync is a bit more manual though, and so you would have to start with some existing match, and then manually go through each incremental match until you get to the point you want…which is a bit cumbersome and error prone.
There are some rather interesting points with backup and restore on a Jetson whereby you want to flash that content rather than running rsync to do the restore. What follows is not in any particular order, but is instead intended to show how to use clones.
During a flash a blank file the exact size of the root filesystem (“APP” partition in labels) is created. Loopback covers this so it can be treated as if it is a partition. Then an ext4 filesystem is formatted on this. After some boot file additions to the sample rootfs in the “Linux_for_Tegra/rootfs/” are added, the entire “Linux_for_Tegra/rootfs/” is copied to the loopback device which looks like an ext4 partition. Permissions are preserved this way (without metadata the system would fail to boot or malfunction as soon as security runs).
This file has loopback removed, and it becomes just a binary blob of data. Flash copies this binary data to the eMMC at the correct partition. Note that the full file is the “raw” file, and that there is a smaller version, the “sparse” file. The Jetson itself knows how to unpack a sparse file, and the result is an exact match as if it had started with the raw file. You can work with raw files if you cover them with loopback, and that loopback device can be mounted on the host PC at some subdirectory as if it were a regular hard drive partition formatted in ext4. Sparse files are useless for any purpose except flashing, and I throw them away.
Now if you have cloned your Jetson once (which is superior to methods from a running system since a running system has temp files open and can also change during save), then you have a full backup. You can flash this backup and have a 100% exact match to that moment in time.
If you were to have a copy of this (that’s a huge amount of disk space), and were to loopback mount a copy on the host PC, then that destination location could be used as your remote rsync to either write incremental changes to, or to restore from on a running Jetson. If a running Jetson had a fast rsync backup to the host PC via a loopback mounted clone, then it would be simple to flash to that release (making sure the flash software was the same release version as what originally flashed the rootfs). One would put the clone in “Linux_for_Tegra/bootloader/” with name “system.img”, and then use the flash.sh option “-r” to “reuse” the existing system.img.
You could do the same thing by rsync to copy a running Jetson to the “Linux_for_Tegra/rootfs/”, and then having a flash without saying to reuse the system.img (in other words, don’t use the “-r” option to flash.sh). This method would possibly update some “/boot” content prior to a flash, but other than this it would still be a match for system used during rsync backup.
If you happen to have an emulator environment, e.g., QEMU (sorry, I don’t know enough to help with that), then the loopback mounted clone could be the filesystem and tools such as “apt” and “rsync” could be used to update the clone just like a running system. The newer L4T releases actually do this on first flash in order to add the NVIDIA content (mainly direct hardware acceleration drivers) onto what is otherwise a purely Ubuntu rootfs.
If a clone is loopback mounted on a host PC, then you can use applications such as “gparted” to change the extents of the partition on that huge file, and then reduce the file size with the “truncate” command. A partition which produces a 28GiB file, but is mostly empty, could for example be reduced to maybe 5GiB. Until your backups result in needing more space you could backup to 5GiB copies.
If the loopback mounted image is mounted onto “Linux_for_Tegra/rootfs/” without using the “-r” option, then the produced system.img would be correct even though your backup was reduced to 5GiB.
If you have a 5GiB reduced size clone, then you could enlarge it by appending NULL space onto the end of it with truncate, followed by an ext4-aware application such as “gparted” being used to consume that extra NULL space and format it to ext4 without destruction of the original 5GiB space. This could be used as a “Linux_for_Tegra/bootloader/system.img” directly if the size happens to be the default, or if you use the “-S size” option to provide the image’s exact MiB or GiB.
FYI, an MiB is dividing the exact byte size by 1024 twice. GiB is dividing the exact byte size by 1024 three times. Specifying size via flash.sh option “-S 28GiB” implies the actual file is exactly “1024*1024*1024*28 = 30064771072” bytes.
One could also recursively copy a loopback mounted clone to some subdirectory while preserving permissions (implying numeric IDs are used during the copy), and place as many incremental updates as you want in different subdirectories, and then copying that into “Linux_for_Tegra/rootfs/” would restore to that backup point.
You have a lot of options to use rsync with a running system, and a lot of different tricks you can use with loopback mounted raw clones. You can manipulate raw clones in many ways, including changing size so long as you use an ext4-aware tool.