Microsoft Exchange poses some challenges to storage management if (and when) its database threatens to outgrow its allocated storage space. You may be faced with a number of thorny problems when it comes to moving the database from one storage system to another, not all of which have obvious solutions.
The single biggest reason why moving Exchange stores are problematic is not just the size of the store; there are other databases that routinely reach dozens of gigabytes all the time, and I've yet to meet anyone who managed storage for a living that was scared of a 70 GB database. It's the fact that moving the database to another device usually means taking all Exchange users offline for the duration of the move. The database has to be unmounted, moved and then remounted -- and during that time, it's wholly inaccessible.
To that end, I've worked out three basic scenarios for moving an Exchange database, with the amount of impact they have on the customer and user base.
1. Planned downtime
If it's not a deal breaker to have Exchange offline for a certain period of time, plan downtime as the least complex way to move Exchange data. The process is not difficult; it just needs to be taken carefully, and it's been well-documented by both Microsoft and other parties. Daniel Petri, for instance, has a step-by-step guide to moving Exchange stores. Again, the only problem is that during the migration, Exchange will be completely unavailable, so this is generally only an option if there's a window of time available to do it in and no one will mind.
2. New Exchange instance
This works if you're planning to migrate not only Exchange's data but the Exchange server itself to entirely new hardware and storage. In this scenario, you set up a new Exchange server, replicate public folders, migrate mailboxes and rehome address books to the new server, and then decommission the old server. This method requires the most over
To continue reading for free, register below or login
To read more you must become a member of SearchStorageChannel.com
head --you're setting up an entirely new server after all -- but it may be the most elegant in the long run, and may even mean the least amount of total downtime. It also gives you a window of opportunity to address any storage issues with the Exchange server itself (i.e., its system disks and not just its database storage).
3. New database in a new storage group
In this scenario, you create a new database for Exchange, in a new storage group, located on a fresh storage device. Mailboxes and other structures can then be moved there as needed, and the old database or group can be taken offline when it's no longer populated. This scenario is also a lot less obtrusive than taking everything offline at once since only one mailbox at a time is inconvenienced, but it may prove to be more trouble than it's worth if the Exchange installation in question has reached its maximum allotment of databases and/or storage groups.
Note that the limits for how many databases and storage groups you can create within Exchange vary between editions, sometimes drastically. Exchange 2003 Enterprise Edition can support four storage groups with five databases per group; Exchange 2007 Enterprise Edition can hold 50 groups with up to 50 databases in each (probably a reflection of the product being rewritten to take advantage of 64-bit platforms).
A few other caveats are worth keeping in mind no matter what approach you ultimately take. First, any attempt to move an Exchange database to new storage should be preceded by a snapshot backup of some kind. There's nothing worse than starting to do something like this, then having it aborted and having no way to return. Also make sure that a normal backup is performed of the Exchange store after the move is finished, which truncates transaction logs and makes future recovery operations less involved.
Second, when you move Exchange stores, the system path and transaction log path for any Exchange database should be on separate physical drives whenever possible -- not two partitions of the same drive, or sharing the same partition. This not only increases parallelization and performance, but improves your chance of performing a recovery if one of those two volumes should go bad on you.
Finally, I've mentioned in the past that if you move mailboxes, you should use the Move Mailbox Wizard to preserve single-instance storage. However, Microsoft has pointed out in this Exchange Store resource that single-instance storage (SIS) "is designed to improve the delivery performance of the server when delivering to many people, and not necessarily to save space on the disk." So if you have no choice but to use a migration technique that breaks SIS, you'll probably be moving to devices that can handle the additional space anyway. Also, depending on the data retention policies in effect, the non-SIS messages may eventually be cycled out of active use.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows.
