Move Exchange Server mdbdata or log files

Up til now our mailserver has stored its data on the same drive as the OS. Because the drive is filling up, I installed a new drive (D). I now want to move the logs or the data to that drive, as I understand that it's better to separate those two.

1) Can I just go to the First Storage Group > properties, and click on the browse-button for the transaction log location, change that to the new drive, and that's it? (We use only one storage group, one private and one public store. I suppose moving the FS Group is the same as moving just one store.)
2) Will this have consequences for people using the mailserver at that time? Or do I have to disconnect the server, or stop some services?
3) Does it make a difference to move the log or the data (system path location)? What is better? I suppose the new drive is a bit faster, but am not sure. (I've read it's better to separate mdbdata and log files in case one disk crashes.)
LVL 1
grexxAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
ikm7176Connect With a Mentor Commented:
1)http://www.msexchange.org/tutorials/MF001.html
   http://support.microsoft.com/default.aspx?kbid=821915&product=exch2003

2). During move your stores should be dismounted to move so the users will not be able to access the files

3.)  The exchange database consists of .edb and .stm files and .log files

(i)- .EDB and .STM Files:
An Exchange database consists of a rich-text .edb file and a native multimedia content .stm file. The .edb file stores all of the MAPI messages, tables used by the store process to locate all messages, and checksums of both the .edb and .stm files. The .stm file contains messages that are transmitted with their native Internet content. Because access to these files is generally random, they can be placed on the same disk volume.
As you plan your storage solution for these files, you should assume a certain amount of reliability; in other words, RAID-0 is not a recommended option. After reliability, your storage solution is based on a choice between optimizing performance (RAID-1) and optimizing capacity (RAID-5). If possible, use RAID-1 (or 0+1) for these files.
For public folders, you could store these files on a RAID-5 array, because data on public folders is usually written once and read many times. RAID-5 provides better read performance than write performance.

(ii)-Transaction Log Files
Each storage group generates its own set of transaction log files. Transaction log files maintain the state and integrity of .edb and .stm files. As new transactions occur, the transactions are simultaneously written in the log file and in memory. Log file transactions are not recognizable as Exchange messages, but they contain transaction data and specify where in the .edb file the data should be written. Before the transactions are committed to the .edb file, users access the transactions from memory. Then, when the load on the server has decreased, transactions are committed to the .edb file for permanent storage. The process of caching transactions in memory and deferring the update of the physical disk is referred to as a “lazy write.”
If a disaster occurs, and you must rebuild a server, you use the latest transaction log files to rebuild your databases. If you have access to the transaction log files and the latest backup, you can recover all of your data. However, if you lose the transaction log files, the data is permanently lost.
You can significantly improve the performance and fault tolerance of Exchange servers by placing each set of transaction log files on a separate drive. Because each storage group has its own set of transaction logs, the number of dedicated transaction log drives for your server should equal the number of planned storage groups. With a SAN solution, select a product that allows you to easily partition the virtualized space into separate virtual drives for storage groups and transaction log files. In addition, because transaction log files are critical to the operation of a server, you should protect the drives against failure, ideally by hardware mirroring using RAID. A RAID level of 0+1 (in which data is mirrored and then striped) is recommended.
Tip    Distribute the database drives across many small computer system interface (SCSI) channels or controllers, but configure them as a single logical drive to minimize SCSI bus saturation.


hope this helps you.
0
 
grexxAuthor Commented:
Thanks for your long answer. I forgot to tell we use Exchange 2000 on W2K, but that doesn't seem really important. We have quite a small network, one mailserver, one storage group, one store. We don't have a raid at the moment, not on this server anyway. (The disks are SCSI, but different in size, and I believe that won't work in a raid.)

I know the domain is installed on the mailserver as well, and the domain is mirrored on another server. (I don't know if this is common practice.) I haven't set up this network, but I've been told this would make a copy of all exchange data on the other server. I can't find any files on that server though.

I moved the log files to the other disk, after I made a full backup. This all was done really quickly, so quickly that I wondered if it even happened at all. But the files have moved, so I guess it's okay. I kept the other files on the original drive. With the backup and logs I can recreate all data. The backup is scheduled daily, and the backupfile is copied to tape the next day. I suppose this should be enough, or am I missing something?

NB: Changing everything to raid would be a very big operation, and is not an option, involving too much risks (as I'm not an experienced Windows network admin), and my manager probably wouldn't aprove (if it works and if we have backups, that's good enough).
0
All Courses

From novice to tech pro — start learning today.