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

Ronald F. Guilmette rfg at tristatelogic.com
Sun Jun 10 22:15:13 UTC 2012


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.

Well, nevermind about that.  I get the general idea, i.e. that dumping
at level N causes dumping of everything that has changed since the last
dump at level N-1.

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?)

>I have not tried a dump level 
>higher than zero with a dump|restore copy, but expect it to work.
>
>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.

>Also see the sysutils/rsnapshot port for an interesting snapshot use. 
>Combined with a bootable FreeBSD like mfsBSD (http://mfsbsd.vx.sk/), 
>that might be a workable alternative to creating a bootable backup.

Thanks.  I've installed that port and I am looking at the man page, but
I believe that I do still want to reach my goal of just having a (recovery)
hard disk that I can just boot directly from.

>> 3)  Assuming that I have a second disk to which I plan (now) to use
>> dump&restore to make periodic copies of all of my ``normal'' (non-backup)
>> filesystems onto.   Assuming also that I've already installed the FreeBSD
>> boot loader into the boot block on this second disk, and that I've already
>> run fdisk & bsdlabel on it so as to set up all of the partitioning to be
>> essentially identical to my ``main'' system disk.  Assuming that all of
>> this is the case, by using dump&restore as you have shown in your document
>> under the heading "Copying Filesystems", will I have succeded at doing what
>> I was first asking about in this thread, i.e. will I have successfully
>> created a _bootable_ mirror of my main system disk...
>
>With some tuning, yes.  /etc/fstab mountpoints often won't match when 
>such a drive is connected to a different port or new system.

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.

>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.

>gpart and GPT are easier than fdisk and bsdlabel.

For you maybe.

I'm ignorant.  I only have experience with fdisk & bsdlabel.   (But at
your prompting I will try to educate myself on the alternatives.)

>I really need to flip 
>that disk setup article upside down, with gpart first as the new goodness.

See above.  me personally?  I am very much a fan of doing things the old
& traditional way, unless there is something compelling that makes me
"upgrade".


Regards,
rfg


More information about the freebsd-questions mailing list