Re: (Another) ontape to recover from a FIFO pipe

I wrote back to Andy: >My one big doubt is that the flat file is about 79GB in length and >we all know how Informix (especially my 7.23 clunker) handles files >longer than 2GB. Was your flat archive file similarly humongous? Well, Andy, it looks the doubts I had before were for naught. I didn't get anywhere that far in the restore directly from the file. I changed TAPEDEV to the target file (it was never compressed) and started the ontape: $ ontape -r Please mount tape 1 on /inf_archive/archives/archive.L0 and press Return to continue ... The file is there, of course, so I simply press the Return key. Immediately, it comes back with: Physical restore failed - function open tape device /inf_archive/archives/archive.L0 failed code -1 errno 72 What is error 72? finderr 72 says: -72 Not a stream device. WHADAYAMEAN not a stream device?!! When I was teaching the class we always used flat file for the TAPEDEV and never encountered this error on the restore. Perhaps ontape opens the file and does a service call to obtain infor about the file and the length overflows.. I've seen Tim Brown's suggestion and I may eventually try this tack but I'm still trying to keep it simple Andy? Anyone else? I'm still taking suggestions.. Thanks. +------------------------------------------------- Jacob Salomon -+ |When you exit this vehicle, please be sure to lower your head and| |watch your step. If you fail to do so, please lower your voice | |and watch your language. | +-----------------------------------------------------------------+ Andy France <andyATzespriDOTcom> wrote in message news:<10mra6le3kc9q88@news.supernews.com>... > > I had a similar problem. We backup to a named pipe and gzip the dump > on the other side. For a restore I tried gzcat back to the pipe but > when I ran ontape I just got a broken pipe. > > In the end I uncompressed the dump, and specified the dump file name > in the TAPEDEV parameter in my onconfig file. ontape then did the > restore without any problems. > > HTH, > Andy. > > Jacob Salomon wrote: > > Informix IDS 7.23 (Go ahead and laugh - I agree with you) > > > > Hi Family. > > > > I have been researching ways to archive to a named pipe. I see from > > researching this newsgroup that I am far from the dfirst person to > > try this. By playing with the TAPEBLK size, I came up with 128K as > > an ideal buffer size for backups - it backed up a 140GB system in > > under 2 hours. > > > > The Unix SA created a 200GB "large file" file system while I created > > a FIFO and set TAPEDEV to reference it. I also set the TAPESIZE to a > > billion (K). All set up. > > > > I backed up by starting a DD command to read from the FIFO and write > > to a flat file. The I started the ontape -s -L 0. Like I said above, > > it was done in under 2 hours using the 128K block size. > > > > Now how about recovery? Well, I started the ontape -r in one window. > > $ ontape -r> > Please mount tape 1 on /apps/informix/arc_pipe and press Return to > > continue ... > > > > Before hitting enter, I ran this dd command in another window: > > $ dd if=/inf_archive/archives/archive.L0 \\ > > of=/apps/informix/arc_pipe bs=131072> > > > That is, read back from the flat file I created in the backup (79GB) > > and write it to the FIFO in the same block size with which it was > > created. > > > > On the ontape window, I hit <Return>. ontape displays the dbspaces, > > presents the ontape -d output and asks: > > Continue restore? (y/n) y > > Of course Y silly! > > > > I answer "n" to "Do you want to back up the logs?". > > > > Now it starts to churn away for a few seconds. Then POW: > > > > Physical restore failed - restore reserved pages failed > > Program over. > > > > Bak to the dd side, that program is patiently trying to write to the > > FIFO. I CTRL-C out of it and I get the message: > > 9+0 records in > > 8+0 records out > > > > Hey, if the reserved paged could not restore, the restore should > > have died at the first "record" from dd - at 128K it certainly > > covers the reserved pages and then some! But Noooo! It read 8 > > records of 128K each - a full meg - before deciding it couldn't > > handle the reserved pages. > > > > I cannot possibly be the first fool to stumble into this problem! > > Has anyone else ever had this problem and solved it? Is anyone out > > there successfully archiving and recovering to/from flat files using > > a FIFO pipe file? > > > > Thanks. > > +------------------------------------------------- Jacob Salomon -+