Re: restore failing from nfs ontape file

This is a discussion on Re: restore failing from nfs ontape file within the informix forums in Other Databases category; 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 ...

Go Back   Database Forum > Other Databases > informix

Database Forums

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #1  
Old 11-06-2008, 10:07 AM
Default 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 -----
>
>
>


Reply With Quote
Reply


Thread Tools
Display Modes



All times are GMT -4. The time now is 10:28 PM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Integrated by bbpixel2009 :: jvbPlugin R1013.368.1

Search Engine Friendly URLs by vBSEO 3.1.0
vB Ad Management by =RedTyger=
In an effort to better serve ads to our visitors, cookies are used on Mydatabasesupport.com. For more information, check out our Privacy Policy.