Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Anthony l]

[-- Attachment #1.1: Type: text/plain, Size: 2371 bytes --]

Hello Anthony here,

I'm not sure if this is the correct place to send a question, If I am wrong I would appreciate if you could send me in the right direction.  I have come across the oss.sgi forums a lot looking for a solution to my problem but I could not find much.


Here's my situation.

I have a bunch a tapes that were created way back when using an IRIX system. Some kind of version 6, perhaps even the latest version. anyway I am able to peak at the headers to determind the the file type on the drive is indeed:

xFSdump0....   or when I make a sample using 'dd if=/dev/nst0 of=./test.img' '+ 'file test.img' I get XFSDUMP archive (version 2)

So, instinctively to get the data off the tapes I would think would be as simple as:

sudo xfsrestore -f /dev/nst0 ./path to where I want it stored

Then I get:

using dump format 3

xfsrestore: searching media for dump

xfsrestore: preparing drive

xfsrestore: examining media file 1

...

xfsrestore examining media file xx

the following dump has been found on drive 0:

hostname: isp---------(stuff)

mount point: /isp-iga

volume: /dev/rdsk/sks0d2s7

session time: Mon Jan 10 11:47:42 2005

media label: "backup"

file system id: xxx....

session id: xxx...

media id:...

restore this dump?

1: skip

2: restore (default)

> 2 (enter)


======

examining media file 0

reading directories

examining media file 1

reading directories

... and so on

no files selected for restoral



====

1: media change declined (timeout 3600 seconds)

2: display media inventory status

3: list needed media objects

4: change media (default)


3 and 4 do nothing

I get no media needed. and If I press 4 same menu comes back.

2: media file xxx (xxx) where xxx is a number

used for directory restoral

first extent contained: ino xxxxxxxxxxxx off 0

next extent to restore: ino (same as above) off 0



and If I click 1:

restoral interrupted use -R

restore summery:

stream 0: /dev/nst0 quit media no longer usable

restore status: QUIT


Then if I got to the directory where I pointed all I have is:

orphanage/

xfsrestorehelperblahblah/

where orphangae is empty and the other contains like 5 files that are just something else.

What am I doing wrong here ?? any help would be great.

Thanks



[-- Attachment #1.2: Type: text/html, Size: 3264 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Eric Sandeen]

On 6/29/16 1:48 PM, Anthony l wrote:
> Hello Anthony here,
> 
> I'm not sure if this is the correct place to send a question, If I am
> wrong I would appreciate if you could send me in the right direction.
> I have come across the oss.sgi forums a lot looking for a solution to
> my problem but I could not find much.
> 

Sure, it's a fine place.  Question below.

> 
> Here's my situation.
> 
> I have a bunch a tapes that were created way back when using an IRIX
> system. Some kind of version 6, perhaps even the latest version.
> anyway I am able to peak at the headers to determind the the file
> type on the drive is indeed:
> 
> xFSdump0.... or when I make a sample using 'dd if=/dev/nst0
> of=./test.img' '+ 'file test.img' I get XFSDUMP archive (version 2)
> 
> So, instinctively to get the data off the tapes I would think would
> be as simple as:
> 
> sudo xfsrestore -f /dev/nst0 ./path to where I want it stored
> 
> Then I get:
> 
> using dump format 3
> 
> xfsrestore: searching media for dump
> 
> xfsrestore: preparing drive
> 
> xfsrestore: examining media file 1
> 
> ...
> 
> xfsrestore examining media file xx
> 
> the following dump has been found on drive 0:
> 
> hostname: isp---------(stuff)
> 
> mount point: /isp-iga
> 
> volume: /dev/rdsk/sks0d2s7
> 
> session time: Mon Jan 10 11:47:42 2005
> 
> media label: "backup"
> 
> file system id: xxx....
> 
> session id: xxx...
> 
> media id:...
> 
> restore this dump?
> 
> 1: skip
> 
> 2: restore (default)
> 
>> 2 (enter)
> 

> ====== 
> 
> examining media file 0
> reading directories
> examining media file 1
> reading directories
> ... and so on
> no files selected for restoral

That doesn't seem to be an actual xfsdump error string, is it?

Maybe you can capture and include the entire xfsdump output, or put it
in a pastebin somewhere?  By the time things get hand-transcribed it's
easy to lose important bits.

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Dave Chinner]

On Wed, Jun 29, 2016 at 06:48:29PM +0000, Anthony l wrote:
> Hello Anthony here,
> 
> I'm not sure if this is the correct place to send a question, If I am wrong I would appreciate if you could send me in the right direction.  I have come across the oss.sgi forums a lot looking for a solution to my problem but I could not find much.
> 
> 
> Here's my situation.
> 
> I have a bunch a tapes that were created way back when using an IRIX system. Some kind of version 6, perhaps even the latest version. anyway I am able to peak at the headers to determind the the file type on the drive is indeed:
> 
> xFSdump0....   or when I make a sample using 'dd if=/dev/nst0 of=./test.img' '+ 'file test.img' I get XFSDUMP archive (version 2)

dump version 2....

> So, instinctively to get the data off the tapes I would think would be as simple as:
> 
> sudo xfsrestore -f /dev/nst0 ./path to where I want it stored
> 
> Then I get:
> 
> using dump format 3

Oops, wrong format version.

> What am I doing wrong here ?? any help would be great.

Try telling restore to use dump format version 2 by using the -K
option.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Anthony l]

