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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
|