Re: backup and archive

Any chance of seeing you script? Regards Silvester Valiente Informix/Ingres DBA TNT Australia Ltd (02) 9319 8545 curtis@pencom.com (Curtis Preston) wrote: >In article <32F219CB.7446@transre.com>, From "Juan R. Guzman" ><jguzman@transre.com>, the following was written: >>> >>> Curtis Preston writes: >>> >>> I know that OFFICIALLY Informix does not support it, but have you >>> ever thought of sending your archive logs to disk? It solves all the >>> problems that you're having. I've been doing it for years with >>> hundreds of production 24x7 Informix databases. I have also >>> recovered many of them, and there is no problem sending the archive >>> logs to disk. >>> >>> I even have a script that stops and restarts the logs, moving and >>> compressing the old files, every day. It also automatically starts >>> the archive logs upon bootup. Interested? It really doesn't take up > >> that much disk. >> I think that's risky. What happens if that disk goes. You've lost >> the logical logs upto that point. Let's hope one of your informix >> disks don't go until your next archive is completed. I know losing >> two disks is very unlikely, but I don't what to be the one telling >> management that we lost a corporation's day worth of work, no matter >> what the reason. This maybe a worst case scenario but that's what you >> always have to look at when your planning, in case you ever have to >> face it.> . >Wow, someone actually more paranoid than me. Cool! I agree, and >backups are a risky business. First, however, let's put things into >perspective. In all my days of backing up 100's of servers and millions >of gigabytes of data, I have NEVER lost more than one disk on the same >system at once unless they were on the same controller. I HAVE however >had many tape drives eat tapes that I depended on. Which is more likely >to happen? The disk that you depend on for your logs goes when your >database disk goes, or the tape you need gets dropped on the way to the >drive, and the door shatters open and the tape becomes useless (or >something else bad happens to your tape, like spilling on it in panic >mode, or getting eaten in a drive.) The point is that you are correct, >but the scenario that you pose has flaws as well. >What happens when the tape you wrote your logs to dies? You're screwed. > Just as I am screwed if my disk dies before I get it to tape. Here's >the differences: >* I can, if I'm really paranoid, run the script I use every hour. >This would close the log, compress it, and reopen a new log. This >old log can now be copied to another disk or tape. I can do with >it what I want. You can still have a tape mounted and copy the >data to it if you want that extra safeguard. >* Performance goes WAY up, on the writing of the logs, and the >reading of them during a restore when you need to. >* Informix does not let you know that you are almost out of tape. In > fact, it has no way to know. So basicly, you've been writing to >this tape all day or weekend, and it fills up. Your logs now stay >in the buffer and aren't being written anywhere until you notice >that your database freezes because your log buffers are all full. >Been there. HOWEVER, if you were sending them to disk, you could >monitor the file system and do something proactive when it gets >close to full. (Delete older logs, etc.) >* This is exactly the way Oracle and Sybase do their transaction >logs. Informix is the only one I know that wants to go right to >tape. As long as you are not sending them to the same disk, or even >a disk on the same controller your risk is almost nill. >* Restoring from logs on disk is SO much easier. No more swapping > tapes. You can do it all sitting at your desk. And it is MUCH >faster than reading from tape. >* It makes the WHOLE THING easier to manage, which means that your > backups gain a higher level of reliability. When you've got 50 or >60 instances writing logs directly to 50 or 60 tape drives, that is >an unmanageable mess with you running around swapping tapes all the > time. Going to disk makes it very automatic, and automatic is >ALWAYS better than manual anytime. >-- >I am currently writing a book for O'Reilly Publishing about enterprise >backup and recovery, and would really appreciate hearing anything >you would like to ask me or tell me. If you have problems with >something, then others will as well. Can you think of anything >else that should go in such a book?