Re: dump | restore fails: unknown tape header type 1853384566
Danny Braniss
>=20
> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
>=20
> =20
> >> I'm trying to migrate a filesystem from one disk to another using:
> >>
> >> dump a0hCf 0 32 - /old =7C restore -rf -
> >>
> >> (/old is already mounted read-only). The process runs for a while an=
d> >> then stops with:
> >>
> >> =5B...=5D
> >> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 200=
9
> >> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 200=
9
> >> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 200=
9
> >> unknown tape header type 1853384566> >> abort? =5Byn=5D
> >>
> >> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD'=
s
> >> dump's output?
> >> =20
> >>
> What happens if you don't use the cache?
> > =20
> No big difference:
> > dump a0f - /old =7C restore -rf -
> =5B...=5D
> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
> unknown tape header type -621260722> abort? =5Byn=5D
>=20
> Looks like a junk value somewhere... Unitialized variable or some such.=
>=20
can you try splitting it in 2, ie no pipe?
dump a0f some.file /old (or dump 0f - /old =7C gzip -c > file.dump.gz)
restore rf some.file
danny
_______________________________________________
freeb...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-...@freebsd.org"
Mikhail T.
I'm trying to migrate a filesystem from one disk to another using:
dump a0hCf 0 32 - /old | restore -rf -
(/old is already mounted read-only). The process runs for a while and
then stops with:
[...]
DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
unknown tape header type 1853384566
abort? [yn]
Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
dump's output?
The system runs 7.0-STABLE from July 6th, i386. I just tried updating
the dump and restore from source (latest 7.x) -- the error is the same...
Please, advise. Thanks!
-mi
Mikhail T.
> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
>
>>
>> dump a0hCf 0 32 - /old | restore -rf -
>>
>> (/old is already mounted read-only). The process runs for a while and
>> then stops with:
>>
>> [...]
>> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>> unknown tape header type 1853384566
>> abort? [yn]
>>
>> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
>> dump's output?
>>
>
>
dump a0f - /old | restore -rf -
[...]
DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
unknown tape header type -621260722
abort? [yn]
Looks like a junk value somewhere... Unitialized variable or some such.
-mi
Daniel O'Connor
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
> I'm trying to migrate a filesystem from one disk to another using:
>
> dump a0hCf 0 32 - /old | restore -rf -
>
> (/old is already mounted read-only). The process runs for a while and
> then stops with:
>
> [...]
> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
> unknown tape header type 1853384566
> abort? [yn]
>
> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
> dump's output?
What happens if you don't use the cache?
Also, do you really want -h 0? That means you skip nodump marked files at a=
=20
level 0 dump.
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
--nextPart1505730.BJrJCmrapF
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJyGqB5ZPcIHs/zowRAlITAJ4s4JYFDaJAS6e5352mS0BvTdJ2jQCeJZXl
lg+Tg9fdpzt2RajAmXyLN2I=
=sX+i
-----END PGP SIGNATURE-----
--nextPart1505730.BJrJCmrapF--
Mikhail T.
>> Daniel O'Connor написав(ла):
>>
>> On Tuesday 24 March 2009 11:55:07 Mikhail T. wrote:
>>
>>
>>
>>>> I'm trying to migrate a filesystem from one disk to another using:
>>>>
>>>> dump a0hCf 0 32 - /old | restore -rf -
>>>>
>>>> (/old is already mounted read-only). The process runs for a while and> >> then stops with:
>>>>
>>>> [...]
>>>> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
>>>> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
>>>> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
>>>> unknown tape header type 1853384566> >> abort? [yn]
>>>>
>>>> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
>>>> dump's output?
>>>>
>>>>
>>>>
> > What happens if you don't use the cache?
>
>>>
>>>
>>
>>> dump a0f - /old | restore -rf -
>>>
>> [...]
>> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>> unknown tape header type -621260722> abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.
>>
>>
> restore rf some.file
>
> danny
>
Well, the first part (the dump) runs almost to the completion, but hangs
at the very end for some reason:
dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old
DUMP: WARNING: should use -L when dumping live read-write filesystems!
DUMP: Date of this level 0 dump: Tue Mar 24 05:59:27 2009
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/ad2s1e (/ibmo) to /ibm/ibmo.0.2009-03-24.dump
DUMP: mapping (Pass I) [regular files]
DUMP: Cache 64 MB, blocksize = 65536
DUMP: mapping (Pass II) [directories]
DUMP: estimated 152357442 tape blocks.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 0.83% done, finished in 9:59 at Tue Mar 24 16:04:19 2009
DUMP: 2.74% done, finished in 5:55 at Tue Mar 24 12:05:07 2009
DUMP: 4.66% done, finished in 5:06 at Tue Mar 24 11:21:27 2009
DUMP: 6.58% done, finished in 4:43 at Tue Mar 24 11:03:37 2009
...
DUMP: 91.54% done, finished in 0:23 at Tue Mar 24 10:38:15 2009
DUMP: 93.41% done, finished in 0:18 at Tue Mar 24 10:38:02 2009
DUMP: 95.27% done, finished in 0:13 at Tue Mar 24 10:37:50 2009
DUMP: 97.15% done, finished in 0:07 at Tue Mar 24 10:37:36 2009
DUMP: 99.03% done, finished in 0:02 at Tue Mar 24 10:37:23 2009
DUMP: DUMP: 152769349 tape blocks on 1 volume
DUMP: finished in 16706 seconds, throughput 9144 KBytes/sec
[... Hang ...]
load: 0.18 cmd: dump 10105 [sbwait] 72.53u 383.14s 0% 73048k
load: 0.19 cmd: dump 10102 [sbwait] 164.93u 314.87s 0% 75008k
load: 0.10 cmd: dump 10102 [running] 164.93u 314.87s 0% 75008k
The timestamp on the output file is, indeed, 10:38 and the dumping
process is hanging ever since then (over 90 minutes already).
Yours,
Mikhail T.
> can you try splitting it in 2, ie no pipe?
> dump a0f some.file /old (or dump 0f - /old | gzip -c > file.dump.gz)
> restore rf some.file
>
>
restore -rf ibmo.0.2009-03-24.dump
load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k
unknown tape header type 213474529
abort? [yn]
Please, advise. Thanks! Yours,
Mikhail T.
> Mikhail T. wrote:
>> dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old
>> DUMP: WARNING: should use -L when dumping live read-write
>> filesystems!
>
It was yesterday. Today I remounted it rw to remove some junk-files,
which I don't need to transfer. I don't believe, this is causing the
problems.
> In my experience, restore can sometimes throw warnings if you dump a
> live filesystem. It might be causing your errors? If possible, can
> you try completely unmounting the filesystem you are dumping and
> trying again?
I don't think, restore can even figure this out, much less throw a
warning -- it is dump, that complains... But the dump started this
morning is still hanging (in sbwait) -- I've never seen this before. I'm
also very troubled, that such an important functionality (dump/restore!)
is sooo problem-prone, and yet so few people seem to care...
Is the official view, that dump is obsolete (and already bit-rotten),
perhaps, and use of tar is encouraged instead?
Andrew Snow
> dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old
> DUMP: WARNING: should use -L when dumping live read-write filesystems!
I thought you said it was a read-only filesystem?
In my experience, restore can sometimes throw warnings if you dump a
live filesystem. It might be causing your errors? If possible, can you
try completely unmounting the filesystem you are dumping and trying again?
Yoshihiro Ota
> -mi
-a option seems to be the problem.
Try without it.
Hiro
Daniel O'Connor
Content-Type: text/plain;
charset="koi8-u"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 25 March 2009 11:48:56 Mikhail T. wrote:
> Andrew Snow =CE=C1=D0=C9=D3=C1=D7(=CC=C1):
> > Mikhail T. wrote:
> >> dump 0aCf 64 /ibm/ibmo.0.2009-03-24.dump /old
> >> DUMP: WARNING: should use -L when dumping live read-write
> >> filesystems!
> >
> > I thought you said it was a read-only filesystem?
>
> It was yesterday. Today I remounted it rw to remove some junk-files,
> which I don't need to transfer. I don't believe, this is causing the
> problems.
>
> > In my experience, restore can sometimes throw warnings if you dump a
> > live filesystem. It might be causing your errors? If possible, can
> > you try completely unmounting the filesystem you are dumping and
> > trying again?
>
> I don't think, restore can even figure this out, much less throw a
> warning -- it is dump, that complains... But the dump started this
restore will emit a warning if dump writes a stream that is out of order=20
because of a live file system but that is not what you are seeing.
> morning is still hanging (in sbwait) -- I've never seen this before. I'm
> also very troubled, that such an important functionality (dump/restore!)
> is sooo problem-prone, and yet so few people seem to care...
Well, "works for me".
> Is the official view, that dump is obsolete (and already bit-rotten),
> perhaps, and use of tar is encouraged instead?
I've never had dump fail but it IS rather crusty and slow.. That said tar=20
doesn't cover all the information I believe.
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
--nextPart1370125.q0FYTSpdyJ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJyZCj5ZPcIHs/zowRAuC5AKCsG52ocLa5Mw5KyHhhCsCQaLVgTwCfQgIX
sNG6y1F8aM8Ge4/yK1uMyDc=
=bb2i
-----END PGP SIGNATURE-----
--nextPart1370125.q0FYTSpdyJ--
Mikhail T.
>> morning is still hanging (in sbwait) -- I've never seen this before. I'm
>> also very troubled, that such an important functionality (dump/restore!)
>> is sooo problem-prone, and yet so few people seem to care...
>>
>
> Well, "works for me".
>
can reproduce the problem easily.
>> Is the official view, that dump is obsolete (and already bit-rotten),
>> perhaps, and use of tar is encouraged instead?
>>
>
> I've never had dump fail but it IS rather crusty and slow.. That said tar
making filesystem-level backups, that's both modern and covers all
aspects (like flags)?
That said, I point out, that for me, dump is not failing (although it
did hang this morning). It is the restore, which fails to read dump's
output:
unknown tape header type 213474529
abort? [yn] n
resync restore, skipped 502 blocks
expected next file 54, got 0
unknown tape header type -954356454
abort? [yn] n
resync restore, skipped 29 blocks
expected next file 54, got 0
unknown tape header type -1754938223
abort? [yn] n
resync restore, skipped 482 blocks
expected next file 54, got 0
unknown tape header type -915868704
abort? [yn] n
resync restore, skipped 29 blocks
expected next file 54, got 0
unknown tape header type 1790084751
abort? [yn] n
resync restore, skipped 482 blocks
expected next file 54, got 0
unknown tape header type 903667267
abort? [yn] n
...
Thanks!
-mi
Mikhail T.
>> No big difference:
>> dump a0f - /old | restore -rf -
>> [...]
>> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>> unknown tape header type -621260722
>> abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.
>>
>> -mi
>>
>
> -a option seems to be the problem.
> Try without it.
>
unrelated -a option:
root@symbion:/ibm (113) dump 0f - /ibmo | restore -rf -
DUMP: Date of this level 0 dump: Tue Mar 24 21:31:19 2009
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/ad2s1e (/ibmo) to standard output
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 152357442 tape blocks.
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: 0.16% done, finished in 242:05 at Sat Apr 4 00:00:21 2009
DUMP: 4.29% done, finished in 10:24 at Wed Mar 25 08:24:02 2009
DUMP: 8.56% done, finished in 5:52 at Wed Mar 25 03:56:43 2009
DUMP: 11.76% done, finished in 4:35 at Wed Mar 25 02:43:29 2009
DUMP: 16.00% done, finished in 3:38 at Wed Mar 25 01:52:05 2009
DUMP: 19.28% done, finished in 3:15 at Wed Mar 25 01:33:43 2009
DUMP: 22.74% done, finished in 2:55 at Wed Mar 25 01:18:49 2009
unknown tape header type 1431655765
abort? [yn] n
resync restore, skipped 9 blocks
expected next file 1599492, got 0
DUMP: 24.50% done, finished in 3:27 at Wed Mar 25 02:05:41 2009
unknown tape header type 1508167078
abort? [yn] n
resync restore, skipped 66 blocks
expected next file 1599492, got 0
unknown tape header type -1493630979
abort? [yn] y
dump core? [yn] n
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.
Now can one get /real/ support for the most basic functionality of the
most advanced modern Unix in the world? Thanks,
Andrew Snow
> Now can one get /real/ support for the most basic functionality of the
> most advanced modern Unix in the world? Thanks,
I think before this goes any further, you will need to try
rebooting/unmouting it, running fsck on it, and then dump the unmounted
partition and see how that goes.
- Andrew
Daniel O'Connor
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 25 March 2009 12:38:04 Mikhail T. wrote:
> Daniel O'Connor =CE=C1=D0=C9=D3=C1=D7(=CC=C1):
> >> morning is still hanging (in sbwait) -- I've never seen this before. I=
'm
> >> also very troubled, that such an important functionality (dump/restore=
!)
> >> is sooo problem-prone, and yet so few people seem to care...
> >
> > Well, "works for me".
>
> Well, would like a login on this system to take a look for yourself? I
> can reproduce the problem easily.
I don't know the internals of dump/restore :(
> >> Is the official view, that dump is obsolete (and already bit-rotten),
> >> perhaps, and use of tar is encouraged instead?
> >
> > I've never had dump fail but it IS rather crusty and slow.. That said t=
ar
> > doesn't cover all the information I believe.
>
> So, if dump/restore ain't it, does FreeBSD have a supported way of
> making filesystem-level backups, that's both modern and covers all
> aspects (like flags)?
I would try a pax archive, eg..
tar --format pax --one-file-system -pcf - -C / . | tar -pxf - -C /mnt/newdi=
sk
According to the libarchive-formats page this handles ACLs & flags, my test=
ing=20
shows it handles flags (at least). eg..
[midget 13:30] /tmp/test2 >touch foo
[midget 13:30] /tmp/test2 >chflags uchg foo =20
[midget 13:30] /tmp/test2 >tar --format pax -zpcf /tmp/test.pax.gz foo
[midget 13:30] /tmp/test2 >rm -f foo
rm: foo: Operation not permitted
[midget 13:30] /tmp/test2 >chflags nouchg foo
[midget 13:30] /tmp/test2 >rm foo
[midget 13:30] /tmp/test2 >tar -pxf /tmp/test.pax.gz =20
[midget 13:30] /tmp/test2 >ls -lao
total 30 =20
drwxr-xr-x 2 darius wheel - 512 Mar 25 13:30 .
drwxrwxrwt 53 root wheel - 28672 Mar 25 13:29 ..
=2Drw-r--r-- 1 darius wheel uchg 0 Mar 25 13:30 foo
[midget 13:30] /tmp/test2 >rm -f foo
rm: foo: Operation not permitted
> That said, I point out, that for me, dump is not failing (although it
> did hang this morning). It is the restore, which fails to read dump's
> output:
You can't tell the difference between dump producing mangled output or rest=
ore=20
bombing out on valid input..
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
--nextPart12025682.40UkcpncZI
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJyZ9A5ZPcIHs/zowRAjtjAJ9Re4V+zBWBrdjjltDwdYGwJSIaTwCdGlke
F95N4/KuXGNR+A1p4WxbUCE=
=KvTW
-----END PGP SIGNATURE-----
--nextPart12025682.40UkcpncZI--
Mikhail T.
> Mikhail T. wrote:
>
>> Now can one get /real/ support for the most basic functionality of the
>> most advanced modern Unix in the world? Thanks,
>>
>
> I think before this goes any further, you will need to try
> rebooting/unmouting it, running fsck on it, and then dump the unmounted
> partition and see how that goes.
>
new disk...
But I will try your suggestion next, after the current attempt (using
restore's -v switch) ends. If it chokes on the same file every time,
that would be a clue... Thanks,
-mi
Mikhail T.
>> That said, I point out, that for me, dump is not failing (although it
>> did hang this morning). It is the restore, which fails to read dump's
>> output:
>>
>
>
(to make backups) is not going to know, whether his dumps are usable
(for whichever of the two reasons), until he needs them...
Daniel O'Connor
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote:
> Now can one get /real/ support for the most basic functionality of the
> most advanced modern Unix in the world? Thanks,
Maybe you should return it to the shop and ask for your money back.
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
--nextPart1914226.SHNIKI2sUl
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJyawl5ZPcIHs/zowRAoQ8AJ44eqmk9Z8Fb2xnNt4a6+4kmqW3KACbBRb5
a3VXan3gOZv3FJHV1JjKy6Y=
=4TsE
-----END PGP SIGNATURE-----
--nextPart1914226.SHNIKI2sUl--
Mikhail T.
> On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote:
>
>> Now can one get /real/ support for the most basic functionality of the
>> most advanced modern Unix in the world? Thanks,
>>
>
> Maybe you should return it to the shop and ask for your money back.
>
revoke my own 15 years worth of contributions to the project...
Except, why would I? I always supported people, who had problems with
any of my work -- and the attitude of the rest of the contributors /used
to be/ the same...
Daniel O'Connor
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Wednesday 25 March 2009 14:35:01 Mikhail T. wrote:
> Daniel O'Connor =CE=C1=D0=C9=D3=C1=D7(=CC=C1):
> > On Wednesday 25 March 2009 13:10:23 Mikhail T. wrote:
> >> Now can one get /real/ support for the most basic functionality of the
> >> most advanced modern Unix in the world? Thanks,
> >
> > Maybe you should return it to the shop and ask for your money back.
>
> Well, if this response is the best one can get, may be I should also
> revoke my own 15 years worth of contributions to the project...
>
> Except, why would I? I always supported people, who had problems with
> any of my work -- and the attitude of the rest of the contributors /used
> to be/ the same...
People ARE helping you, just because they haven't come up with an answer is=
no=20
reason to send snarky comments to the list.
Outrage (fake or otherwise) that people don't seem to be taking your=20
particular problem seriously is unhelpful and probably counter-productive.
=2D-=20
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
--nextPart2312064.hPhShRi3Ly
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQBJybGM5ZPcIHs/zowRAqKZAJ4hB3UlBJc7gEqMVvJM2C4CwhK2+QCffHRT
O02sDTpiYUpf8VdJCLugKPI=
=0QEu
-----END PGP SIGNATURE-----
--nextPart2312064.hPhShRi3Ly--
Mikhail T.
> I think before this goes any further, you will need to try
> rebooting/unmouting it, running fsck on it, and then dump the unmounted
> partition and see how that goes.
>
>
Mark Kirkwood
>
> That said, I point out, that for me, dump is not failing (although it
> did hang this morning). It is the restore, which fails to read dump's
> output:
>
> resync restore, skipped 502 blocks
> unknown tape header type -954356454
> abort? [yn] n
> resync restore, skipped 29 blocks
> unknown tape header type -1754938223
> abort? [yn] n
> resync restore, skipped 482 blocks
> unknown tape header type -915868704
> abort? [yn] n
> resync restore, skipped 29 blocks
> unknown tape header type 1790084751
> abort? [yn] n
> resync restore, skipped 482 blocks
> unknown tape header type 903667267
> abort? [yn] n
> ...
>
Is this link any help?
http://www.mail-archive.com/freebsd-...@freebsd.org/msg197899.html
Other than that, I'd suggest checking the disk(s) with smartmontools to
try to rule out hardware problems.
regards
Mark
Greg Black
> That's true. I just wanted to point out, that someone running dump only
> (to make backups) is not going to know, whether his dumps are usable
> (for whichever of the two reasons), until he needs them...
Such a person is not making backups and deserves what he gets.
I haven't got anything to say about dump/restore because I haven't
bothered with them for years. I do know that dumps from mounted file
systems will often appear to work, but will fail when it matters. This
is not a bug and is expected behaviour to which the solution is obvious.
Mikhail T.
> On 2009-03-24, Mikhail T. wrote:
>
>> That's true. I just wanted to point out, that someone running dump only
>> (to make backups) is not going to know, whether his dumps are usable
>> (for whichever of the two reasons), until he needs them...
>>
>
> Such a person is not making backups and deserves what he gets.
>
just is not routinely using them and thus does not know, that they
aren't usable... It is not unreasonable to expect the two utilities to
"just work", so I wouldn't be blaming such a person for not testing
restore.
That such a scenario is possible, despite the user making diligent
regular backups, is a very bad sign...
> I haven't got anything to say about dump/restore because I haven't
> bothered with them for years. I do know that dumps from mounted file
> systems will often appear to work, but will fail when it matters. This
> is not a bug and is expected behaviour to which the solution is obvious.
>
FS being mounted read-only should not be a problem. And even read-write
mounted filesystems will be Ok, although possibly inconsistent (a file
modified during backup may get to into dump "as of" any point). But an
idle FS is Ok to dump. Generally, when dumping read-write mounted
filesystems, one is supposed to use snapshots, but that is very buggy on
its own (leading to kernel crashes), so it is safer to rely on the FS
being "idle", if it can not be forced into read-only for some other reason.
-mi
Dimitry Andric
> dump a0f - /old | restore -rf -
> [...]
> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
> unknown tape header type -621260722
> abort? [yn]
>
> Looks like a junk value somewhere... Unitialized variable or some such.
Hmm, I can't reproduce this at all; I use dump and restore quite
regularly in this way, and I have never encountered this issue (except
for the occasional 'expected file NNN, got file MMM', which is usually
harmless).
Maybe the dump output gets corrupted in some way? (E.g. faulty RAM, or
disk?) If you are dumping a live filesystem, could it possibly help to
add the -L option?
Hywel Mallett
> On 2009-03-24 07:30, Mikhail T. wrote:
>> dump a0f - /old | restore -rf -
>> [...]
>> DUMP: 17.25% done, finished in 3:27 at Tue Mar 24 05:42:00 2009
>> DUMP: 20.36% done, finished in 3:09 at Tue Mar 24 05:28:13 2009
>> DUMP: 23.83% done, finished in 2:50 at Tue Mar 24 05:14:32 2009
>> unknown tape header type -621260722
>> abort? [yn]
>>
>> Looks like a junk value somewhere... Unitialized variable or some such.
Looking at the restore code (tape.c, in findinode), restore is =20
expecting a header type in the range 1-6, so the header type =20
-621260722 is way out. Assuming that findinode is being passed the =20
correct variable, it would indicate that dump is writing the header =20
(or at least the header type incorrectly). I can't work out where this =20
header is getting written though. It looks like plenty of data gets =20
written into a header (such as inode, magic number, checksum). I =20
wonder if one of these values is overflowing and overwriting the =20
header type?
>
> Maybe the dump output gets corrupted in some way? (E.g. faulty RAM, or
> disk?) If you are dumping a live filesystem, could it possibly help to
> add the -L option?
It might be worth fscking the original volume (though I suspect the OP =20
has done this already), and also passing the -D option to restore, as =20
restore will then try and continue, rather than abort on getting the =20
invalid header type. Fixing the root cause would be better, but that =20
might be a workaround for now.
David Malone
> Same problem:
>
> restore -rf ibmo.0.2009-03-24.dump
> load: 0.55 cmd: restore 11303 [nbufkv] 3.53u 3.91s 4% 27980k
> abort? [yn]
>
Hi Mikhail,
If you actually need to get a dump back that restore can't read,
you can try the "-D" option that I added a few years ago. Dump and
restore expect things to be in a block format, but if (say) dump
outputs a few bytes into the stream due to a bug, then the entire
end of the dump can become unreadable. The -D option to restore
tells it to try hard to get back in sync again.
I'd guess you've tripped over either a bug in dump or restore. If
you can file a PR, particularly with access to a sample dump, then
I can have a look and see if I can figure out what's going on.
Daid.
Eugene Gladchenko
This is a cryptographically signed message in MIME format.
------------E4199112C0777C1
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Mikhail,
MT> I'm trying to migrate a filesystem from one disk to another using:
MT> dump a0hCf 0 32 - /old | restore -rf -
MT> (/old is already mounted read-only). The process runs for a while and
MT> then stops with:
MT> [...]
MT> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
MT> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
MT> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
MT> unknown tape header type 1853384566
MT> abort? [yn]
MT> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
MT> dump's output?
Is your /tmp large enough to restore?
--=20
Eugene Gladchenko
EVG15-RIPE
------------E4199112C0777C1--
Rolf G Nielsen
> Hello!
>
> I'm trying to migrate a filesystem from one disk to another using:
>
Try
dump -a0 -h 0 -C 32 -f - /old
instead.
Your command line should work, but I've had trouble with similar ones
and have been able to solve it by separating the options.
>
> (/old is already mounted read-only). The process runs for a while and
> then stops with:
>
> [...]
> DUMP: 22.85% done, finished in 3:57 at Tue Mar 24 01:03:21 2009
> DUMP: 24.66% done, finished in 3:50 at Tue Mar 24 01:00:58 2009
> DUMP: 26.44% done, finished in 3:43 at Tue Mar 24 00:59:14 2009
> unknown tape header type 1853384566
> abort? [yn]
>
> Any idea, what's going on? Why can't FreeBSD's restore read FreeBSD's
> dump's output?
>
> The system runs 7.0-STABLE from July 6th, i386. I just tried updating
> the dump and restore from source (latest 7.x) -- the error is the same...
>
> Please, advise. Thanks!
>
> -mi
>
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
>
>
>
--
Sincerly,
Rolf Nielsen
Greg Black
> Greg Black ???????(??):
>> On 2009-03-24, Mikhail T. wrote:
>>
>>> That's true. I just wanted to point out, that someone running dump only
>>> (to make backups) is not going to know, whether his dumps are usable
>>> (for whichever of the two reasons), until he needs them...
>>
>> Such a person is not making backups and deserves what he gets.
>>
> But he *is* making backups -- kindly re-read my paragraph above... He
> just is not routinely using them and thus does not know, that they
> aren't usable... It is not unreasonable to expect the two utilities to
> "just work", so I wouldn't be blaming such a person for not testing
> restore.
Sorry, this person is *not* making backups in any meaningful fashion.
Unless you verify regularly (preferably every time you make a backup)
that you can restore both parts of the backup and the entire thing, you
are not making backups. You may be lucky, but you probably won't be
lucky when it really matters.
This is a long-standing issue with backups. But people who don't
understand the tools they are using tend to make these mistakes. The
result is bad. The solution is to employ competent people who both
understand the issues and have the authority to carry out their task.
Doug Barton
> Sorry, this person is *not* making backups in any meaningful fashion.
> Unless you verify regularly (preferably every time you make a backup)
> that you can restore both parts of the backup and the entire thing, you
> are not making backups. You may be lucky, but you probably won't be
> lucky when it really matters.
s/making backups/employing an effective data recovery strategy/
Please don't feed the "proper use of language" trolls. :)
Meanwhile, we may want to consider that this whole thread is veering
off topic ...
Doug
--
This .signature sanitized for your protection