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

Good news - I succeeded and kept it relatively simple. The biggest clue was Art's naysaying reply: >You cannot recover from a pipe. Ontape opens the 'tape' file, >reads the reserved pages, performs some calculations, closes the >'tape' file, and reopens expecting that the tape has rewound. I didn't realize it until I tried understanding Andy's script. (I still don't but that should not be a problem now.) What I needed to do was simulate the tape rewind so it reads the same data again. That can be done by a feeding a short dd to the pipe, followed by the complete dd. The piped archive was taken with TAPEBLK = 256K, although my experimentation had found that 128K gets the backup done the fastest. OK, oversight.. Here's the recovery step: (1) In window #2 I typed, but did not enter, this command: $ dd if=/inf_archive/archives/archive.L0 \\ of=/apps/informix/arc_pipe \\ bs=262144 count=2That is, a dd command to read from the huge archive file, write back to the pipe file using the same block size with the "tape" had been written, but only send two blocks. That count took some experimentation because I did not know how many TAPEBLK-size tape blocks ontape would try to read before it thinks it is has enough information about the archive. (2) In Window #1, I entered the command: $ ontape -rA few seconds later is asks me to mount a tape on /apps/informix/arc_pipe and press RETURN to continue. (3) Switch back to window # 2; press RETURN to start the dd command (4) Back to W#1 and press enter. ontape will present some information, ending with a complete onstat -d extracted from the "tape" and ask me "Do you want to restore this? (y/n) " (OK, I don't recall the exact text of the prompt!) I answer y. It also asks me if I ant to back up logs. In my case, where we don't run log backups (because we have nightly backups anyway) my answer will be no. But I didn't press enter yet.. (5) In W#2, the dd has finished and displays the number of records in and out. In our case this is 2. Note - if this dd does not complete as described, this whole exercise will fail. Repeat the same dd command but this time omit the count=2 parameter. (KSH users have it easy - just <esc>k and edit the command.) And this time, press the return. Gotta start filling the pipe before ontape starts to read it. (6) In W#1, press the enter to that logs question. Recap: - In W#1 you have the ontape -r running in foreground - In W#2 you have the dd running in foreground If you have a tail -f running against the online.log file, you will see the beginning recovery message. If it's a big database, leave the terminal windows open and go home. (7) By morning, you should see that W#1 has a new prompt: Do you have a Level-1 archive to recover? (y/n) In my case, I answer no - I didn't want to deal with that added complication. It then asks: Do you have logs to recover? (y/n) Again, I answered N. (8) Program over. Informix enters Fast Recovery state. If all were well with my system, it would soon finish the Fast Recovery and enter quiescent mode. However, I have observed two bad tendencies on this system when recovering using OmniBack (our usual backup software): - Sometimes it get stuck in state "Fast Recovery (CKPT REQ)" - Sometimes it seems to freeze up after "Logical recovery started" In my case, it got stuck in "Fast Recovery (CKPT REQ)" state. The prescribed solution to this was to run onmode -m as if it were in quiescent mode. This worked for me on my test system is back on line. If that fails, you're probably stuck in Logical Recovery and there is an undocumented onmode -n to pull you out of that. (Remember, there is a usually reason it was undocumented!) Only after I was back on line did I realize that the dd command feeding the pipe in w#2 had not completed. I killed it with CTRL-C and I am currently running a complete battery of oncheck scans to see if anything is missing. I split the procedure into those 8 steps in a certain-to-fail attempt to make it idiot-proofed. But then, an idiot should not attempt this anyway. (I am *not* an idiot. A nut? Probably. But not an idiot!) Thanks for the suggestions and especially for telling me it can't be done! +------------------------------------------------- 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. | +-----------------------------------------------------------------+ I, JSalomon@bn.com (Jacob Salomon) wrote in message news:<38b6a68e.0410131249.5df024a4@posting.google.com>... > 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