Re: restore failing from nfs ontape file

You really should try using -9 on your gzip

However to restore

gunzip -c file1.gz | ontape -r
or
zcat file1.gz | ontape -r
or
gzip -dc file1.gz | ontape -r

As LarryW said elswhere TIMTOWTDI

--
Clive

Floyd Wellershaus wrote:
> do you know what option I would use for the restore side, using gzip ?
>
> My backup is
> ontape -s -L 0 | gzip > file1.gz
>
> So would my restore be use gunzip and thus be
>
> gunzip file1.gz | ontape -r ?
>
> Thanks !
>
>
> ----- Original Message -----
> From: "Floyd Wellershaus"
> Sent: Thu, November 6, 2008 9:35
> Subject: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 -----
>
> _______________________________________________
> Informix-list mailing list
> Informix-list-at-iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
> ----- End of original message -----
>
>
>