[EMAIL PROTECTED] wrote:
--- Alex Zbyslaw <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
I forgot about nice being interal to csh, that is
likely to source of my problems...
I use this for a dump
dump -0 -C 32 -f - |bzip2 --best | dd
of=/foo/bar.dbz2
and then on a restore
bzip2 -dc | (cd /foo; restore -r -f -)
the error I get is
expected 234234 got 234237
expected 234235 got 234238
expected 234236 got 234239
... ...
expected 234250 got 234267
which fills up the screen with seemingly corruption
errors, then the restore bails with an error asking
if
I wish to continue, if I continue it fails. I will
get
a screen dump of the error when I can dig up the
corrupt dump file, and or make a new one. I believe
the error is something about inodes missing or
being
corrupted.
this exact command syntax works on everything but
my
usr filesystem.
The restore man page does tell you why this happens
(I know because I
was just reading it today :-))
You are doing this dump on a Live Filesystem. To do
that use the -L
option to dump (FreeBSD 5.X or later) which will
snapshot the filesystem
first. Either that, or do what we had to do for
years and drop down to
single-user mode and make sure no processes are
running to change the
filesystem. Dump needs the filesystem to be static.
Then when you restore you will get precisely *one*
similar "error" (at
least on 5.4), which I can't explain but can say
*does not matter*. I
have restored several such dumps and compared them
to the original
filesystem and they are fine. You should do that
yourself for your own
peace of mind. (I do similar to you but with gzip
and on 5.4).
The "error" you'll get should be:
expected next file <inumber>, got <inumber>
A file that was not listed in the
directory showed up.
This can
occur when using a dump created on an
active file system.
and I think it must be some artefact of the
snapshot/dump interaction.
If you use -L and *still* have trouble then it
sounds like a bug.
--Alex
I wasn't aware booting off the cd and running fixit
made my filesystems become live...
It shouldn't, but why are you doing that? Run dump with -L while your
laptop is up and running FreeBSD.
But while you are in your fixit CD or single-user you could try fscking
the filesystems just in case. The output you showed certainly looks
like files disappeared between the "dumping directories" and "dumping
files" pass. I think that a corrupted filesystem could show that
behaviour. Whereas the "error" I consistently get looks like an extra
file somehow *appeared* between the passes.
dump -0 -C 32 -f - |bzip2 --best | dd of=/foo/bar.dbz2
won't "bzip2 --best > /foo/bar.dbz2" do? Why dd? You might also want
-a in the dump command so that there are no "tape size" calculations (or
maybe that's the default in 6.X, you'd have to check the man page).
Btw, restore also has a -N option which does the restore without
actually writing any data. God for seeing if a restore would work but
quicker and doesn't require any disk space :-)
--Alex
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
