After I posted part 4 of my restic backup series,
@resticbackup asked
the above question, and I thought trying to answer it would be a good intermediate
article.

As a brief background, rclone describes
itself as "rsync for cloud storage". It can talk to a rather
comprehensive number of storage providers as well as local storage, and
can perform operations as simple mkdir, cp and ls
and ones as complicated as syncing between two different storage providers.
It, like rsync, is a useful tool in your kit.

So why not just run rclone in a loop? Actually, that might not be a bad
idea, and it's certainly a simple one. Pick a loop sleep that matches
your replications needs, put some error checking in, and fire away. If
I were going to do this, I'd likely use rclone copy rather than
rclone sync. copy will copy files from the source to the
destination, but will not delete any files on the destination which
do not exist on the source. sync on the other hand, will make the
source and destinations look exactly the same.

My preference for copy over clone is two fold. First, I like
the idea of having different retention policies at different repositories.
For example, some of the storage provider options are so inexpensive, for
my scale of storage needs, that I basically treat them as "just
shove things in there forever, I don't care", or, at least, care about
once a year. On the other hand, local fast storage is much more
expensive, that perhaps I can only afford to keep, say, a week or two of
backups around for all of my systems. By treating the repositories as
distinct, and with the append-only nature of restic, I can do that,
keeping what I'm likely to need for most restore operations at hand, and
keeping longer term, much much less likely to be needed restored data
off some place where it's harder to access but cheaper to keep.

The second reason for treating the repositories separate is it helps
guard against "oh shit!" moments: if you are cloning every
five minutes and you accidentially delete some data you need, you've got
a narrow window to realize that and stop the clone. At some point
in your life, you will do this — I remarked once that "[s]ome
people think I'm smart, but that's not it. I just remember exactly what
each of those bite marks on my ass means."

That all said, I'm going to keep using the mechanism I outlined in the
last article, of firing off a new sync job every time a new snapshot
appears. There's a few reasons for this. First, it's there, and its
working. Baring some overriding need to change this setup, I don't
plan on exerting energy to change it — for now.

Second, there is some amount of overhead cost here every time I do a
sync. My goal is that data starts being synced within a couple minutes
of a new snapshot being created. I'm still, however, mostly doing
the one-backup-a-day-late-at-night model (at least for now). With that,
I'll actually have work to do less than one-tenth of one percent of the
time, which just feels off. I'll admit, of course, that's just a gut
feeling. In addition, even if I'm not copying data, building up a list
of what I have locally and, more importantly, what's at the remote
repository, has some cost. All of the storage providers charge
something for operations like LIST, etc. That said, honestly,
I haven't ran the math on it and the charge here is almost certainly
one or two epsilons within nothing, so perhaps this isn't much of a
reason to care.

The two important bits on conclusion: first, I have something working,
so I'm going to keep using it until it hurts to do so, which, honestly,
is a good chunk of the reason I do many things. We'll be fancy and
call it being "pragmatic". Second, your needs and costs
and criteria are certainly different from mine, and what's best for
you requires a solid understanding of those things — one size
certainly doesn't fit all.