Interestingly, when running my rsync command, I unexplainably now get this:
rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(848) [sender=3.3.0]
rsync error: received SIGUSR1 (code 19) at main.c(1600) [generator=3.3.0
Hmm…
Hmm, do you get more information if you run rsync with the -v (verbose) parameter?
If you used the -a (archive) parameter before, you could also try without it and use the -r parameter instead for recursive operations.
It may be related, but when I tried a couple of things, I received a “disk full” warning, although there’s no way that’s true since I confirmed it is not actually full.
Regardless, after rebooting the command worked just fine with -rv options.
As a long-time time big fan and user of rsync, I’d like to emphasise @litemotiv’s comment,
This is not a sophisticated backup solution which alone enables point-in-time restores, full recovery or various other options. In the two typical cases:
rsync --archive will create an ever-growing collection of the latest version of every file which existed when rsync’ed, but you will lose every previous change to every modified file. Conversely, if your rename or remove directory big_data , then you will forever have big_data and every file in it in the state in which it was last rsync’ed.rsync --archive --delete will fix the problem of unlimited accumulation of every removed or renamed file, but will effectively save every mistaken change and file removal, leaving only an exact copy of the source at the time of the last rsync.While rsync has an astonishing number of options to fine tune how it works, it alone can’t help with some of the things which a typical backup tool such as deja-dup/duplicity can - most significantly the ability to restore a file to an older version and sensible use of available storage.
Beware trying to back up $HOME. So much of what goes in there on a modern desktop environment is not data which you would ever want to restore. There is no one easy choice, but look to identify the handful of configuration and unique storage locations which you cannot easily re-create. This can get tricky, especially when you also consider specific applications which have their own configuration and data backup options, including the GNOME desktop itself [Hint: dconf load / < my.dconf].
To make a general point: you really need to understand what you’re trying to achieve before working on how to achieve it. In the case of “backups”, this gets tricky quickly.
Aaaaand another thing: you want to know what your process is doing, but don’t want log cancer. This is a very similar problem. Understand STDOUT and STDERR and see logrotate(8).
I presume any other desktop has similar command line options (I checked Cinnamon, and it has the same command parameters).