From: James R. <ja...@kr...> - 2003-12-08 20:28:18
|
Hi, I'm getting the following message when restoring. $ restore -iv Verify tape and initialize maps Input is from a local tape Tape block size is 32 Dump date: Fri Dec 5 00:12:05 2003 Dumped from: Tue Oct 28 15:21:11 2003 Level 1 dump of /store on orca:/dev/md0 Label: orca restore: Cannot find file dump list The tape was created using a command like this: ssh orca dump -u -0 /store -f - | dd ibs=512 obs=512 of=/dev/tape conv=sync DDS4 tape drive Linux x86 with a heavily upgraded Redhat 6.2 distro restore 0.4b34 (using libext2fs 1.34 of 25-Jul-2003) Tape block size 512 bytes. Density code 0x26 (DDS-4 or QIC-4GB). Is there a way to recover this? I tried... dd bs=512 if=/dev/tape of=temp.bin restore -iv -f temp.bin ...but got the same results. James |
From: Stelian P. <st...@po...> - 2003-12-08 22:26:56
|
On Mon, Dec 08, 2003 at 03:16:03PM -0500, James Roth wrote: > Hi, > > I'm getting the following message when restoring. > > $ restore -iv > Verify tape and initialize maps > Input is from a local tape > Tape block size is 32 > Dump date: Fri Dec 5 00:12:05 2003 > Dumped from: Tue Oct 28 15:21:11 2003 > Level 1 dump of /store on orca:/dev/md0 > Label: orca > restore: Cannot find file dump list > > The tape was created using a command like this: > ssh orca dump -u -0 /store -f - | dd ibs=512 obs=512 of=/dev/tape conv=sync > > DDS4 tape drive > Linux x86 with a heavily upgraded Redhat 6.2 distro > restore 0.4b34 (using libext2fs 1.34 of 25-Jul-2003) > Tape block size 512 bytes. Density code 0x26 (DDS-4 or QIC-4GB). > > Is there a way to recover this? > I tried... > > dd bs=512 if=/dev/tape of=temp.bin > restore -iv -f temp.bin Try: restore -iv -f temp.bin -b 10 but I'm not sure it will help... Are you sure the tape blocksize (as per mt setblk) hasn't changed between the dump and the restore ? Stelian. -- Stelian Pop <st...@po...> |
From: James R. <ja...@kr...> - 2003-12-08 22:41:15
|
Stelian Pop wrote: >On Mon, Dec 08, 2003 at 03:16:03PM -0500, James Roth wrote: > > > >>Hi, >> >> I'm getting the following message when restoring. >> >>$ restore -iv >>Verify tape and initialize maps >>Input is from a local tape >>Tape block size is 32 >>Dump date: Fri Dec 5 00:12:05 2003 >>Dumped from: Tue Oct 28 15:21:11 2003 >>Level 1 dump of /store on orca:/dev/md0 >>Label: orca >>restore: Cannot find file dump list >> >>The tape was created using a command like this: >>ssh orca dump -u -0 /store -f - | dd ibs=512 obs=512 of=/dev/tape conv=sync >> >>DDS4 tape drive >>Linux x86 with a heavily upgraded Redhat 6.2 distro >>restore 0.4b34 (using libext2fs 1.34 of 25-Jul-2003) >>Tape block size 512 bytes. Density code 0x26 (DDS-4 or QIC-4GB). >> >>Is there a way to recover this? >>I tried... >> >> dd bs=512 if=/dev/tape of=temp.bin >> restore -iv -f temp.bin >> >> > >Try: > restore -iv -f temp.bin -b 10 > >but I'm not sure it will help... > >Are you sure the tape blocksize (as per mt setblk) hasn't changed >between the dump and the restore ? > >Stelian. > > Thanks for the reply. I tried -b 10 as well as 1, 2, 3, ... 32, 64, etc. From my backup log: "DUMP: Writing 10 Kilobyte records" Also, my script sets the block size to 512 before each dump. Does my "dd ibs=512 obs=512 of=/dev/tape conv=sync" look suspicious to anyone? James |
From: James R. <ja...@kr...> - 2003-12-08 23:18:36
|
James Roth wrote: >>> Hi, >>> >>> I'm getting the following message when restoring. >>> >>> $ restore -iv >>> Verify tape and initialize maps >>> Input is from a local tape >>> Tape block size is 32 >>> Dump date: Fri Dec 5 00:12:05 2003 >>> Dumped from: Tue Oct 28 15:21:11 2003 >>> Level 1 dump of /store on orca:/dev/md0 >>> Label: orca >>> restore: Cannot find file dump list >>> >>> The tape was created using a command like this: >>> ssh orca dump -u -0 /store -f - | dd ibs=512 obs=512 of=/dev/tape >>> conv=sync >>> >>> DDS4 tape drive >>> Linux x86 with a heavily upgraded Redhat 6.2 distro >>> restore 0.4b34 (using libext2fs 1.34 of 25-Jul-2003) >>> Tape block size 512 bytes. Density code 0x26 (DDS-4 or QIC-4GB). >>> >>> Is there a way to recover this? >>> I tried... >>> >>> dd bs=512 if=/dev/tape of=temp.bin >>> restore -iv -f temp.bin >>> >> More clues. Looking at a different partition from the same machine yields a different error: restore -iv Verify tape and initialize maps Input is from a local tape Tape block size is 32 Dump date: Thu Dec 4 00:09:52 2003 Dumped from: Tue Oct 28 15:15:21 2003 Level 1 dump of / on orca:/dev/sda6 Label: orca Extract directories from tape Checksum error 14534106460, inode 48294 file <directory file - name unknown> Mangled directory: reclen not multiple of 4 resync restore, skipped 101 blocks Initialize symbol table. restore > Maybe this old 6.2 redhat box has some libc issues. Kernel 2.4.18 looks like GLIBC_2.1.3. Restoring from a newer machine does not help. Thanks, James |
From: Stelian P. <st...@po...> - 2003-12-09 08:16:01
|
On Mon, Dec 08, 2003 at 06:06:21PM -0500, James Roth wrote: > More clues. Looking at a different partition from the same machine > yields a different error: > > restore -iv > Verify tape and initialize maps > Input is from a local tape > Tape block size is 32 > Dump date: Thu Dec 4 00:09:52 2003 > Dumped from: Tue Oct 28 15:15:21 2003 > Level 1 dump of / on orca:/dev/sda6 > Label: orca > Extract directories from tape > Checksum error 14534106460, inode 48294 file <directory file - name unknown> > Mangled directory: reclen not multiple of 4 > resync restore, skipped 101 blocks > Initialize symbol table. > restore > > > Maybe this old 6.2 redhat box has some libc issues. Kernel 2.4.18 looks > like GLIBC_2.1.3. Restoring from a newer machine does not help. This really looks like your tapes are corrupt. Try cleaning your drive head, reading in a different drive might help. But if the issue is really the magnetic media, I'm afraid you won't be able to restore them. Just to be sure, take a new tape, do a dump on it and try to restore (using the same parameters - dd et al - you were using before). If what goes wrong is in the setup, then you won't be able to restore it. On the other hand, if you restore it just fine, then the problem lies on the old medium... Stelian. -- Stelian Pop <st...@po...> |
From: Stelian P. <st...@po...> - 2003-12-09 08:11:49
|
On Mon, Dec 08, 2003 at 05:28:57PM -0500, James Roth wrote: > I tried -b 10 as well as 1, 2, 3, ... 32, 64, etc. From my backup log: > "DUMP: Writing 10 Kilobyte records" > > Also, my script sets the block size to 512 before each dump. > > Does my "dd ibs=512 obs=512 of=/dev/tape conv=sync" look suspicious to > anyone? It does seem suspicious to me, as is the fact you're using a 512 byte blocksize with a DDS4 drive, which should use much larger blocksizes (32k for example) or variable block sizes (mt setblk 0) in order to gain both speed and capacity. Stelian. -- Stelian Pop <st...@po...> |