log files in Exchange Server

pts.
Tags:
E-mail applications
Microsoft Exchange
I have a real problem developing in Exchange Server 2k. We have 90 users and the log files are growing to an unmanageable size, which creates problems for my backups. Is there anywhere I can set these to automatically delete after a period of time?

Answer Wiki

Thanks. We'll let you know when a new response is added.

Two methods I can tell you-
1. Enable circular logging. This will only keep a couple of log files, but you will not be able to fully recover the Exchange store if you had to restore from backup.
-or-
2. Backup the information store and have the backup software flush committed logs. This is my recommendation. Each time the backup runs, all committed log files will be removed. Also, you will be able to fully recover the information store, if necessary.

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Jcdavistech
    Backing up the information store removes the committed log files. This backup is also a very necesary task to ensure continuity in the event of a disaster. This backup can be done either with the standard NT backup utility or with any Exchange aware backup product. I would definately recommend this strategy over enabling circular logging. Enabling circular logging could prevent you from being able to accurately troubleshooting errors in the information store, so be very careful about enabling this option
    0 pointsBadges:
    report
  • Stevesz
    If you have an Exchange aware backup, the logs should be committed and flushed by the backup. In many Exchange aware backup programs, this is an option that needs to be checked. If you are creating enough log files between backups, and you are doing daily backups, you need more disk space. Add a drive to your server and move th elog files to the new drive. The circular logging mentioned in the earlier reply should only be used as a last resort. Doing so could present problems should you need to recover your Exchange database, and the log files have not ben committed before being overwritten.
    2,015 pointsBadges:
    report
  • Sbusiso
    Hi there, Backing up Exchange should resolve this issues, so I suggest that you get your backup solution to work properly.
    0 pointsBadges:
    report
  • ColinNZ
    To fully appreciate what others have replied with (above) you need to understand what the transaction log files are used for: Every message transaction in exchange is first processed in memory, then stored in a transaction log file (very fast write time), and only then committed to the exchange database (comparatively slow write time). If circular logging is turned off (which it should be), transaction logs record every message transaction made since the last full exchange backup. If circular logging is turned on, the logs are overwritten as required. There are two basic rules to observe when setting up Exchange (with respect to logs): 1. Transaction logs should always be stored on a disk with fast access times. I don't think this is so much of an issue these days, however in the days of Exchange 5.5, the setup program would test your HD write speeds, and recommend a particular drive for transaction log storage. 2. Transaction logs should ALWAYS be stored on a different disk, to the main exchange database. Exchange disaster recovery procedures all assume that you have lost either the database, or the logs, but not both! (If you're after a 'recovery back to time of failure'). I personally use mirrored disks for c: (System and transaction logs) and RAID5 for d: (database). We initially used one RAID 5 array for the entire server. This was a bad, and very dangerous practice. If you loose two disks, or your RAID card fails you loose logs and database. Transaction logs are useful in two situations: 1. Exchange server fails - i.e. power is cut to the server. Because the write time to the transaction logs fast, only messages held only in memory will be lost. This should be minimal. On power up, exchange will read the transaction logs, and commit anything outstanding to the exchange database. As I understand it - this is also the case with circular logging turned on. 2. A Hard disk fails (unrecoverable) If the c: (containing your transaction logs) fails, then you still have the exchange database. There may be a few uncommitted emails missing. These emails are lost. Build a new server (Disaster Recovery). Connect your existing database, and you're up and running with minimal message loss. If the D: (containing the exchange database) fails, then you'd better hope that you had circular logging turned off and were doing regular backups. In this case you replace the d: drive, and restore the exchange database from the last backup. On completion of the restore, exchange will replay the transaction logs (24 hours worth if you are backing up daily) and recovers any changes to the database since the last backup. End result - even fewer emails lost than in the last example (c: drive failure). 3. All drives fail - or you have circular logging turned on (ie Transaction logs are of no use). In this case, the best you can hope for is to return your server back to the point of the last good backup. You lose any email transactions done since your last backup. Hopefully this less than 24 hour?s worth. However... I'm picking that you may be looking for a new job shortly after... Given this description, you should now fully understand the importance of transaction logs, and the comments preceding mine. I?d recommend taking a look at the Exchange Disaster Recovery white papers on Microsoft?s web site. Exchange 2000: http://support.microsoft.com/?id=326052 Or ?Google? on: "disaster recovery" "white paper" exchange site:.microsoft.com I hope this was useful. A little long winded, but also fairly simplistic. ColinNZ
    0 pointsBadges:
    report
  • Gasup1
    I am currently using NT backup. Is deleting the log files in Exchange part of its' functionality? Perhaps I missed a step in the configuration.
    0 pointsBadges:
    report
  • Techtone
    I fully agree with colin. Well said old boy, It is definately best pructice to understand entirely the "behind the scenes" activity of any Server / Service before making changes or installing. I couldnt have explained in SHORT any better my-self. Colins advise to read the white papers first is strongly reccomended. You could also look at MS Exchange Server 2003 Disaster Recovery Operations Guide. www.microsoft.com/technet/prodtechnol/exchange/guides/DROpsGuide/516ca17d-5452-41eb-a2d9-dc95f16405a4.mspx Good Luck and Well said again Colin!! Regards: TT
    0 pointsBadges:
    report
  • ColinNZ
    In reply to Gasup1 The following is a quote from the DR Document for Ex2K (Chapter 6 page 111. URL for this PDF is in previous reply) Normal backup A Normal backup archives every selected database and all necessary log files. Log files older than the checkpoint at the time the backup was started are deleted after the backup completes. If you perform a Normal backup on a daily basis, you can prevent log files from monopolizing space on the hard disk. This is the simplest online backup method. If using NT Backup, a Normal backup is the recommended method. The other backup choices do not truncate the transaction logs: Copy Backup Differential Backup Incremental Backup Daily Backup (performs the same function as a Copy Backup) Full descriptions of the above backups are also available on the same page. Regards ColinNZ p.s. Thanks Techtone!
    0 pointsBadges:
    report
  • RichardDoe
    NTBackup is Exchange aware and should be deleting your log files when it is run. If this is not the case, your backups are probably failing. I would take a good look at the backup log file and see what's going on. Also, totally agree with reading the disaster recovery plan. You need to know this information like the back of your hand if you're going to administer Exchange ;-)
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following