Re: backup and archive

In Article<09970105221619.OUI28.curtis@pencom.com>, <curtis@pencom.com> writes: > Path: news1.neo.lrun.com!news-out.internetmci.com!newsfeed.internetmci.com!dciteleport.com!europa.clark.net!news.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.sprintlink.net!news-peer.sprintlink.net!kirin.wwa.com!not-for-mail > From: curtis@pencom.com (Curtis Preston) > Newsgroups: comp.databases.informix > Subject: Re: backup and archive > Date: 6 Feb 1997 06:35:24 GMT > Organization: Pencom Systems Incorporated > Lines: 79 > Message-ID: <09970105221619.OUI28.curtis@pencom.com> > References: <32DD43D0.134C@hotmail.com> <09970020192048.OUI81.curtis@pencom.com> <32F219CB.7446@transre.com> > Reply-To: curtis@pencom.com > NNTP-Posting-Host: pool12-025.wwa.com > X-Newsreader: OUI PRO 1.5.0.2 > > 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? > If you are worried about a disk going bad that you are writting your logs to you can go one step further. What we do an addition to writing to disk is a remote copy to another server. The server is on the same local network so the transfer is fast. A script copies the disk log to a dated file and then does a remote copy to another server for a backup copy.