On Wed, Jan 24, 2007, Anne <[EMAIL PROTECTED]> said: > In one of the responses to a bug I reported, I was told this: > "As an aside, if you have customers, you owe it to them to have a backup > server."
Sorry for being a snipey there -- I just woke up this morning (California time) and saw way too many emails of the 'urgent fix needed!!' variety :-| For my personal email, I have a big Postfix queueing area. I "eat my own dog food" with DBMail, and I update to the dbmail_2_2_branch SVN every 2-3 weeks. Things rarely go wrong, but when they do, I shut down DBMail but leave Postfix running. It queues up email while I fix whatever bug was there. At this point I'm treading in dark water, because firing up DBMail with a bum fix could result in mis-inserted or lost mail. It's the risk I take eating the dog food, I guess. Here's another idea: have Postfix write email out to a standard spool, which is blown away every time a backup is completed. Between yesterday's backup and today's spool file, you haven't lost anything if the active database becomes corrupted. Some additional procedures would have to be in place in the event of a bum backup. > Our dbmail database is backed up every night. Last night something went > wrong with the data in the database. This happened before the backup was > started so the backup became useless. A crucial question with backups is "What is my cost per minute/hour/day of lost data?" once you know the cost, you can calculate the price you are willing to pay for your backup solution. One neat approach is to have a hot mirror on a backup server. When your backup window begins, you stop the mirroring, make the backup, then start the mirror again. MySQL's binary logs will have queued the changes and will bring the mirror up to date pretty quickly. With this approach you never impact performance of the user-facing servers during your backup window, and you might be able to do more frequent backups as a result. The cost is an entire parallel server, which may or may not outweigh the cost of an entire day's lost data. > If I would have some fancy mirroring solution it would have replicated the > problem. So that wouldn't have helped. I've seen some *very* nasty errors reproduced with hot mirrors. They are great for online failover, and for the backup server solution above, but terrible for backups in and of themselves. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
