backups using rsync

[Ronald F. Guilmette]

In message <20130304125634.8450cfaf.freebsd at edvax.de>, 
Polytropon <freebsd at edvax.de> wrote:

>On Mon, 04 Mar 2013 03:35:30 -0800, Ronald F. Guilmette wrote:
>> Now, unfortunately, I have just been bitten by the evil... and apparently
>> widely known (except to me)... ``You can't use dump(8) to dump a journaled
>> filesystem with soft updates'' bug-a-boo.
>
>There are other tools you can use, for example tar or cpdup
>or rsync, as you've mentioned in the subject.

tar I already knew about, but I think you will agree that it has lots of
limitations that make it entirely inappropriate for mirroring an entire
system.

This cpdup thing is entirely new to me.  Thanks for mentioning it!  I really
never heard of it before, but I just now installed it from ports, and I'm
perusing the man page.  It looks very promising.  Too bad it doesn't
properly handle sparse files, but oh well.  That's just a very minor nit.
(Does it properly handle everything else that rsync claims to be able to
properly handle, e.g. ACLs, file attributes, etc., etc.?)

>The same problems that apply when dumping live systems can
>bite you using rsync,

What problems are we talking about, in particular?

I am guessing that if I use rsync, then I *won't* encounter this rather
annoying issue/problem relating to UFS filesystems that have both soft
updates and journaling enabled, correct?

>but support for this "on file system
>level" seems to be better in rsync than what dump does "on
>block level".

What exactly did you mean by "this" ?

>> If I use all of the following rsync options...  -a,-H,-A, -X, and -S ....
>> when trying to make my backups, and if I do whatever additional fiddling
>> is necessary to insure that I separately copy over the MBR and boot loader
>> also to my backup drive, then is there any reason that, in the event of
>> a sudden meteor shower that takes out my primary disk drive while leaving
>> my backup drive intact, I can't just unplug my old primary drive, plug in
>> my (rsync-created) backup drive, reboot and be back in the sadddle again,
>> almost immediately, and with -zero- problems?
>
>You would have to make sure _many_ things are consistent
>on the backup disk.

Well, this is what I am getting at.  This is/was the whole point of my post
and my question.  I want to know:  What is that set of things, exactly?

>Regarding terminology, that would make the disk a failover disk

OK.  Thank you.  I will henceforth use that terminology.

>The disk would need to have an initialized file system and
>a working boot mechanism, both things rsync does not deal with

Check and check.  I implicitly understood the former, and I explicitly
mentioned the latter in my original post in this thread.

But is there anything else, other than those two things (which, just as
you say, are both clearly outside of the scope of what rsync does)?
Anything else I need to do or worry about in order to be able to use
rsync to create & maintain a full-blown fully-working system failover
drive?

If so, I'd much rather learn about it now... you know... as opposed
to learning about it if and when I actually have to _use_ my failover
drive.


Regards,
rfg