[-- Attachment #1.1: Type: text/plain, Size: 509 bytes --]

Thanks for replying. I made a Paste bin of the output I'm getting. This time I used the -K option which is to force use compatibility with older versions of xfs I think.

http://pastebin.com/vrL6iiW2



There is my full output to what I am getting. Not actually getting an error code I just don't understand why this wouldn't work. Also If I chose skip instead of restore ill get to some different dumps. But same thing happens if I choose restore on those too.

Thanks for the reply Dave and Eric


[-- Attachment #1.2: Type: text/html, Size: 1048 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Eric Sandeen]

On 6/30/16 10:35 AM, Anthony l wrote:
> Thanks for replying. I made a Paste bin of the output I'm getting.
> This time I used the -K option which is to force use compatibility
> with older versions of xfs I think.
> 
> http://pastebin.com/vrL6iiW2
> 
> 
> 
> There is my full output to what I am getting. Not actually getting an
> error code I just don't understand why this wouldn't work. Also If I
> chose skip instead of restore ill get to some different dumps. But
> same thing happens if I choose restore on those too.

You might also look at

http://oss.sgi.com/archives/xfs/2005-01/msg00418.html

and try another run with maximum verbosity as that user 
did.

Is this a multi-tape dump?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Anthony l]

[-- Attachment #1.1: Type: text/plain, Size: 952 bytes --]

I don't think this is a multi tape dump. But then again i don't know for sure. I recently got a job and this is my first 'project'. I have about 10 tapes each are labeled a month and a year, so I don't think they are multi tape because they span like 3 years 2004-2007 . Although for the current tape I am working on right now if I select 1 skip, I'll get to another back up labeled "incremental backup 1" or something similar. Using the verbosity output here is what I got. (also using interactive restore). I went ahead and specified byte size 4096. Through earlier test using the dd command I determined that was the correct size. Ill post one without byte size specified too. I just saw it in that post and thought it might help.

Here is the output with verbosity.

http://pastebin.com/Nd6BqNc5

The out is the same with or without -b 4096.

http://pastebin.com/0dxbCvyc (no -b)


-Anthony

<http://oss.sgi.com/mailman/listinfo/xfs>

[-- Attachment #1.2: Type: text/html, Size: 2202 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Eric Sandeen]

On 6/30/16 11:59 AM, Anthony l wrote:
> I don't think this is a multi tape dump. But then again i don't know for sure. I recently got a job and this is my first 'project'. I have about 10 tapes each are labeled a month and a year, so I don't think they are multi tape because they span like 3 years 2004-2007 . Although for the current tape I am working on right now if I select 1 skip, I'll get to another back up labeled "incremental backup 1" or something similar. Using the verbosity output here is what I got. (also using interactive restore). I went ahead and specified byte size 4096. Through earlier test using the dd command I determined that was the correct size. Ill post one without byte size specified too. I just saw it in that post and thought it might help.
> 
> Here is the output with verbosity.
> 
> http://pastebin.com/Nd6BqNc5
> 
> The out is the same with or without -b 4096.
> 
> http://pastebin.com/0dxbCvyc (no -b)


interactively restore from this dump?
1: skip
2: interactively restore
 (default)
->2
++++================++++
missing some stuff------

^^^ is that your comment, or actual output?

Looks like it eventually encountered a short read:

xfsrestore: drive op: read: wanted 131072 (0x20000)
xfsrestore: tape op: reading 245760 bytes
xfsrestore: tape op read of 245760 bytes short: nread == 4096
xfsrestore: tape op: get status
xfsrestore: tape status = wprot onl
xfsrestore: short read record 1 (nread == 4096)
xfsrestore: drive op read returning error rval=1

in dmesg, is there any sort of IO error from the tape?

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Anthony l]

[-- Attachment #1.1: Type: text/plain, Size: 9577 bytes --]

I put that, but I suppose if I am trouble shooting thats not the best idea. That was all I was able to see. I just ran the command and moved all the out put to a file here is a complete paste of the entire verbosity out.
http://pastebin.com/UW9zRAZ0    (full verbosity out)
Nothing looks like its producing an error which is why I am so confused.

and cat/var/log/dmesg | grep -i st0  (tape connector)
$ cat /var/log/dmesg | grep -i st0
[    1.036623] scsi host0: ata_piix
[   16.613496] st 6:0:0:0: Attached scsi tape st0
[   16.613500] st 6:0:0:0: st0: try direct i/o: yes (alignment 4 B)



$ cat /var/log/dmesg | grep -i scsi
[    0.429954] SCSI subsystem initialized
[    0.827902] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    1.036623] scsi host0: ata_piix
[    1.036699] scsi host1: ata_piix
[    1.192299] scsi host2: ata_piix
[    1.192390] scsi host3: ata_piix
[    1.193129] scsi host4: ata_generic
[    1.193216] scsi host5: ata_generic
[    1.864429] scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HE160HJ  0-24 PQ: 0 ANSI: 5
[    1.864648] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    1.867113] scsi 1:0:1:0: CD-ROM            PLDS     DVD+-RW DH-16A6S YD12 PQ: 0 ANSI: 5
[    1.882378] sr 1:0:1:0: [sr0] scsi3-mmc drive: 48x/12x writer dvd-ram cd/rw xa/form2 cdda tray
[    1.882516] sr 1:0:1:0: Attached scsi CD-ROM sr0
[    1.882574] sr 1:0:1:0: Attached scsi generic sg1 type 5
[    1.898525] sd 0:0:0:0: [sda] Attached SCSI disk
[    7.328020] scsi host6: Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 3.0
[    7.328020]         <Adaptec 29320LP Ultra320 SCSI adapter>
[    7.328020]         aic7901A: Ultra320 Wide Channel A, SCSI Id=5, PCI 33 or 66MHz, 512 SCBs
[    7.329000] scsi target6:0:0: asynchronous
[    7.330396] scsi 6:0:0:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.330404] scsi target6:0:0: Beginning Domain Validation
[    7.334243] scsi target6:0:0: wide asynchronous
[    7.337044] scsi target6:0:0: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.349735] scsi target6:0:0: Ending Domain Validation
[    7.352917] scsi target6:0:1: asynchronous
[    7.354313] scsi 6:0:1:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.354319] scsi target6:0:1: Beginning Domain Validation
[    7.358061] scsi target6:0:1: wide asynchronous
[    7.361002] scsi target6:0:1: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.373736] scsi target6:0:1: Ending Domain Validation
[    7.376870] scsi target6:0:2: asynchronous
[    7.378273] scsi 6:0:2:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.378279] scsi target6:0:2: Beginning Domain Validation
[    7.381828] scsi target6:0:2: wide asynchronous
[    7.384690] scsi target6:0:2: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.397361] scsi target6:0:2: Ending Domain Validation
[    7.400499] scsi target6:0:3: asynchronous
[    7.401901] scsi 6:0:3:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.401907] scsi target6:0:3: Beginning Domain Validation
[    7.405763] scsi target6:0:3: wide asynchronous
[    7.408555] scsi target6:0:3: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.421233] scsi target6:0:3: Ending Domain Validation
[    7.424407] scsi target6:0:4: asynchronous
[    7.425819] scsi 6:0:4:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.425825] scsi target6:0:4: Beginning Domain Validation
[    7.429636] scsi target6:0:4: wide asynchronous
[    7.432427] scsi target6:0:4: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.445294] scsi target6:0:4: Ending Domain Validation
[    7.448422] scsi target6:0:6: asynchronous
[    7.449838] scsi 6:0:6:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.449845] scsi target6:0:6: Beginning Domain Validation
[    7.453663] scsi target6:0:6: wide asynchronous
[    7.456487] scsi target6:0:6: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.469217] scsi target6:0:6: Ending Domain Validation
[    7.472339] scsi target6:0:7: asynchronous
[    7.473800] scsi 6:0:7:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.473807] scsi target6:0:7: Beginning Domain Validation
[    7.477631] scsi target6:0:7: wide asynchronous
[    7.480481] scsi target6:0:7: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.493222] scsi target6:0:7: Ending Domain Validation
[    7.496351] scsi target6:0:8: asynchronous
[    7.497771] scsi 6:0:8:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.497778] scsi target6:0:8: Beginning Domain Validation
[    7.501488] scsi target6:0:8: wide asynchronous
[    7.504429] scsi target6:0:8: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.517155] scsi target6:0:8: Ending Domain Validation
[    7.520280] scsi target6:0:9: asynchronous
[    7.521668] scsi 6:0:9:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.521675] scsi target6:0:9: Beginning Domain Validation
[    7.525473] scsi target6:0:9: wide asynchronous
[    7.528407] scsi target6:0:9: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.541143] scsi target6:0:9: Ending Domain Validation
[    7.544314] scsi target6:0:10: asynchronous
[    7.545727] scsi 6:0:10:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.545735] scsi target6:0:10: Beginning Domain Validation
[    7.549442] scsi target6:0:10: wide asynchronous
[    7.552280] scsi target6:0:10: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.564984] scsi target6:0:10: Ending Domain Validation
[    7.568067] scsi target6:0:11: asynchronous
[    7.569451] scsi 6:0:11:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.569459] scsi target6:0:11: Beginning Domain Validation
[    7.573197] scsi target6:0:11: wide asynchronous
[    7.576047] scsi target6:0:11: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.588771] scsi target6:0:11: Ending Domain Validation
[    7.591894] scsi target6:0:12: asynchronous
[    7.593326] scsi 6:0:12:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.593334] scsi target6:0:12: Beginning Domain Validation
[    7.597156] scsi target6:0:12: wide asynchronous
[    7.599974] scsi target6:0:12: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.612720] scsi target6:0:12: Ending Domain Validation
[    7.615848] scsi target6:0:13: asynchronous
[    7.617212] scsi 6:0:13:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.617220] scsi target6:0:13: Beginning Domain Validation
[    7.620943] scsi target6:0:13: wide asynchronous
[    7.623937] scsi target6:0:13: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.636720] scsi target6:0:13: Ending Domain Validation
[    7.639849] scsi target6:0:14: asynchronous
[    7.641217] scsi 6:0:14:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.641225] scsi target6:0:14: Beginning Domain Validation
[    7.644860] scsi target6:0:14: wide asynchronous
[    7.647710] scsi target6:0:14: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.660427] scsi target6:0:14: Ending Domain Validation
[    7.663613] scsi target6:0:15: asynchronous
[    7.665008] scsi 6:0:15:0: Sequential-Access QUANTUM  SDLT600          2B2B PQ: 0 ANSI: 4
[    7.665016] scsi target6:0:15: Beginning Domain Validation
[    7.668828] scsi target6:0:15: wide asynchronous
[    7.671621] scsi target6:0:15: FAST-80 WIDE SCSI 160.0 MB/s DT (12.5 ns, offset 120)
[    7.684311] scsi target6:0:15: Ending Domain Validation
[    7.686630] scsi 6:0:0:0: Attached scsi generic sg2 type 1
[    7.686795] scsi 6:0:1:0: Attached scsi generic sg3 type 1
[    7.686956] scsi 6:0:2:0: Attached scsi generic sg4 type 1
[    7.687115] scsi 6:0:3:0: Attached scsi generic sg5 type 1
[    7.687276] scsi 6:0:4:0: Attached scsi generic sg6 type 1
[    7.687437] scsi 6:0:6:0: Attached scsi generic sg7 type 1
[    7.687598] scsi 6:0:7:0: Attached scsi generic sg8 type 1
[    7.687761] scsi 6:0:8:0: Attached scsi generic sg9 type 1
[    7.687924] scsi 6:0:9:0: Attached scsi generic sg10 type 1
[    7.688089] scsi 6:0:10:0: Attached scsi generic sg11 type 1
[    7.688249] scsi 6:0:11:0: Attached scsi generic sg12 type 1
[    7.688409] scsi 6:0:12:0: Attached scsi generic sg13 type 1
[    7.688569] scsi 6:0:13:0: Attached scsi generic sg14 type 1
[    7.688731] scsi 6:0:14:0: Attached scsi generic sg15 type 1
[    7.688893] scsi 6:0:15:0: Attached scsi generic sg16 type 1
[   16.613496] st 6:0:0:0: Attached scsi tape st0
[   16.617070] st 6:0:1:0: Attached scsi tape st1
[   16.638012] st 6:0:2:0: Attached scsi tape st2
[   16.638789] st 6:0:3:0: Attached scsi tape st3
[   16.639266] st 6:0:4:0: Attached scsi tape st4
[   16.639837] st 6:0:6:0: Attached scsi tape st5
[   16.640425] st 6:0:7:0: Attached scsi tape st6
[   16.640905] st 6:0:8:0: Attached scsi tape st7
[   16.641381] st 6:0:9:0: Attached scsi tape st8
[   16.641998] st 6:0:10:0: Attached scsi tape st9
[   16.642563] st 6:0:11:0: Attached scsi tape st10
[   16.643069] st 6:0:12:0: Attached scsi tape st11
[   16.643545] st 6:0:13:0: Attached scsi tape st12
[   16.644117] st 6:0:14:0: Attached scsi tape st13
[   16.644597] st 6:0:15:0: Attached scsi tape st14

