Re: Is archiving to file safe ?
In article <483dhd$mbg@dub-news-svc-5.compuserve.com>, 100621.1654@compuserve.com (Bertrand Botineau) wrote: >Hi, > >In order to do archives faster than on tape, I did some experiments to set the >archive device to a file in the tbconfig file (Config is HP/UX 9, Informix >5.01 to 5.03). This appears to work correctly, provided you create the file >before by "touch"ing it; the restore is ok too. My questions are the >following: > >1. is this a safe method in a production environnement ? > >2. has anybody used the same trick with the log archiving ? > >Thank you in advance > >Bertrand Botineau, DBA, DHL France, 100621.1654@compuserve.com My company is archiving to tape but logging to disk. We do this in order to create multiple copies of the log files. If you have a bad archive but good logs, you can go back forever to recover, if you have enough time. We run a 'lights out' Time and attendance system using crons on a distributed system (8 HP9000 nodes and 1 master) serviceing 2500 users. Twice a day, we do an archive (level 0) to tape. The rest of the time, we log to disk and regularly copy the files between the 'nodes' during the day for duplication. (We have little network traffic on the HP ethernet backbone.) We also fbackup the logs to tape daily after the archive, creating two tapes. We have experienced the following problems: 1. Disk space fills up on logs and log backup stops, eventually resulting in loss of database access. A cron monitors this and notifies us if there is no tbtape -c or tbtape -s jobs running. 2. We have the maximum log size set o 200MB. If the log becomes larger than this, the tbtape shuts down. 3. Because the archive also is initiated via a cron, a bad tape also results in the above condition. We run a script to start logging that serializes the log disk file. This allows us to stop/start logging remotely without having to change tapes. I have had some nasty experiences depending on tape backups, so I am wary of any archive/recover process which has any single point of failures. John Callaway, johnyc@mainelink.net