Sorry, but there is a bit to much FUD in here for my taste. I do know this
is not the place for flame wars, but I would never ever hire a person who
has these views to be anywhere near an exchange server.
To me, this post shows a lack of understanding on how exchange works, and
more so when it comes to the point on how to handle a corrupt server.
- Databases can be corrupt but still *seem* to work
True, so can a multi million dollar Oracle system.
Part of your daily maintenance is to check this. Plenty of tools available
for that, including all the major backup tools.
>- Databases are used for several users at the same time
Well, of cource you have several mailboxes in a storage group.
>- Repairs often require databases stores to be dis-mounted
Only if you have severe corruption, which you would avoid by actually taking
care of your data.
>- Corrupt databases will often stop information stores mounting
Yes, by design. Would you mound a corrupted file system without checking it
first?
>- Backup agents often do not work as advertised and can be risky
Well, Backup Exec, ARCServe and NT-backup work just as advertised, as long
as you understand the difference between a "mail-store backup" and a
"mail-box backup"
>- Flat-file backups of a dismounted store are the most reliable
I would like to disagree there, since you do NOT HAVE a consistant log state
in such a backup.
Online backups with log-trunking is the most reliable backup.
>Offline Backup and Restoration Procedures for Exchange
>http://support.microsoft.com/kb/296788/
Lets read the first few paragraphs in that article.
" This article describes methods you can use to bypass the online backup
application programming interfaces (APIs) and manually back up and restore
Exchange information store databases."
WHY would you want to bypass the built in routines?
>Corrupt information stores are your worst nightmare
Yes, that is true. (Do NOT let the log-space of a Pre-2000 exchange server
run out.. let me tell you that)
>- Your information store could have been corrupt for weeks before
>crashing
Uhm, only if you have not backed up the database in that time. Let's
reiterate: ALL the major backup tools _will_ do a complete consistency check
when you back up. If the store is corrupt, you _will_ be told. IF you find a
corrupt tool, you have the choice of trying a soft recovery on a per item
basis. You can do a somewhat nastier thing and to a hard recovery and just
trash whatever was in that object. Or you can to a log replay and do a point
in time recovery... pretty much the same choices as on a
multi-million-dollar-Oracle cluster.
>(your backups could be corrupt too)
Yeah, if you rely on flat file offline backups, you bypass all the checking.
>- Information stores are tied to custom Active Directory attributes
No, you can run exchange without an AD, but you would loose the point of it.
>- Information stores are tied to individual servers
Yes, you have to store the mail of a user somewhere, that is correct.
>- All of this has to be correct for stores to mount
Where is the problem?
>- Just copying databases back will not always work
See above, if you rely on offline backups you _will_ run a greater risk of
corrupting your store, since you bypass the checks.
>- A "consistency adjuster" may need to be used to "mask" big problems
A what-now? There are a few tools that let you repair and diagnose the
store, but in what way do they "mask" the problem`?
>- If your Exchange server "crashed" and cannot be started again to
> properly "remove" it from active directory,
One words: ADSIedit. Beautiful tool to manipulate AD. I've used it plenty
when it comes to doing swing-migrations of SBS-sites.
>you may not be able to add a
>new exchange organization cleanly and may have to START AGAIN with a NEW
>active directory (THIS IS COMPLETELY TRUE - THE MS ARTICLES ON THE
>SUBJECT DO NOT WORK IN SOME INSTANCES)
Such as what instances?
>For more information see:
>How to recover the information store on Exchange 2000 Server or Exchange
>Server 2003 in a single site
>http://support.microsoft.com/kb/313184/
IF you end up having to use that article, the admin has been a clutz to let
the server get to a state where that method is required.
>If you do decide to use Exchange (which I strongly advise against)
>
>- Do not rely on live backups
See above. Do NOT rely on _offline_ backups!
>- Use flat-file backups of databases by scheduling a job to dismont the
>message stores and copy files to another disk, drive or server
See above: You do NOT have a consistant log state when doing that.
>- If your exchange server is also a domain controller everything gets 3
>times harder. Do not run exchange as a DC or GC, PDC or infrastructure
>master.
Why three times harder? It makes no difference what so ever.
>- Note: You can't help running exchange as a DC, GC, PDC and
>infrastructure master in Small Business versions of exchange or single
>server sites.
Wrong. You can add several DC's to a Small Business Domain. The SBS has to
be the first installed server however, but that is by design.
