Best practices always have you backing up your system standalone,
that is booted from an out of band boot volume. At a minimum you
generally want a quiescent filesystem or set of files.
Agreed. But if you are already cloning your system before/after
updates and keeping your files and other dynamic data on a non-boot
volume like a good admin does, to back up the mail server you don't
really need to back up the OS.
The backup of the OS and other files -- assuming we're looking for a
best practice -- also should be done standalone so that *no* files on
the target are open for read or write and the file system is
completely quiet, though as you point out since these files change
less frequently than your mail so their backup doesn't have to occur
as frequently. Knowing what to backup and when is all part of your
backup practices and strategy.
Of course bringing the system down, or even subsystems like mail
isn't always practical. Dilgent use of backup mail servers can permit
each to be backed up offline in a practical manner where you don't
have them all offline at the same time.
Technically you shouldn't loose and mail from your mail server being
down, as any sending MTA should try to queue the message if the
target mail server is down, but some mail may be sent directly w/o a
spooler. Direct output of jobs is often the most common of these,
scripts that try and connect directly to drop off their output and
don't have a way to spool the mail. Of course one could argue that
this is a bad practice and the output should be sent to an MTA (and
you'd be right.)
In this case out of band is shutting down the mail system.
Out of band usually means bringing down the system to boot whatever
stand alone backup systems you use to backup the system, that is out
of band of the normal system operations. In the poster's case of
Retrospect this could be booting from the CD. In the case of just
backing up the mail system out of band that could be just stopping it
so that it wasn't active, as you point out. Most Retrospect backups
cover more than just the mail files though.
In reality this is generally not necessary, but will likely
generate comparison errors as the mail system continues to
deliver/remove mail while the backup proceeds.
It's never a necessity until a piece of mail comes in halfway
through your backup and Berkeley DB throws a rod on a messed up db
log file and you have to rebuild the whole thing from scratch.
You'll still have all of your mail files, well perhaps all minus a
few, just no valid bdb indexes. Of course this will only happen when
you need the backup, and not the time you were testing it.
Hopefully any issues like this do come out in testing your backup
strategy, and if not you should try to force them in your test. It's
not a necessity to have the mail database to effectively recover, as
it can be trivially rebuilt. In the event of a system failure you're
likely to be recovering files out of band of the previous backup
direct from the failing disk, so you're likely going to need to
rebuild the database anyway.
While you can get away with this sometimes, if you have any sort of
load on your mail server, I would highly suggest you don't do a hot
backup if you care to have your backup be usable without manually
recovering from it.
I was just pointing out that it' not a *requirement*, and that you
can get away with it. A good backup package should not be reading
write locked records/files, and the mail system should be locking
those files its writing. In some cases it may mean the the file gets
deferred for backup, or not backed up at all. I haven't found the
postfix/cyrus combo to be very atomic. In the case of the Cyrus' mail
databases, best practices should have you checking them as part of
recovery operations and rebuilding them when necessary.
Perosnally I dislike Cyrus and don't trust the database any farther
than I can throw it on a tape. It's the sore point with Cyrus as
opposed to MDAs that just use static files and nothing to get out of
sync with itself. The trade off here is that Cyrus's database permits
quick IMAP operations.
Since mail.app no longer throws up a modal dialog box when a
POP/IMAP server goes down, the five minutes that your server is down
at 3 am will not be noticed by anyone. Plus all good mail admins
have backup MX's set up, so no loss in incoming mail either.
And mail should be quiet enough during your backup window that you
don't have a significant load.
If you want to shut down the mail services during the backup for
due diligence add a pre- and post- script to the backup that issues
`serveradmin stop mail` and `serveradmin start mail` respectively.
Which the script does.
Yes it does, but if you just wanted Retrospect or some other backup
package to do the backup you'll want these steps. In many cases the
mail directories are sizable, arbitrarily duplicating them is
unnecessary if you have a more comprehensive backup system in place.
This isn't so much a real backup as a clone of the files to some
other directory. It's not backing up anything more than the mail
subsystem files themselves, but does start and stop the mail
services
Agreed, the script allows you to stage your mail db backup to
another drive/folder, and then let your favorite backup tool work on
the stage at it's leisure. This way Retrospect doesn't have to know
squat about what a mail server is.
Then Retrospect or another package should then be told to exclude the
real files. Otherwise you could get a lot of file comparison errors
unnecessarily, assuming you do such checking.
I was more trying to point out that just copying them to another
local location wasn't itself a good backup practice unto itself. What
I didn't mean was to sully the good job of your useful script.
--
-dhan
------------------------------------------------------------------------
Dan Shoop email@hidden
Consulting Internet Architect email@hidden
AIM: iWiring http://www.iwiring.net/
Skype: danshoop http://www.ustsvs.com/
iWiring designs and supports Internet systems and networks based on
Mac OS X, unix, and Open Source application technologies and offers
24x7, guaranteed support to registered clients, at affordable rates.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
