I am not familiar with the script. If you can provide a URL to it, then it might help, but I’ll give some general information.
First, when you use rsync, then I highly recommend using the option “do not cross filesystems”. Let’s say in a naive case you were to use rsync to back up all of “/media” to the SSD, and the SSD is itself mounted there…you could have a bit of a recursive logic error there. This option is the “-x” (or “--one-file-system”) option. If you need to back up multiple mount points where one mount point is inside the other, then you could do this with two rsync commands (at least while building up your rsync command options I recommend not combining two filesystems in a single command).
Next, always back up with “numeric” IDs. There are times when two separate systems are involved, and their user names and IDs differ. In theory, if you ignore numeric IDs on the local system, then there is not an issue. But what happens if your local system itself held backup content for some other system, and that backup used numeric IDs and names which don’t exist on the current system? There would be a translation which breaks some restore abilities. It is just safer to always rysnc with numeric IDs. The one exception is if the rsync must be without sudo since only root can preserve numeric IDs and the IDs of other users (but you are using sudo anyway). The option for rsync to preserve numeric IDs is the “--numeric-ids” option.
If you are performing an rsync over a network, then you might want to use compression. You probably don’t need compression locally. The result will be the same, only time will change so long as you have enough RAM.
I tend to use rsync over ssh, but I’ll pretend this is with an SSD mounted on a Jetson.
Most of “/dev” is generated at run time via udev and will not be an actual file, and you should not back up udev dynamic files. However, during boot, prior to udev running, there might be some static nodes. You can get that from the host PC’s directory which you used for flashing. Your host PC will have a directory “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra”, and a subdirectory to that, “rootfs/”. The “Linux_for_Tegra/rootfs/dev” content can be used to create what is needed after the rest of the SSD content is added.
The “/proc” and “/sys” directories are not real directories, and contain only metadata generated by the kernel. These do not get backed up. The “--one-file-system” (or “-x”) option will prevent this from being picked up by accident.
Symbolic links must be preserved, and has a couple of ways to do this. The “archive” mode is recommended for this (option “-a” or “--archive”). It does not hurt to also include other options for preserving symbolic links, and in case I forget something, I usually use this option as well (the “-l” or “--links” option). Either would do the job, but I choose redundancy in case I forget something.
Some parts of “/var” are mandatory, e.g., the dpkg database of installed packages. It is easier to just copy everything there. You don’t need all of the log files, and that content is significant, but compared to the SSD size this is not usually a problem. If it were a problem, then you’d want to manually exclude the log files. You can check out the man page for rsync, and you’d want to check out these options:
--exclude=PATTERN--exclude-from=FILE--include=PATTERN--include-from=FILE
A special case of exclude which I want to mention is related to these directories and/or content:
-
--exclude '.gvfs'
The ‘.gvfs’ content is a special method of GUI desktop apps talking to each other, e.g., via the copy and paste mechanism. This cannot be read, even by root, unless the security mechanism is happy with the operation. This is also not a “real” file and should always be ignored.
-
--exclude 'lost+found'
This is part of the filesystem metadata, and is specific to that one exact partition. Content here only occurs if part of the filesystem is lost from corruption which the journal cannot handle. Never back this up for restore to another disk/partition.
Note that you can create a list of files to exclude or include (think of it as something you refine over time), and use the files instead of naming the include/exclude on command line for every file.
One of the most valuable options to rsync is to tell rsync to do nothing and just echo what it would do if it were really doing something: “--dry-run”. Don’t be afraid to experiment so long as you use “--dry-run”.
I use the option for verbose, “-v”. You can eliminate this if you want.
Larger/longer rsync commands might make you curious about status as it goes through the rsync. If you like to have information as you go, then you might use option “--info=progress2,stats2”.
If your destination hard drive already has content, then the normal rsync method would be to copy replacement content in prior to removing old content (in case it fails). This could also cause the command to fail when running low on space. I am not worried about old content, and so I use the option “--delete-before”. I will ignore this option, but feel free to add it if you want to minimize required resources during the rsync.
The option “-P” is useful if the rsync might get interrupted. Large “partial” files can be used to continue after restarting rsync. A good example is that if you have a file which is 16GB in size, then there is an interruption, you would need to start over on that file (imagine doing this over an unreliable WiFi to a remote host, or a case where electric power might interrupt). It doesn’t hurt to include “-P” (and I like copy and paste), so I just add it in.
I won’t cover ssh options since I think you are mounting the drive locally. I actually use ssh keys for my logins, and can log in directly to root without sudo (allowed only by keys), and this greatly simplifies rsync to remote hosts. This does take a bit of setup, though it isn’t actually all that bad. Working directly from the Jetson prevents needing this.
You won’t be using SElinux ACLs on the Jetson, but if you were to back up to a remote host PC (which probably does have some ACL content even if not enforcing), then you’d use the “-A” (or “--acls”) option. Just ignore this if using rsync to a drive locally mounted to the Jetson. Similar for the related “extended attributes”, “-X” (or “--xattrs”). However, keep in mind that if the filesystem has no such attributes or ACL, then there is no harm in enabling these options. You can enable them, and if they don’t apply, it won’t matter. I tend to always use them because I can quickly copy and paste and the command will be correct regardless of whether I am working directly on a Jetson or if I am using rsync to/from a remote host which does pay attention to those options.
If your SSD partition is empty and mounted on “/media/ssd” (I’m simplifying to type this out, but substitute where you actually have this mounted at), then this would be the first command you might be interested in (I drop into a root shell since everything should be via sudo):
sudo -s
rsync --dry-run -avcrltxAP --info=progress2,stats2 --numeric-ids --exclude '.gvfs' --exclude 'lost+found' '/' /media/ssd
# If --dry-run looks ok:
rsync -avcrltxAP --info=progress2,stats2 --numeric-ids --exclude '.gvfs' --exclude 'lost+found' '/' /media/ssd
# ...do what you need to to recursively copy (with preservation of ownership and permissions) the "`Linux_for_Tegra/rootfs/dev/`" content to "`/media/ssd/dev`". You need to be root (`sudo`) before you can copy or create this type of file.
FYI, before starting you might look at the output of “df -H -T”. Only the content listed as “ext4” would be of interest. “/dev” shows as a pseudo filesystem, and should not be copied. What the command won’t tell you is that if you were to umount the “/dev” mount point, then there would be some actual device special files still there (the mount of the udev content hides what is under this, but if you were to umount, then what would show up is the host PC’s “Linux_for_Tegra/rootfs/dev/”).
