Making a bootable backup (hard)disk... how?
wblock at wonkity.com
Sun Jun 10 23:05:29 UTC 2012
On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
> 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.
It's diffs. One complete copy to start, then a partial dump, just the
files that have changed since the first. And then another partial, just
the files that have changed since the second. Start over with a full
dump every so often, because that reduces the amount of backups that
have to be restored until you get to the final version of the file.
As far as I can recall, I've always used level zero.
> 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?)
Sorry, I've never checked. File dates, maybe. The source for dump
would be the place to look.
>> 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.
It does many of those things, enough that many people use it for backup.
> 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.
When a mountpoint is /dev/gpt/myrootfs, it doesn't matter whether the
drive shows up as ada0 or ad4 or da2, the mount still works.
>> 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.
Lightning strikes the machine and only the backup disk is available.
Labels and a generic ifconfig let that disk boot and work on a different
system. Those details can make recovery significantly easier.
Of course, the more we talk about this, the more it sounds like you
might as well just create a mirror and let the system do all the
duplication in real time.
More information about the freebsd-questions