Re: backup and archive

In article <09970105221619.OUI28.curtis@pencom.com>, Curtis Preston <curtis@pencom.com> writes >In article <32F219CB.7446@transre.com>, From "Juan R. Guzman" ><jguzman@transre.com>, the following was written: > >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 What happens if cpu dies (I've seen it happen), board fails (happened to a client of ours a few days ago). >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 I've dropped tapes before - QIC 150 tapes generally just bounce so do 9inch reel tapes. >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, You should have a separate tape drive configured and not dump on the log tape drive. Or tapes sometimes get eaten but that is not critical unless the machine dies at the same time. Even then you can still read up to the damaged part of the tape. >but the scenario that you pose has flaws as well. > >What happens when the tape you wrote your logs to dies? You're screwed. Only if the machine dies at the same time and at least I can read the tape up to the point of failure. If the machines dies the filesystem can easily get corrupt and you can lose the middle of one of you log files. Generally fsck does not do a good job of repairing filesystems. You get the filesystem clean again but usually lose some data. > 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. Why have the extra step - it just means the logs are on disk for longer. >* Performance goes WAY up, on the writing of the logs, and the >reading of them during a restore when you need to. Writing - get a faster tape drive, I can write a 500Mb ARCHIVE to a DAT drive in 1/2 hour. If you that large a transaction volume you system must be corresponding large and the cost of the fast DAT drive will be minimal compared to the rest of the hardware. >* 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.) And hit the same problem when you run out of disk space. >* 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 And how do they recover if the machine loses power and filesystems containing logs AND the database get corrupted? I'd rather have my data safe on tape. >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. Power failure....UPS failure (seen it). >* 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. Surely a days logs can fit on 1 tape? What happens when 1 file of logs on disk needs to be recovered? What happens if the earliest log you need is not on disk (Backup files of logs on disk to make space...where did I put a spare tape????....Find required file....you do cataolgue them with logical log numbers don't you?...restore logs ....extract newest files of logs from tape....restore them... Or even start restore from tape...find a file got deleted before being backed up and you're stuck. Me I just put the tape in and restore. >* It makes the WHOLE THING easier to manage, which means that your So you like cataloging which files contain which logical logs and on which tapes they are? > backups gain a higher level of reliability. When you've got 50 or See above. >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. See above about cataloging tapes/files. It has to go to tape eventually anyway why not let online catalog the tapes for you and also not have to catalog files. Operators can change over the logical log tapes and backup tapes at the same time. > >-- >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? > -- David Williams