On Sun, 10 Jun 2012, Ronald F. Guilmette wrote:
In message <alpine.bsf.2.00.1206100543280.75...@wonkity.com>,
Warren Block <wbl...@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.
_______________________________________________
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"
