What Uses the Disk Space?
This is for Exchange 2003 ONLY. For the version for Exchange 2007, click here: What uses Disk Space on Exchange 2007
Among some Exchange administrators there is some confusion of the use of disk space. Usually when an administrator comes in one morning to find that the server has died because it has run of our disk space.
There are up to four main types of files that can grow on an Exchange server.
- The Exchange Database Files
- The Exchange transaction log files
- Message Tracking log files.
- Web Access Log Files
- Exchange 2000 and Exchange 2003 SP1 Bad Mail Files
Identifying the file use
In order to work out where the disk space has gone, you need to identify the file types.
A good first option is to use a tool which will analyse the disk space and tell you what folders have the most data in them. Use something like TreeSize for this. (Download). Once you know where the space is being used up, you can look to see what they are.
Exchange Database Files
Exchange database files are made up of two files, which should be treated as one - the stm file and edb file. On a default installation of Exchange 2000 and 2003 you will have two file of each type. The files priv.edb and priv.stm are the mailboxes. The files pub.edb and pub.stm are your public and system folders. Do nothing with those files while Exchange is running.
Message Tracking Logs
Message tracking logs are a lot of every message that goes through the server. They only log the date time, sender and recipient, plus if you have enabled it, the subject.
Exchange 2003
You can see if you have message tracking enabled by looking on the Properties of the Exchange 2000/2003 server in ESM. Message tracking is on the first tab. Message tracking logs can be set to clean themselves up - a good idea is to keep 30 days of logs. However if you need to, you can delete the tracking logs.
More information on message tracking is here.
Web Access Log Files
If your site is heavy user or web services, such as Outlook Web Access, RPC over HTTPS, Exchange ActiveSync then you will quickly clock up web logs. These are standard IIS logs and therefore can be treated as such. The default location for them is C:\Windows\System32\Logfiles. For the default web site it will be a folder named W3SVC1. The files in that folder can be deleted without any issues, no services need to be stopped. However you may wish to keep the last month or so in case you need to refer to them in the future.
Bad Mail - Exchange 2000 and Exchange 2003 SP1 (by default)
Exchange 2000 introduced the concept of Badmail - which is a directory that stores all of your bad mail email messages that generated a Non Delivery Report. Badmail functionality was switched off by default from Exchange 2003 Sp1 and higher - and for most administrators there is no need to enable the feature.
However on Exchange 2000 it can quickly eat lots of space, particularly if you are a high traffic server.
Due to the nature of the badmail messages, which are very small files and lots of them, viewing the badmail folder in Windows Explorer is bad idea. Instead use the command prompt to browse to the badmail folder. You will find it in \exchsrvr\mailroot\vs 1\badmail.
If there is a lot of content in there, delete it either by using the command prompt, or renaming the folder and doing a SHIFT-DEL on the folder (not its contents), so that it skips the recycle bin. Exchange will recreate the folder if required.
Microsoft have bad mail management scripts available to download here: http://www.microsoft.com/downloads/details.aspx?familyid=782aaf0f-6239-40ad-adda-97863d852ff7&displaylang=en
Exchange Transaction Logs
Exchange transaction logs are the most common cause of loss of disk space use, as they are not flushed unless there is a successful backup. After a backup is successful the transaction logs are marked as committed and flushed. If a backup fails for some reason then you can get a rapid build up of the logs. The transaction logs are a log of everything the Exchange server has done since the last backup. Transaction log files are easily identified as they are always the same size - 5120kb.
Do NOT delete these files manually.
If you are seeing a lot of transaction log build up, then you should first check your backups to see that they are working correctly. If you are using a third party backup tool to backup Exchange and it doesn't seem to be working correctly, then as a quick and dirty method to flush the logs, use ntbackup that is built in to Windows on the Exchange server to backup Exchange. This will flush the logs.
A rapid build up of transaction logs can also be an indication of a problem with your email - an email loop or the server is being abused by a spammer. This should be investigated as well, particularly if the backup was successful and the transaction logs are all timed after the backup has completed.
If you need to create space quickly, then transaction logs will compress very easily with little performance impact. Do NOT compress the entire directory, as this can cause problems. When you are compressing the files, make sure that you only select the transaction logs - not the database files that may be in the same folder, nor any other files that are in the folder that are not 5120kb in size. Do not compress the current log file either, as that will have a performance impact on the server.
If you do need to manually delete the files, or you have reason to believe that Exchange isn't flushing the logs files correctly after a backup and there are committed log files still there, then you should review this KB article: http://support.microsoft.com/kb/240145
Questions
Q: How can I tell when the last successful backup was taken?
A: You can see if Exchange is aware of a successful backup in ESM, Servers, <your server>, <your storage group>, <your mailbox store>. Right click on on the mailbox store and choose Properties. Click on the tab Database and the last successful backup date and time is shown.
Q: I backup our server using Ghost, True Image or other disk image based system, but the transaction logs don't flush.
A: This type of backup is not considered by Exchange to be a valid backup of the database and therefore will not flush the transaction logs.
Exchange isn't particularly well suited to this type of backup either. These are snap shot type backups and therefore do not give you options for restoring the additional data.
For example, you run a backup at 3am on a Tuesday which completes successfully. The next day your users come in, work on their email etc. At 1am the next morning, the server fails and you need to restore from a backup.
With an image based backup you would lose the last 22 hours of email. For many companies, the most recent email is the most valuable.
However if you had carried out an Exchange aware backup and had also followed the best practises of having the Exchange database separate from the transaction logs, you could restore the data and then replay the transaction logs in to the database. This would bring the database close to the point of failure.
If you insist on carrying out an image based backup type without an Exchange aware backup application then you should enable circular logging. This will ensure that there is not a build up of the transaction logs, but limits your data recovery options.
Q: Why shouldn't I simply enable circular logging to get rid of the transaction logs?
A: Circular logging should not be considered a valid method of dealing with transaction logs that have built up and not been flushed by a backup application. You should investigate why the backup application and/or Exchange is not flushing the committed logs.
Q: Can I move the database and/or transaction logs to another drive?
A: You can move both elements to another drive. It is actually best practises to have them on separate physical drives/arrays for performance and redundancy reasons. To move the files, follow the instructions in this kb article http://support.microsoft.com/kb/821915.
Q: Can other things take up a lot of space?
A: A very common cause of rapidly reducing disk space is Shadow Copies. You should investigate whether Shadow copies is enabled and if it is, reduce the amount of space available to it.
Also don't forget to look at old user profiles, temp files and temporary internet files which can also take up a lot of space, particularly on newly built servers where you could have a lot of remains from application installations.