RE: Archive and restore by named pipe
Aaaargh! Please contact the IIUG and ask them to sort
this out, I shouldn't be getting these emails, but I'm
getting one every few minutes.
Dom
--- "Lofstrand, Bob" <lofstrr@hastings-ent.com> wrote:
> We had the same problem when we moved to 7 engine on
> our sco boxes. Our
> archives write to a compressed file via named pipe
> just fine, but will not
> restore the same way is they did under 5. Our
> solution is to decompress the
> archive to a spare tape, (we are using the tape for
> file system backups and
> swapping out at night to do an archive as well is
> not practical.) then
> recover from that tape. This is a bit inelegant, but
> it does work and
> needing to recover from archive is quite rare.
> > ----------------------
> > Robert K. Lofstrand 806.351.2300 x3650
> > Informix Database Specialist
> lofstrr@hastings-ent.com
> > Hastings Entertainment Inc.
> http://www.gohastings.com
> >
> >
> > -----Original Message-----
> > From: David Kosenko [SMTP:dkosenko@home.com]
> > Sent: Sunday, January 09, 2000 3:55 PM
> > To: informix-list@iiug.org
> > Subject: Re: Archive and restore by named pipe
> >
> > The problem is in the way that ontape reads the
> backup media. It first
> > reads
> > the header off the media, then closes the file
> descriptor, expecting the
> > media
> > to "rewind" (this is why you cannot usually use
> no-rewind devices with
> > ontape).
> > It then rereads it from the beginning for the
> physical restore. Because
> > your
> > pipe cannot be "rewound", after it closes the fd
> and reopens it, it reads
> > data
> > that is not (now) a valid header, so the restore
> fails.
> >
> > Theoretically, if you could send two copies of the
> header to the pipe
> > during the
> > restore, it should work. Offhand, I don't know
> how long the header is.
> > You
> > could probably do a dd & od and figure out how
> many bytes make up the
> > header and
> > then put a kludge in your script to send the
> header twice.
> >
> > Dave
> >
> > Also sprach Juerg Schaer <jsc@imtf.ch> :
> >
> > :Hello
> > :
> > :I'm looking for a solution to avoid the use of a
> tape drive for
> > :archiving Informix by ontape.
> > :I have tested, that only archives less than 2GB
> can be used without
> > :problems, but my archive is about 3 GB and it's
> growing.
> > :I have tested the way by using a named pipe as a
> TAPEDEV.
> > :
> > :Tape section of onconfig.
> > :TAPEDEV /tmp/ontape.nmp # Tape
> device path
> > :TAPEBLK 1024 # Tape block size
> (Kbytes)
> > :TAPESIZE 4096000
> > :
> > :my archive script:
> > :#!/bin/ksh
> > :PIPE=/tmp/ontape.nmp
> > :FN=/dbms/informix/ontape.`date +"%Y%m%d"`
> > :MAXSIZE=500m
> > :export MAXSIZE PIPE FN
> > :
> > :rm $PIPE
> > :mknod $PIPE p
> > :
> > :( /usr/local/bin/gzip < $PIPE ) | split -b
> $MAXSIZE - $FN. &
> > :
> > :echo "\\ny" | ontape -s -L 0 >> /tmp/nmpbkup.log
> > :# end of archive script
> > :
> > :my restore script:
> > :#!/bin/ksh
> > :PIPE=/tmp/ontape.nmp
> > :FN=/dbms/informix/ontape.`date +"%Y%m%d"`
> > :export PIPE FN
> > :
> > :cat `echo $FN.* | sort` | /usr/local/bin/gunzip >
> $PIPE &
> > :echo "\\ny\\nn\\nn\\n" | ontape -r
> > :# end of restore script
> > :
> > :But always the physical restore failed by
> restoring from named pipe !!!
> > :The archive seems to be OK.
> > :By unzipping instead of $PIPE into a file, the
> restore is OK.
> > :It seems to be a problem with TAPEBLK ...
> > :
> > :I am using Informix Dynamic Server Version
> 7.30.UC8 for AIX 4.2.1
> > :
> > :Can anybody help me ?
> > :
> > :
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com