<http://oss.sgi.com/mailman/listinfo/xfs>

[-- Attachment #1.2: Type: text/html, Size: 14015 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Dave Chinner]

On Thu, Jun 30, 2016 at 12:04:07PM -0500, Eric Sandeen wrote:
> 
> 
> On 6/30/16 11:59 AM, Anthony l wrote:
> > I don't think this is a multi tape dump. But then again i don't know for sure. I recently got a job and this is my first 'project'. I have about 10 tapes each are labeled a month and a year, so I don't think they are multi tape because they span like 3 years 2004-2007 . Although for the current tape I am working on right now if I select 1 skip, I'll get to another back up labeled "incremental backup 1" or something similar. Using the verbosity output here is what I got. (also using interactive restore). I went ahead and specified byte size 4096. Through earlier test using the dd command I determined that was the correct size. Ill post one without byte size specified too. I just saw it in that post and thought it might help.
> > 
> > Here is the output with verbosity.
> > 
> > http://pastebin.com/Nd6BqNc5
> > 
> > The out is the same with or without -b 4096.
> > 
> > http://pastebin.com/0dxbCvyc (no -b)
> 
> 
> interactively restore from this dump?
> 1: skip
> 2: interactively restore
>  (default)
> ->2
> ++++================++++
> missing some stuff------
> 
> ^^^ is that your comment, or actual output?
> 
> Looks like it eventually encountered a short read:
> 
> xfsrestore: drive op: read: wanted 131072 (0x20000)
> xfsrestore: tape op: reading 245760 bytes
> xfsrestore: tape op read of 245760 bytes short: nread == 4096
> xfsrestore: tape op: get status
> xfsrestore: tape status = wprot onl
> xfsrestore: short read record 1 (nread == 4096)
> xfsrestore: drive op read returning error rval=1
> 
> in dmesg, is there any sort of IO error from the tape?

So xfs_reatore is wanting to find the session inventory in that
last media file, and it would appear that it isn't there or shorter
than expected. A tape problem, perhaps? Have you tried running
xfs_restore using the minimal tape protocol (-m)?

Another option is to try to restore the dump files from tape to a
local file on disk and see if that can be parsed instead.

The other thing you might want to do is upgrade xfsdump to the
latest version - you're running 3.1.1 and the current version is
3.1.6. I doubt it will change the behaviour, but at least it will
give us something to work from...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Andrew Ho]

