November 4th, 2003, 02:15 PM
Exchange Server Precautionary Measures/Recovery Procedures
This doesn't quite fit the tutorial section, and this is just a quick check before restoring an MS Exchange server....and is by no means a complete guide, just quick tips.
Precautionary Measures on an MS Exchange Server-
-On any M$ (not only Exchange servers) server, make sure that you have your OS mirrored via the actual RAID controller (allow about 8 gigs for the OS depending upon the amount of data or usage housed on the server)
-IN MY OPINION It is always good practice to have your data structure, especially a corporate email server on a RAID5 (depends on size of server etc. for all cases, this is based on a medium - large server), and this would not be through the OS (since that would become OS dependent, and if the OS fails, your RAID is screwed). Keep the RAID5 through your RAID controller. (what I like to call a hardware RAID)
-Keep your RAID5 containers in tiptop condition! If you ever notice that your containers are in critical condition, run your RAID controller's setup program (most controllers have a setup program at boot-time that allows you to scrub/synch bad drives on the RAID.)
-Always keep good tape backups of your server, this is almost a universal rule for every net admin. Although we may not feel like labeling, or putting our tapes in a safe place sometimes...DO IT!
-Keep a detailed spreadsheet on any updates done to the server, such as service packs, or program installations, as these could have an adverse effect on running a tape backup. (you'll see why later)
Uhoh! Did you have an Exchange server failure?
-First thing is first, pull your spreadsheet....Check what updates and software installations you've put on the failed exchange server.
-Run to the bank/vault/storage area where your most recent backup tapes are located, and get them ready for usage...
-When rebuilding the server, (and this is where the spreadsheet comes in handy) make sure you rebuild it to the exact specs of the previous server, as in service packs, updates, and software installations. As Exchange sometimes is very picky on tape backups. It tends to like being restored to a similiar state, depending upon your backup method. This will cut down on the inconsistancies that Exchange might have to repair when restoring the databases.
-If all else fails, and your restoring software can't get Exchange to its previous state of operation call Microsoft and pay them to help. (I know that it sounds like the easy way out, but when it comes to your job, don't take any chances) They solve the problem, or you don't pay And when a CEO is a-callin (because you're taking too long) you might go home a-ballin, cuz you lost your job.
-Last but not least, give a realistic time model for restoring the server, it is always good practice to give yourself a time buffer, that way if you're early in the restoring of the server, you can test, and make sure everything is running optimally, and in addition....look good
Hope this helps anyone who has the fluke of an entire Exchange server going down, FOR WHATEVER REASON. This might actually help with any server...I've found this to be a good guideline in the professional world.
Creating further mindless stupidity....through mindless automation.
November 9th, 2003, 12:52 PM
Good advice, particularly on the backup and restore sections for admins of any flavor. By the way, Sun and HP
offer similar assistance and may already be a part of your support contract (if it is one of those 7 figure contracts,
then you have it).
From past experience, I would recommend that you build one of your (test) boxes from a restore everytime a change
in your backup policy/procedure takes place. Trying to rebuild a mission critical machine is the _wrong_ time to find
out that your backup policy/procedure was flawed. But, that's just common sense right?
Get OpenSolaris http://www.opensolaris.org/