Re: backup and archive
Posted in 1997
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?