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

Warren Block wblock at
Sun Jun 10 12:23:15 UTC 2012

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

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

Rather than reading just the contents of files, dump operates at a lower 
level, backing up all of the blocks used by a filesystem.

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

The mount command above that is

   mount /dev/da0s1f /mnt

The "f" indicates it's a split filesystem layout, where /, /var, /tmp, 
and /usr are separate filesystems in different partitions.  That's a 
traditional layout in FreeBSD.  bsdinstall in FreeBSD 9 creates a single 
filesystem, / .  Restoring a dump of a /usr filesystem would go to 
/mnt/usr in that case.  (That would mean you are converting from the 
split layout to a single filesystem, because with a combined filesystem 
you can't easily back up just /usr with dump.  dump does not "cross 
filesystems" when making a backup.)

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

See the dump man page about dump levels.  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.

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

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

With some tuning, yes.  /etc/fstab mountpoints often won't match when 
such a drive is connected to a different port or new system.  Use 
gpart(8) GPT labels or tunefs(8) filesystem labels.  Likewise with the 
Ethernet board, so see rc.conf(5) about ifconfig_DEFAULT.

gpart and GPT are easier than fdisk and bsdlabel.  I really need to flip 
that disk setup article upside down, with gpart first as the new 

See also:

More information about the freebsd-questions mailing list