From ArchWiki

I think its a good idea to mention dirvish here. --Moere 03:34, 1 March 2010 (EST)

rsyncd.conf for ssh transfers.

It should be mentioned on this page that in order to use modules, one has to put an rsyncd.conf file in the home directory of the user who is ssh'ing in. This is not very obvious.

rsync for snapshot backups

After a bit of reading, i found out that plain rsync is pretty much capable of snapshot backups, like time-machine inspired stuff. Not sure if this is the appropriate place. It would be something like this:
DATESTAMP=$(date +%Y-%m-%d)
rsync -rltgo --chmod=a-w --link-dest=$SNAPS/latest $HOME $SNAPS/$DATESTAMP
rm latest

There is a much better discussion here:

Should not use --delete for rsync

Using '--delete', if one end of the connection is below 3.0.0, might disable incremental recursion which will lead to much more memory usage.
Should use '--del' instead.
From rsync's man page:

Beginning with rsync 3.0.0, the recursive algorithm used
is now an incremental scan that uses much less memory than
before and begins the transfer after the scanning of the
first few directories have been completed. This
incremental scan only affects our recursion algorithm, and
does not change a non-recursive transfer. It is also only
possible when both ends of the transfer are at least
version 3.0.0.
Some options require rsync to know the full file list, so
these options disable the incremental recursion mode.
These include: --delete-before, --delete-after, --prune-
empty-dirs, and --delay-updates. Because of this, the
default delete mode when you specify --delete is now
--delete-during when both ends of the connection are at
least 3.0.0 (use --del or --delete-during to request this
improved deletion mode explicitly).

Small Boy (talk) 10:45, 30 January 2021 (UTC)Reply[reply]

Version 3.0.0 is 12 years old so I don't think this is relevant. -- Lahwaacz (talk) 13:28, 30 January 2021 (UTC)Reply[reply]

Thanks. I changed my mind. While I can't quite agree with you, looking at it another way, --delete does what --del does when possible, and when not, does the sync using (some or much) more memory, so the bottom-line is, --delete always succeeds but --del will fail when unable to do it more efficiently. So recommending --delete seems better. Apologies. Small Boy (talk) 13:41, 30 January 2021 (UTC)Reply[reply]

Rsync#As cp/mv alternative -> add note about btrfs systems

Rsync having no --reflink support like cp, shouldn't a note be added about it not being a viable alternative in the case of Cow systems like Btrfs ? see [1]

-- Cvlc (talk) 16:51, 9 December 2021 (UTC)Reply[reply]