Re: restore failing from nfs ontape file

Ok.
btw, I got a file to large for STDIO error on my backup.
Any ideas how to overcome that one ?





----- Original Message -----
From: "Clive Eisen"
Sent: Thu, November 6, 2008 9:46
Subject: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 -----
>
>
>




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

Hello Floyd,

Your errors baffle me. Is everything 64-bit (Informix, O.S., NAS,
etc)? Clive's answers are great and I'm going to save them in my bag
of tricks.

There are various ways to backup: Snap, ontape, onbar, cp, dd, etc.
Where I work we have a 1Tb system also. It is cooked on SAN and we
back it up to NAS. To oversimplify we first run "UNLOAD TO chunk_list
SELECT * from syschunks" and then run the cold backup against that
chunk_list. The pseudo code for this is: "compress -c SAN > NAS". We
would have used gzip but it had a 2Gb limit long ago when we wrote the
script. And we do all those compresses in parallel to speed it up.
If your disks are RAW then maybe a "dd" version of all this will work.

-L.S.

I really hope that you have no update activity in the database or using
"onmode -c block" while your process is running otherwise your backup is
going to be useless.

Just to clarify some things that were discussed over this thread:

1. The message "Read/Write End Of Medium enabled: blocks = 474623" is an
expected message when you are using TAPESIZE set to zero. It is an
informative message that is telling you how many TAPEBLK size blocks
were written to the medium.

2. Floyd, You do not mention what type of NFS are you using (NFS to
another machine or to a NAS?). IN any case I think NFS is not the best
backup medium with ontape simply because the performance usually suffers
and sometimes network problems make it an unreliable medium.

3. If you need to use a device in a remote machine, the safest and
faster way to do so is using remote devices, that is, setting TAPEDEV to
":".

4. If compression is a need (Which it should be if you are transferng 1
TB through the network) you should take a look at the FILTER feature in
11.50 that allows you to use an external program to compress/encrypt a
backup.

5. If restore speed is important, you should also consider moving to
onbar and split your database in multiple dbspaces so the backup and
restore can run in parallel.

6. The error message you are seeing during restore indicates that either
the backup is corrupt or NFS is generating an error at reading time. To
try to diagnose this you could try to run the restore locally? also you
could try to run archecker. The best you could do is open a case with
Technical Support to diagnose this issue.

best regards.

Gustavo Castro

LIGHT SCANS wrote:
> Hello Floyd,
>
> Your errors baffle me. Is everything 64-bit (Informix, O.S., NAS,
> etc)? Clive's answers are great and I'm going to save them in my bag
> of tricks.
>
> There are various ways to backup: Snap, ontape, onbar, cp, dd, etc.
> Where I work we have a 1Tb system also. It is cooked on SAN and we
> back it up to NAS. To oversimplify we first run "UNLOAD TO chunk_list
> SELECT * from syschunks" and then run the cold backup against that
> chunk_list. The pseudo code for this is: "compress -c SAN > NAS". We
> would have used gzip but it had a 2Gb limit long ago when we wrote the
> script. And we do all those compresses in parallel to speed it up.
> If your disks are RAW then maybe a "dd" version of all this will work.
>
> -L.S.
> _______________________________________________
> Informix-list mailing list
> Informix-list-at-iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
>