Date: Sun, 10 Jun 2012 18:23:42 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: rfg@tristatelogic.com Cc: freebsd-questions@freebsd.org Subject: Re: Making a bootable backup (hard)disk... how? Message-ID: <201206102323.q5ANNghc005925@mail.r-bonomi.com> In-Reply-To: <48302.1339366497@tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Ronald F. Guilmette" <rfg@tristatelogic.com> wrote:
> Warren Block <wblock@wonkity.com> wrote:
> >On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
>
> >> ... 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.
That's about all -really- need to know.
The sequencing stuff is just a recommendation on a way to do multiple levels
of incremental backups.
> 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.
First, your assumption is incorrect. *grin*
All that dump stores is the timestamp of the completion of the last dump
at each level. As for "where" that information is stored. RTFM applies.
the 'files' section. By default '/etc/dumpdates', but modifiable by the
-D option.
> (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?)
Wrong assumptions lead to looking for the wrong things. <grin>
Why store the date for every node, when storing the date of the dump
sufficies? (assuming you're consisently using the same dump command for
dumps recorded to the same 'dumpfile', that is, and using different
dumpfiles for different 'selective' dump commands) _Anything_ modified
after the last dump at the next lower level needs to be saved as part of
-this- dump, unless it is 'excluded' from this dump.
A level 0 dump backs up 'everything', except things which are expliclitly
excluded.
A level 1 dump backs up 'everything that has changed since the last level
0 dump' (whether or not it was inclued in the level 0 dump), except for
things which are eplicitly excluded.
A subsequent level 1 dump catches everything since the last level _0_ dump.
A level 2 dump backs up 'everything that has changed since the last level 1
dump' (whether or not it was inclued in the level 1 dump, or level 0 dump),
except for things which are eplicitly excluded.
A level 3 dump backs up 'everything that has changed since the last level 2
dump' (whether or not it was inclued in the level 2, 1, or 0 dump), except
for things which are eplicitly excluded.
A subsequent level 2 dump catches everything since the last level _1_ dump.
Another level 1 dump -here- catches everything singe the prior level 0 dump.
and kills the record of any level 2 (or higher) dump.
A level 3 dump here -- with dump anything since the level 1 dump (since there
was no 'current' level 2 dump).
> 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 doesn't matter what anybody tells you. what matters is what the machine
does. Thus the authoritative response is "try it and find out." <grin>
> >> 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.
'dump'/'restore' doesn't do -everything- necessary.
You have to:
set up slices/partitions as needed.
'label' as appropriate
INSTALL BOOT BLOCKS
'newfs' the appropriate filesystems
then dump/restore the filesystems on the disk.
> >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.
It is an issue _only_ if you're dropping the 'cloned' drive into =another=
machine. It will come up configured with the same hostname, IP address/
netmask, etc. as the 'donor' machine.
If it's only use is as a backup to replace a failed original, don't worry
about it. This logic applies to /etc/fstab, too.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206102323.q5ANNghc005925>