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 (http://mfsbsd.vx.sk/), 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 goodness.

See also:
http://www.wonkity.com/~wblock/docs/html/labels.html
http://www.wonkity.com/~wblock/docs/html/disksetup.html
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to