Making a bootable backup (hard)disk... how?

[Warren Block]

On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:

>
> In message <alpine.BSF.2.00.1206100543280.75580 at wonkity.com>,
> Warren Block <wblock at wonkity.com> wrote:
>
>> On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
>>> 1)  In your example under the heading "Copying Filesystems", the second
>>> shell command line shown is:
>>>
>>>   dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt && restore -ruf -)
>>>
>>> Is that correct?  Shouldn't it actually be this instead?
>>>
>>>   dump -C16 -b64 -0uanL -h0 -f - /usr | (cd /mnt/usr && restore -ruf -)
>>> ...
>> The mount command above that is
>>
>>   mount /dev/da0s1f /mnt
>
> Ah!  OK.  I failed to notice that.  Yes, that clarifies things entirely.
>
>>> ...  I mean if I do the pipeline from dump
>>> to restore as you have shown in your examples in your "Copying Filesystems"
>>> section, then what must I do in order prevent dump from dumping files that
>>> haven't changed?  (And likewise, how do I prevent restore from trying to
>>> restore files under /mnt/usr that have not changed?  Or is that answer to
>>> that question that I simply have to do the first thing, i.e. force dump
>>> not to dump any of the unchanged files?)
>>
>> See the dump man page about dump levels.
>
> OK, I'm looking at it, and to be honest, the subject of dump levels is
> not covered at all well there.  (Neither does it seem to be covered well
> in other online documents, found via Google, that purport to describe
> dump & restore.)  The reference to "modified Tower of Hanoi algorithm"
> and the subsequent suggested dumplevel sequence are especially opaque
> and perplexing.

It's diffs.  One complete copy to start, then a partial dump, just the 
files that have changed since the first.  And then another partial, just 
the files that have changed since the second.  Start over with a full 
dump every so often, because that reduces the amount of backups that 
have to be restored until you get to the final version of the file.

As far as I can recall, I've always used level zero.

> What I don't understand (and what I wish someone would enlighten me about)
> is just this:  It would seem that in order to implement these dump levels,
> dump must be keeping a record somewhere, for each file in the filesystem,
> of the level at which that file was last dumped.  But where is this infor-
> mation stored, exactly??  I won't be able to sleep until I know.
>
> (Aside:  One of the reasons I hate Windoze is that everything is hidden.
> One of the reasons I love UNIX is that everything is out in the open,
> which is to say "documented".  But even after reading the dump(1) man
> page, it ain't in the least bit obvious to me where dump is recording
> the last dump level for each node in the filesystem.  This info must be
> stored SOMEWHERE.  But where?)

Sorry, I've never checked.  File dates, maybe.  The source for dump 
would be the place to look.

>> rsync will do it, and would be my choice for that; start with -aH for
>> options, and --exclude might be used for some directories that don't
>> need to be copied.
>
> Humm... well, I am reminded of all of the reasons why I have been convinced
> (now) to use dump/restore, specifically the security of knowing that _all_
> info will be copied across, in particular (a) extra mode bits/flags and (b)
> ACLs and (c) file attributes.  (This is not to even mention correct handling
> of other obscure filesystem things like, e.g. sparse files.)
>
> So the obvious question is:  If I am going to use rsync to keep my backup
> disk up-to-date, does rsync handle all of these additional small but
> important filesystem details properly too?  If not, then I had best just
> stick with dump/restore, and use the dumplevels.

It does many of those things, enough that many people use it for backup.

> Right.  There's that.  So I will need to diddle the /etc/fstab in the backup.
>
>> Use gpart(8) GPT labels...
>
> Ummm... I don't know pooh about this, but I am reading about it now, and
> the idea make me _very_ nervous.  Apparently, `MBR' is traditional, and
> I am very much of a traditionalist.  (Mostly I find that I only get into
> trouble when I try to buck pre-existing conventions.)
>
>> or tunefs(8) filesystem labels.
>
> I guess you must mean the "-L volname" option.  I'm not at all sure that I
> see how that would help anything.

When a mountpoint is /dev/gpt/myrootfs, it doesn't matter whether the 
drive shows up as ada0 or ad4 or da2, the mount still works.

>> Likewise with the
>> Ethernet board, so see rc.conf(5) about ifconfig_DEFAULT.
>
> Something else (the Handbook?) mentioned something about the ethernet card(s)
> in the context also.  I just don't get it.  Why would I even need to think
> about that in this context?  My current system disk is alive & well and
> already has all of the proper ifconfig stuff in /etc/rc.conf to make the
> local ethernet card work properly on my network.  I am engaged in making a
> _verbatim_ backup of my main system disk to another hard disk that, in
> an emergency, would be plugged in to the exact same system (with the exact
> same ethernet card) and if I have made the verbatim backup properly, then
> it also will have the proper stuff in _its_ /etc/rc.conf file to make that
> same ethernet card work.  So what exacty is the issue?  I don't get it.

Lightning strikes the machine and only the backup disk is available. 
Labels and a generic ifconfig let that disk boot and work on a different 
system.  Those details can make recovery significantly easier.


Of course, the more we talk about this, the more it sounds like you 
might as well just create a mirror and let the system do all the 
duplication in real time.