I did restore the irix tape on Linux by using the command "tar".  tar xv is for restore.
If the tape was backup by a propriety backup software on SGI Irix, it is difficult to restore on Linux.

     Andrew

     Pressure creates diamond.

> On Jun 30, 2016, at 6:07 PM, Dave Chinner <david@fromorbit.com> wrote:
> 
>> On Thu, Jun 30, 2016 at 12:04:07PM -0500, Eric Sandeen wrote:
>> 
>> 
>>> On 6/30/16 11:59 AM, Anthony l wrote:
>>> I don't think this is a multi tape dump. But then again i don't know for sure. I recently got a job and this is my first 'project'. I have about 10 tapes each are labeled a month and a year, so I don't think they are multi tape because they span like 3 years 2004-2007 . Although for the current tape I am working on right now if I select 1 skip, I'll get to another back up labeled "incremental backup 1" or something similar. Using the verbosity output here is what I got. (also using interactive restore). I went ahead and specified byte size 4096. Through earlier test using the dd command I determined that was the correct size. Ill post one without byte size specified too. I just saw it in that post and thought it might help.
>>> 
>>> Here is the output with verbosity.
>>> 
>>> http://pastebin.com/Nd6BqNc5
>>> 
>>> The out is the same with or without -b 4096.
>>> 
>>> http://pastebin.com/0dxbCvyc (no -b)
>> 
>> 
>> interactively restore from this dump?
>> 1: skip
>> 2: interactively restore
>> (default)
>> ->2
>> ++++================++++
>> missing some stuff------
>> 
>> ^^^ is that your comment, or actual output?
>> 
>> Looks like it eventually encountered a short read:
>> 
>> xfsrestore: drive op: read: wanted 131072 (0x20000)
>> xfsrestore: tape op: reading 245760 bytes
>> xfsrestore: tape op read of 245760 bytes short: nread == 4096
>> xfsrestore: tape op: get status
>> xfsrestore: tape status = wprot onl
>> xfsrestore: short read record 1 (nread == 4096)
>> xfsrestore: drive op read returning error rval=1
>> 
>> in dmesg, is there any sort of IO error from the tape?
> 
> So xfs_reatore is wanting to find the session inventory in that
> last media file, and it would appear that it isn't there or shorter
> than expected. A tape problem, perhaps? Have you tried running
> xfs_restore using the minimal tape protocol (-m)?
> 
> Another option is to try to restore the dump files from tape to a
> local file on disk and see if that can be parsed instead.
> 
> The other thing you might want to do is upgrade xfsdump to the
> latest version - you're running 3.1.1 and the current version is
> 3.1.6. I doubt it will change the behaviour, but at least it will
> give us something to work from...
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Anthony l]

