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?

Tohuw
  • 498
  • 2
  • 9
  • 24
  • 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 '13 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 '13 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 '13 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: http://exchangeshare.wordpress.com/2008/05/22/move-committed-exchange-transaction-logs/ – joeqwerty Sep 18 '13 at 20:58
  • @joeqwerty, funny, I just saw that a little before you posted. What I didn't like is that I'd have to run it manually, but overall it's a pretty good solution to be safer about it. If you're into the +rep thing, feel free to convert your comment to an answer. – Tohuw Sep 19 '13 at 13:14
  • 3
    Fantastic question, by the way – mfinni Sep 19 '13 at 14:43

5 Answers5

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/

Tohuw
  • 498
  • 2
  • 9
  • 24
TheCleaner
  • 32,627
  • 26
  • 132
  • 191
  • 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 '13 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 '13 at 17:55
  • Hmm.. Didn't check the TechNet blog link, but I will now. Thanks. – joeqwerty Sep 19 '13 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 '13 at 21:29
  • I tried this as well, but it did not work. The shadow copy appeared to succeed based on the console output, but I saw no such message in eventvwr, nor did a "Previous Version" become available for the database file or the host drive. – Tohuw Sep 23 '13 at 20:14
  • @Tohuw - were you able to try the vsstester script on the technet blog link? http://blogs.technet.com/b/exchange/archive/2013/04/29/troubleshoot-your-exchange-2010-database-backup-functionality-with-vsstester-script.aspx - I know it requires input during a run, but it would prove if it truly works or not. I would test it but we are on O365 now. – TheCleaner Sep 23 '13 at 21:04
  • @TheCleaner No, but I can try that soon. It's trivial to cause this problem again. – Tohuw Sep 24 '13 at 22:39
  • 1
    This has worked for me on Server 2008 R2 and Exchange 2010. Unfortunately I don't know why other people are having problems. – Mark Henderson Aug 25 '14 at 00: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

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 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 '13 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

StackzOfZtuff
  • 1,842
  • 13
  • 21
Ross
  • 21
  • 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 '14 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.
Tohuw
  • 498
  • 2
  • 9
  • 24
bchris999
  • 21
  • 1
  • Good input, @bchris999. I've edited the accepted answer with your additions and submitted that for peer review. – Tohuw Jun 23 '18 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!

Eric Simson
  • 78
  • 4