Re: restore failing from nfs ontape file

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 thatchunk_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 "<remote_machine>:<remotedevice>". 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@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > > >