6

I have several separate test environments running 2008 R2 and Exchange 2010, at varying patch levels and for varying reasons. One consistent issue I encounter is that transaction logs for Exchange are not truncated because no backup solution is in place, nor do I want one.

So, as I see it, that leaves me with three options:

  1. Enable circular logging. This is not desirable for some of the test scenarios, as it may conflict with properly emulating a specific environment.
  2. Dismount all databases and run eseutil /mh. This works, but it's a cumbersome maintenance process.
  3. Some pseudo-backup utility (or some trick with a supported, low-impact one) to "trick" Exchange into believing it is now safe to truncate.

The first two I can do but rather wouldn't. Is there a way to do the third option?

6
  • 1
    I only say this because it is a test environment. But if you don't care to have a backup nor want circular logging you could always (either manually or via a script) delete old transaction logs. You wouldn't be able to rollback properly, but if you don't care to do so, there you go.
    – TheCleaner
    Sep 18, 2013 at 17:44
  • @TheCleaner, good point, but how can I determine that a log is safe to delete? Is there a trivial, automatable way to do so?
    – Tohuw
    Sep 18, 2013 at 17:45
  • Sure, just delete anything older than x number of days if you want. If you do it manually, just sort the logs by date and then delete everything older than this week for example. Any DB backup will be considered "dirty" but if you truly don't care...it'll work fine. Don't delete anything from today basically. You could but why bother?
    – TheCleaner
    Sep 18, 2013 at 17:49
  • Just found this. This should allow you to "safely" move committed transaction logs, which you can then delete. Circular logging, eseutil /mh, backups and manual log deletion (scary) not needed: exchangeshare.wordpress.com/2008/05/22/…
    – joeqwerty
    Sep 18, 2013 at 20:58
  • 3
    Fantastic question, by the way
    – mfinni
    Sep 19, 2013 at 14:43

5 Answers 5

10

Not to steal JoeQwerty's thunder, as I think his answer to this question is more than valid and definitely applicable in pretty much any scenario, except possibly yours. (Hence why I upvoted it.) However, I did find a way to do what you are after...

Fake VSS backup

Basically what this does is fake a VSS backup on the volume that the Exchange database is on, which ends up causing Exchange to truncate the logs.

Breaks Incremental Backups

This will break any backup softwares incremental backup chain so the next real backup will have to be a full backup.

Use Passive Copies

In a DAG, do this on a passive copy if possible.

Procedure

You have to add both the drive/mount point for the database and the log.

  1. Open Command prompt as Admin
  2. Run diskshadow
  3. Type add volume x: (where "x" is the drive for the Exchange database)
  4. Type add volume y: (where "y" is the drive for the Exchange log)
  5. Type begin backup
  6. Type create. This will take a few minutes while VSS does its thing.
  7. Type end backup. This is where it will set the logs to truncate. You will have to wait for the next log to generate before it starts to happen.

At that point if you look in the Application eventvwr logs you should see an entry similar to:

Screenshot of event

(Or you can try PowerShell like so: Get-EventLog -LogName application -Source msexchangeis | select -first 10)

Hope that helps...

Sources

Citation: http://ilantz.com/2011/10/26/how-to-manually-purge-exchange-server-logs-clean-and-easy/

8
  • 1
    As coincidence would have it, I needed to purge the transaction logs in Exchange 2010 today due to a BackupExec backup failure. I tried this method (twice) and it didn't appear to work.
    – joeqwerty
    Sep 19, 2013 at 16:36
  • well crap...the comments all are positive. Did you check the Technet link he linked to as well? That script was much more intense. I don't have an on-prem Exchange to test it on, maybe the OP can test and see if it works for him or not.
    – TheCleaner
    Sep 19, 2013 at 17:55
  • Hmm.. Didn't check the TechNet blog link, but I will now. Thanks.
    – joeqwerty
    Sep 19, 2013 at 17:59
  • Bah, wish I had seen this earlier before I nuked those old logs a different way! I'll give this a go when I can and see what happens. Danke!
    – Tohuw
    Sep 19, 2013 at 21:29
  • 1
    This has worked for me on Server 2008 R2 and Exchange 2010. Unfortunately I don't know why other people are having problems. Aug 25, 2014 at 0:22
6

Use Windows Server Backup to backup the server. It will purge the Exchange Server transaction logs after a successful backup.

http://www.techrepublic.com/blog/datacenter/back-up-exchange-2010-with-this-windows-server-2008-r2-feature/3006

http://technet.microsoft.com/en-us/magazine/jj906377.aspx

Edit

You could try this to forego the backup route. It's a manual process, but it's probably safer than anything else, short of a backup:

http://exchangeshare.wordpress.com/2008/05/22/move-committed-exchange-transaction-logs/

EDIT: This tool doesn't seem to exist in Exchange Server 2010

1
  • I will likely do this, but I was hoping for a method that didn't actually create backups, as I will now have to have some medium (SMB share, USB drive, etc.) to store a backup I'll never want. I should have been more clear about that in the original question. Thank you for your answer.
    – Tohuw
    Sep 18, 2013 at 17:30
2

In this scenario I would:

  1. Enable Circular Logging
  2. Dismount the store/DB to apply this change.
  3. Mount the store/DB this will take some time to sort out the logs.
  4. Disable Circular Logging.
  5. Dismount the store/DB to apply this change
  6. Mount the Store/DB.

Hope this helps,

Ross

1
  • You know, that's not a bad idea, because I may be able to automate that change. It's just the kind of not-safe but possible hack that could work out in this test environment. Next time I run into it I'll give it a go. Thanks @Ross!
    – Tohuw
    May 23, 2014 at 14:52
2

(Adding a new answer because I don't have a high enough reputation to add comments to @TheCleaners existing answer)

Fake VSS backup

Breaks Incremental Backups

This will break any backup softwares incremental backup chain so the next real backup will have to be a full backup.

Use Passive Copies

In a DAG, do this on a passive copy if possible.

Procedure

You have to add both the drive/mount point for the database and the log.

  1. Open Command prompt as Admin
  2. Run diskshadow
  3. Type add volume x: (where "x" is the drive for the Exchange database)
  4. Type add volume y: (where "y" is the drive for the Exchange log)
  5. Type begin backup
  6. Type create. This will take a few minutes while VSS does its thing.
  7. Type end backup. This is where it will set the logs to truncate. You will have to wait for the next log to generate before it starts to happen.
1
  • Good input, @bchris999. I've edited the accepted answer with your additions and submitted that for peer review.
    – Tohuw
    Jun 23, 2018 at 19:57
0

Please refer following link, it covers all necessary steps:

https://community.spiceworks.com/topic/2209505-microsoft-exchange-log-truncation-guide

Suggestion: The best practice is to store exchange database and log files on completely separate disks. This will protect exchange server from data loss if any disk has a failure.

Hope it will help you!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .