Full backup and restore system on the jetson nano jetpack 4.4

Hello, first of all i would like to thank you about your amazing products in general, and on the jetson nano specificaly.
this last days i installed your latest jetpack 4.4 package that has ubuntu 18.04 system. my sd card 128gb.
look, i tried something like 72+ hours to just install full system backup and restore applications like timeshift and systemback, i read ton of data in the internet about this programs and even in nvidia fourums but still didnt find solution.i cant download the applications and i am getting the error “E:unable to locate the package timeshift” (same error for the systemback application). some of the things i did: editing the cd /etc/apt/sources.list to many possibilities as advised in different sites - didnt work, using deb [arch=amd64,i386] after any line that begins with “deb” in sources.list -didnt work, generate sources.list according the country location i am (israel)-didnt work, updating packages through in software and updates-didnt work, adding canonical partner from other application and reloading-didnt work. dd command works but it doesnt help me- i would like to get restore point like in timeshift (no bin file) i tried almost everything, i even had to format again the sd card cause the system was stuck in boot screen and tried the things again but nothing seems to solve it, i just need a program that can make a full system backup and restore point on it.

*commands i used for timeshift download :
sudo apt-add-repository -y ppa:teejee2008/ppa sudo apt-get update
$ sudo apt-get install timeshift
the third command gave the error -“E:unable to locate package”

  • i have an old sd card 64 gb contain jetpack 4.3 => this timeshift work there, but i dont know really how, just installed it, maybe because its old and i downloaded packages in the past that enable the process to be allowed.
    so i will be happy for your help,
    thanks a lot

I know nothing about timeshift, but I see it is for backup and restore. Do beware that a PC has a BIOS/UEFI which is always present through the CMOS. BIOS/UEFI tends to act as something of a standardized API/interface allowing GRUB or “standard” bootloaders to be interchangeable. Embedded systems do not have this, an everything which is inside a PC’s CMOS must essentially exist in partitions instead.

The only thing a PC style backup program can succeed with is the root partition and ext4 partitions. Everything related to boot stages prior to the Linux kernel running is incompatible with a PC.

Talking about backup and restore requires knowing if you are using a Nano with eMMC, versus a Nano booting from SD card. Backup of the root filesystem is trivial, and then if you know the L4T/JetPack release used to create that rootfs originally, restore can occur simply by flashing again with that release after telling the flash to use your cloned rootfs instead of generating a new one.

Also, if you are using an SD card, then anything which directly images an SD onto another SD will work (software which treats content as binary data and does not try to interpret the meaning of the bytes). dd is the primary example.

rsync is an alternate method of backing up a rootfs, but not the non-rootfs content.

Thanks a lot for your fast replay!
as i said before - this backup and restore program is working for me in my ols sd card that contains the jetpack 4.3
i dont know really what i did to make it get installed properly, but maybe i installed packages in the past that allow it somehow to be installed.
in this last days i tried to get started with the new jetpack 4.4 of the nano, but unfortunately i couldnt install this program and i downloaded a lot of garbage that i couldnt even remove so i had to format the sd (i repeat this formatting maybe 3 times if not more) thats excactly the reason i need this timeshift program- downloading something that damage somehow my other files - so i would like to be able to come back to a point the system was good for me. i just ask if you know maybe some important packages or installations that might help this program to work when (just format again the sd)
i am new to linux and ubuntu
thanks a lot for your help

As a note before saying more, the apt mechanism finds packages and their dependencies over the network, and this in turn depends on web sites existing which have both the metadata about packages, along with packages. Those sites are repositories. A command to add repositories, e.g., for timeshift, will only work if the command provides sufficient repository information for the combination of your hardware and the operating system release. The architectures “[arch=amd64,i386]” are only for a desktop PC. Jetsons are aarch64 (a.k.a., arm64 or ARMv8-a…64-bit ARM).

I saw a reference to the command for adding the right repo for timeshift under Ubuntu 18.04, but the command does nothing and does not change the sources.list file. The reason would most likely be because the repository in question supports only amd64/i386 architecture and has no metadata on aarch64, at least under the JetPack/L4T release I was testing.

I did notice though that the timeshift software is just a nice front end to other software. Timeshift has two options for the backup software which actually runs behind the GUI, and one of those is rsync. I know rsync has a learning curve and would be a bit more complicated, but you can simply run the correct rsync commands to do the equivalent of what timeshift was doing. There are several other third party front ends which use rsync to perform actual backup/restore.

If you run the following command you’ll see a lot of applications which might be unrelated, but many of these will in fact do exactly what timeshift does:
apt search backup
…or if you want to see this in a pager and search for all cases where “rsync” appears:
apt search backup | less -i -p rsync
…the less pager then uses the “n” key to search forward, or the “shift-n” key combination for searches in a reverse direction (the “q” key quits the pager). Just watch how many backup programs simply use rsync as the backend. Perhaps one of those applications will do the job for you?

If you used some other front end to create a backup using rsync in the back end, I would expect different configuration files, but it is quite possible the portability of rsync would mean that one rsync front end could be mixed with another rsync front end and would work as expected. Or rsync might be able to be used on command line even if a tool such as timeshift originally created the backup. Somewhere in that list of backup tools using rsync I think you will possibly find something to replace timeshift. When Jetsons finally use Ubuntu 20.4 you can probably go back to timeshift, but you might not care at that point.

Will one of those other rsync based tools work for you?

Tip: A dd clone of the rootfs can be used on loopback and rsync won’t care if there is a real partition or a fake clone. A dd or regular clone can be a destination for incremental backup when the clone is treated as a full backup to be updated at a later date. The clone can be directly used for flashing, whereas a simple backup to somewhere on the host must be copied into an image prior to flashing if you choose to do a full restore via flashing.

wow first of all, thanks for your invest. i really appreiciate the way you try help me and others. its really nice and theres a lot we need learn from you as person.
about what you asked, im gonna try the rsync application soon and i will give you answer if i succeed to solve it. my goal is rly to be able get 1 file that pressing on it simply move me to restore point. i tried a lot of programs like writing in google “alternative timeshift” ubuntu i succeed download some of them but unfortunately its only back up files and to be honest- i can back up files with disk on key :) so it didnt really helped. i just wonder, as a begginer at least, isnt it important to more guys to be able go back if you downloaded something bad. cause theres not a lot of talks about backup and restore, it should be strong topic in my opinion. anyway ill try what you suggest to me (hope in this week) and im really appreciate the time you gave to this case and for me too, its not obvious- thanks a lot!

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.