[conspire] rsync for backups?

[Rick Moen]

Quoting Kim Davalos (kdavalos at sonic.net):

> If I were using rsync underwhat circumstances what I encounter this
> use case in the wild?
> Also, is this use case covered in the documentation, i.e., is this
> an expected behavior?

I'm neither the person you're addressing nor able to spend adequate time 
replying (need to get back to BayCon), but wanted to say a few words
anyway.  Presumably Michael will add more.

My lazy-quick read of Michael's comments is that he's providing example
non-default options that he typically uses for rsync-based backups, but
intra-host and (as an elaboration) inter-host across networks, that help
protect against edge-case problems and accidental omissions.  To
summarise the summary of the summary, backup/restore is a little tricky
at the best of times, and a little extra care and thoughtfulness is
worthwhile if only for peace of mind.

And yes, if I understand your question, the presence of those gotchas is
expected behaviour documented in the rsync documentation, but you might
not be alert to the ramification if you didn't spend quality time
attentively reading the rsync man page and noticing the potential
problem spots.

Then, too, as a separate point Michael made at the end, no matter how
careful you think you're being in ensuring your backups are complete and
sufficient, you really ought to spare ongoing, broadly focussed time
checking outcomes to make _sure_ you got the content you planned to
capture and that it's intact.

A tiny example:  I'd been using for years and years a scripted rsync
backup to capture to removable (external) USB hard drive backup copies
of all the file trees that matter (and not the ones that don't) from my
server.  One of the subtrees being backed up was /var/spool/mail. 

One fine day, luckily, I happened to look at one of the USB drive
snapshots of the /var/spool/mail tree, and, to my horror, all it
contained was (IIRC) a dangling symlink.  It's damned lucky I checked
outcomes in this case, because if I hadn't and the server hard drive
housing /var had failed, I'd have discovered the hard way that the only
backups I possessed of the system SMTP mail spool were rather old. 
Why?   Because at one point, Debian had decided to move the system mail
spool from /var/spool/mail to /var/mail, leaving only a symlink at the
old location -- and I hadn't noticed.

Having noticed, I was able to immediately amend my script and do an
immediate remedial backup of /var/mail .

Not all of the edge cases that Michael is taking trouble to catch are
even going to be a factor on all Linux systems, e.g., --xattrs, which
matters only on systems where extended [file] attributes get defined and
used.  

And some of them are fine points that have nothing to do particularly
with backup integrity but are certainly worth considering for
well-planned scripted backups even if you cannot be bothered for casual
ones you bang out with manually typed commands, like '--ipv4', which
just means 'I prefer IPv4 transport for my cross-network rsync transfer,
so don't even bother trying IPv6 before proceeding'.

HTH.