Re: restore failing from nfs ontape file

Well your other command seems to work also, for doing the actual ontape -s



----- Original Message -----
From: "Clive Eisen"
Sent: Thu, November 6, 2008 9:28
Subject:Re: restore failing from nfs ontape file


Sorry - I should have said for restore

bzcat /s01/informix/backup/level0.bz2 | ontape -r

or whatever

--
Clive

Clive Eisen wrote:
> In the onconfig set
> TAPEDEV STDIO
>
> Then do
> something like
>
> /opt/informix/bin/ontape -s -L 0 |/usr/bin/bzip2 -9 >
> /s01/informix/backup/level0.bz2
>
>
> Floyd Wellershaus wrote:
>
>> Thanks.
>> I am unfamiliar with how to make an ontape go to stdio.
>> Can you give me a hint ?
>> All I know with ontape is that it uses the TAPE parameter value in
onconfig.
>>
>> would it be like 'ontape -s -L 0 | filename.gz' ??
>>
>>
>> ----- Original Message -----
>> From: "Clive Eisen"
>> Sent: Thu, November 6, 2008 9:07
>> Subject:Re: restore failing from nfs ontape file
>>
>>
>> If it was 1T written then I doubt it's ulimit
>>
>> I would say that THINKING is too strong for my suggestion ;-)
>>
>> I just remember that restoring ontape over NFS has been problematic in
>> my dim and distant past.
>> If you are limited by the write performance of your NFS you may want to
>> look at using STDIO
>> anyway and gziping/bzip2 the image on the fly before the write to the
>> nfs mount . It could well reduce your backup time.
>>
>> FYI my bzippped backup is 4.6G - unzipped it's it >33G
>>
>> --
>> Clive
>>
>>
>> Floyd Wellershaus wrote:
>>
>>
>>> So you're thinking the problem isn't with the backup file being corrupted
>>> by going over nfs or for another reason, instead you think the problem is
>>> on the other side.
>>>
>>> I should have told you that the actual filesystem exists on the target
>>> server.
>>>
>>> A wild guess I had, is that the OS ulimit limitation may have
something to
>>> do with why the backup file is bad and I get that extra verbage at the
end
>>> of the ontape :
>>> *Read/Write End Of Medium enabled: blocks = 474623 ***
>>>
>>> So I set the informix ulimit to unlimited, and I'm trying the backup
>>> again, across the nfs. It takes about 5 hours to write out the nearly 1T
>>> file.
>>>
>>> Thanks,
>>> floyd
>>>
>>>
>>> ----- Original Message -----
>>> From: "Clive Eisen"
>>> Sent: Thu, November 6, 2008 8:04
>>> Subject:Re: restore failing from nfs ontape file
>>>
>>>
>>> This is purely from memory, but because of the way ontape
>>> opens-reads-seek0-read on the 'tape' it fails on NFS with the seek0
>>>
>>> Try setting the device to be STDIO
>>> and do
>>> cat /some/file/on/nfs | ontape -r
>>> --
>>> Clive
>>>
>>> Floyd Wellershaus wrote:
>>>
>>>
>>>
>>>> Hi,
>>>> Trying to backup a large database to an nfs filesystem on aix . aix
>>>> 5.3, ids 10.0fc5.
>>>> ontape backup seems to work, although I get a slightly different
>>>> message at the end.
>>>>
>>>> The problem is that when I go to restore the database on the target
>>>> system, it starts to work, presents all the chunks, asks me if I want
>>>> to backup logs etc..., and then after about 10 or 15 minutes fails with:
>>>>
>>>> *Physical restore failed - function write physical restore failed code
>>>> -1 errno 0 *
>>>>
>>>>
>>>> So back to the backup.
>>>>
>>>> Normally I get :
>>>> =====================
>>>> 100 percent done.
>>>>
>>>>
>>>> Please label this tape as number 1 in the arc tape sequence.
>>>> This tape contains the following logical logs:
>>>>
>>>> [some number]
>>>>
>>>> Program over.
>>>> ===============
>>>>
>>>> However, with these backups I am getting:
>>>>
>>>> *=========================
>>>> * ** **
>>>>
>>>> *100 percent done.***
>>>>
>>>> *Read/Write End Of Medium enabled: blocks = 474623 ***
>>>>
>>>> * ***
>>>>
>>>> *Please label this tape as number 1 in the arc tape sequence. ***
>>>>
>>>> *This tape contains the following logical logs:***
>>>>
>>>> * ***
>>>>
>>>> * 177925***
>>>>
>>>> * ***
>>>>
>>>> *Program over.
>>>> ============================
>>>>
>>>> ***
>>>>
>>>> I have both TAPEBLK set to 2048 ( on the target and the source ),
>>>> I have both TAPESIZE set to zero.
>>>>
>>>> Any advice ?
>>>>
>>>> Thanks,
>>>> floyd
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by *OpenProtect* , and is
>>>> believed to be clean.
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Informix-list mailing list
>>>> Informix-list-at-iiug.org
>>>> http://www.iiug.org/mailman/listinfo/informix-list
>>>>
>>>>
>>>>
>>>>
>>> ----- End of original message -----
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ----- End of original message -----
>>
>>
>>
>>
>
> _______________________________________________
> Informix-list mailing list
> Informix-list-at-iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>




----- End of original message -----