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

Ronald F. Guilmette rfg at
Sun Jun 10 11:12:33 UTC 2012

In message <alpine.BSF.2.00.1206092039260.71605 at>, you wrote:

>On Sat, 9 Jun 2012, Ronald F. Guilmette wrote:
>> Also, I don't like backups taking longer than absolutely necessary, and
>> this is why I am specifically _not_ attracted to either the dd solution
>> or to dump/restore, because as I understand it, with either of these methods
>> you end up copying perhaps a metric buttload worth of unallocated free
>> disk space.
>No, that is one of the biggest advantages of dump over dd.  dump knows 
>UFS, and only copies occupied sectors and needed information.

OK.  I obviously got the Wrong Impression about dump/restore.  Thanks for
setting me straight.

(I got the Wrong Impression, I think, because I have read assertions like
"...dump backs up at the filesystem block level...".  What does that mean
exactly?  Use of the term "block level" in this context makes me think of
something operating along the lines of dd.)

>> Also, in one case, one of my partitions has one directory that contains
>> a really massive amount of stuff, and I specifically _don't_ need any of
>> that... backed up.
>Directories and files can be skipped with the nodump flag.

I am in your debt again.

I really will start looking at dump/restore.

>> P.S.  It really is a Damn Shame[tm] that nobody ever hacked FreeBSD cpio
>> to make it be able to copy (a) the extra file flag/mode bits and/or (b)
>> file ACLs and/or (c) file attributes.
>A quick search shows dump should support ACLs.  The other stuff is also 
>there.  Try it.

THANK YOU!  I am finding the above document very helpful.

It really never even occured to me that one could pipe the output of dump
directly to restore.  (Obviously, that pairing creates something very much
along the lines of cpio's -p option... which is one thing that I _am_ already
familiar with.)

Now that I've read your helpful document, I do have three short follow-up

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

I mean if the goal is to create a whole backup under /mnt that looks just
like the whole original system, then shouldn't ``restoration'' of the /usr
part of the original system go into /mnt/usr?

2)  Towards the end of your document you mention rsync.  Assuming that I
have made a backup of my entire /usr partition (using dump&restore) into
/mnt/usr and that at midnight every night from now on I want to simply
refresh that and bring it up to date with the current contents of my
actual /usr partition, what is the most proper way to do this?  Should
I use rsync for that?  Or should I use dump&restore again?  If that latter,
then how exactly does that work?  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?)

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... something that I
can just plug in and go with, when and if disaster strikes and my main
system disk suffers a horrifying head crash, you know, the day after the
manufacturer's warranty period is up?


More information about the freebsd-questions mailing list