[-- Attachment #1.1: Type: text/plain, Size: 1093 bytes --]

Thanks for the suggestions again.

Still banging my head against a wall.

So  I was trying a bunch of xfsrestore commands anything from -m -k -b to all three but still the same result every time.

xfsrestore -K -m -b 4096 -f /dev/nst0 ./

xfsrestore  -K -r -f /dev/nst0 ./


I don't think this is a corrupt tape or anything because I have around 7 -10 tapes that are all made on the irix machine, but all behave the same. I have tried tar before but I get this is not a tar file or gzip file something like that.

But I do have an observation. I had a tape (not made on the irix system) and I was able to pull a direct transfer of files with the dd command. i.e dd if=/dev/nst0 of=./somefile1 ibs =64k

And I would only have to do this 3 -4 times to get like 30+ GBs of data off the tapes and a simple tar xvf command extracted these files just fine. But my question is how come when I try to do these with the tapes made on the Irix machine I only get about 200 mb at a time and there are like 190+ files on each tape. Is this normal for an xfs file system on a tape drive?


[-- Attachment #1.2: Type: text/html, Size: 1652 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Roger Willcocks]

xfsrestore: tape op: reading 245760 bytes
xfsrestore: tape op read of 245760 bytes short: nread == 4096

I think this is the crux -- regardless of the record size xfsrestore
expects, it only ever gets the first 4k block.

This is probably a limitation of the tape drive or the driver.

I'd try:

# mt -f /dev/nst0 setblk 0
# xfsrestore -m -b 245760 -v5 -f /dev/nst0 .


--
Roger



On Fri, 2016-07-01 at 18:23 +0000, Anthony l wrote:
> Thanks for the suggestions again. 
> 
> Still banging my head against a wall. 
> 
> So  I was trying a bunch of xfsrestore commands anything from -m -k -b
> to all three but still the same result every time. 
> 
> xfsrestore -K -m -b 4096 -f /dev/nst0 ./
> 
> xfsrestore  -K -r -f /dev/nst0 ./ 
> 
> 
> I don't think this is a corrupt tape or anything because I have around
> 7 -10 tapes that are all made on the irix machine, but all behave the
> same. I have tried tar before but I get this is not a tar file or gzip
> file something like that. 
> 
> But I do have an observation. I had a tape (not made on the irix
> system) and I was able to pull a direct transfer of files with the dd
> command. i.e dd if=/dev/nst0 of=./somefile1 ibs =64k 
> 
> And I would only have to do this 3 -4 times to get like 30+ GBs of
> data off the tapes and a simple tar xvf command extracted these files
> just fine. But my question is how come when I try to do these with the
> tapes made on the Irix machine I only get about 200 mb at a time and
> there are like 190+ files on each tape. Is this normal for an xfs file
> system on a tape drive?
> 
> 
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Anthony l]

[-- Attachment #1.1: Type: text/plain, Size: 664 bytes --]

Yes so no luck yet. Even specifying the block size as 24576.

But I did come across something interesting. I decided to give up on these tapes and try out some other ones. One tape in particular was listed as an Amanda dump file. upon researching I came across a page labeled Amanda Cheat Sheet. http://www.mast.queensu.ca/computing/department/service.catalogue/backup/cheat-sheet.html

On that site there is a section talking about XFS file systems, SGI, and restoring them using Amanda + xfsrestore. Ill give this a shot I just got to figure out how to use Amanda on a local machine.

Does anyone think this may be my problem, and or any advice?
Thanks.

[-- Attachment #1.2: Type: text/html, Size: 3310 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Dave Chinner]

On Fri, Jul 01, 2016 at 06:23:21PM +0000, Anthony l wrote:
> But I do have an observation. I had a tape (not made on the irix
> system) and I was able to pull a direct transfer of files with the
> dd command. i.e dd if=/dev/nst0 of=./somefile1 ibs =64k
> 
> And I would only have to do this 3 -4 times to get like 30+ GBs of
> data off the tapes and a simple tar xvf command extracted these
> files just fine. But my question is how come when I try to do
> these with the tapes made on the Irix machine I only get about 200
> mb at a time and there are like 190+ files on each tape. Is this
> normal for an xfs file system on a tape drive?

>From the xfsrestore man page:

Media Errors

       xfsdump  is  tolerant of media errors, but cannot do error
       correction.  If a media error occurs in the body of a media
       file, the filesystem file represented at that point is lost.
       The bad portion of the media is skipped, and the restoration
       resumes at the next filesystem file after the bad portion of
       the media.

       If a media error occurs in the beginning of the media file,
       the entire media file is lost.  For this reason, large dumps
       are broken into a number of reasonably sized media files.
       The restore resumes with the next media file.


The error you are seeing is with the last media file in the dump
which, IIRC, contains critical inventory information and so restore
cannot continue without that media file. You need to work out why
that last media file is returning a short read, once once you solve
that problem xfsrestore should work correctly.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Question: Old Irix tape backup. Recovery on Linux (xfsdump/xfsrestore)

[Roger Willcocks]

On Mon, 2016-07-04 at 10:15 +1000, Dave Chinner wrote:

> The error you are seeing is with the last media file in the dump
> which, IIRC, contains critical inventory information and so restore
> cannot continue without that media file. You need to work out why
> that last media file is returning a short read, once once you solve
> that problem xfsrestore should work correctly.
> 

I think every media file is returning a short read; looking at
http://pastebin.com/UW9zRAZ0 this pattern repeats:

xfsrestore: drive op: end read
xfsrestore: drive op: begin read
xfsrestore: tape op: get status
xfsrestore: tape status = wprot onl
xfsrestore: tape op: forward space file 1
xfsrestore: tape op: get status
xfsrestore: tape status = fmk wprot onl
xfsrestore: tape op: reading 245760 bytes
xfsrestore: tape op read of 245760 bytes short: nread == 4096

i.e. it skips to the next filemark and the first read is short. 

Ah...

https://wiki.zmanda.com/index.php/Installation/OS_Specific_Notes/Installing_Amanda_on_IRIX

"When setting the tape device name in either amanda.conf or one of the
changer configuration files, make sure you specify the "variable" device
name, which has a 'v' on the end. If not, IRIX will write 4KByte blocks
instead of the 32KByte blocks AMANDA tells it to. This apparantly works
OK unless you take the tape to a non-IRIX system, where amrestore will
complain about a short (4096) read."

The page goes on to suggest using dd to skip the first eight 4k blocks,
but that doesn't seem right to me (since the first blocks evidently
contain sensible data.)

So on the face of it this is a tape with fixed length blocks, in which
case 

# mt -f /dev/<name> setblk 4096

might do the trick. (Also use '-m -b 4096' with xfsrestore.)

--
Roger





_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs