I have a Windows Server 2012 machine running Exchange 2013 running as a KVM virtual machine. For my VM guests, I do full image based backups from the host, so that I can quickly restore to any host server simply by copying over the disk image files. This means I don't need a nightly full system backup.

That being said, without running a VSS Full Backup, the Exchange logs get massive (Specifically, the performance logs which are 500MB a day). In addition, I would also like to have a nightly backup of just the mail database.

What is the best way to accomplish this? A full backup of the C:\Program Files\Microsoft\Exchange Server\V15 folder as I found in one tutorial did not clear out the logs.

Thanks, Ben

  • I really hope you mean "transaction logs" there. 500MB/day of performance logs are definitely something that should not be gathered without a very good reason. – Massimo Jul 2 '13 at 17:00

This means I don't need a nightly full system backup.

So, what are you going to do when a user accidentally deletes their whole mailbox? You're not going to restore your whole Exchange environment and roll everyone else's mail back. You need a VSS backup of the Exchange databases for this kind of restore. Your current method is fine for DR purposes, but not for "whoops" purposes.

This TechNet article describes how to backup Exchange using the built-in Windows Backup. You should use this strategy to complement your existing image-based backups.

  • Thanks MDMarra. This is for a small environment (just a few users in testing) so a full restore is actually OK for me in most cases. As for "whoops" cases, I had thought that's what backing up the Exchange database folder was doing (Using "custom" in step 4b of the link you provided). – Fmstrat May 26 '13 at 16:07

If the log files are for the database, while everyone here would say DO NOT DO THIS, you can enable circular logging to keep the log files at bay. There are disadvantages to this, so I suggest you do some reading before changing this setting. It is a per database setting and once changed will require a dismount and remount of the database to take effect. The logs are there for a reason, but in some cases, you might not care, if so, then this might work for you.


I absolutely agree with the other answers, you really should do a proper backup of your Exchange databases.

Anyway, in order to avoid filling up your disk space with transaction logs (you were meaning transaction logs, right? 500MB/day of performance logs doesn't really make much sense...), you can enable circular logging, which just overwrites them instead of having them pile up:

Get-MailboxDatabase | Set-MailboxDatabase -CircularLoggingEnabled $true

If your snapshot is not quiescing the VM, then consider your backup corrupt. I had this issue with a Sharepoint server. Realize that Exchange uses Write-Ahead logging (Just like SQL). It commits the data to the the logs before its committed to the DB file.

If your server dies while there is even a small amount of non-committed data in memory, your DB files wont start.


Run a traditional exchange backup along side your snapshot. Or, use a Exchange aware snapshot engine (Veeam, etc.).

  • Ahem... write-ahead logging exists exactly for the purpose of saving a database from unrecoverable corruption if "your server dies while there is even a small amount of non-committed data in memory". Incomplete transactions would be rolled back (with possible data loss), but the DB would start just fine. That's exactly what those logs are there for. – Massimo Jul 2 '13 at 17:11
  • I have had issues in a virtualized environment where snapshot backups of databases are bad, and wont start because the data wasn't closed/committed. Regardless of me being incorrect about the logs, my overall answer reflects my experience with virtual snapshots. Using snapshots as a DB backup is not something anyone should recommend. Down-vote me all you want... – Linuxx Jul 2 '13 at 21:01
  • Using a VM snapshot as a backup solution is definitely wrong, I'm totally not arguing with that. But you are wrong about WAL, a proper transactional database should be able to survive almost everything, up to and including yanking disks out of the server while it's running. – Massimo Jul 2 '13 at 21:19
  • "up to and including yanking disks out of the server while it's running"... OK, well, I guess the Exchange restore I performed when my IBM storage array randomly rebooted was just a dream... And the Microsoft support engineer on the phone that was telling me to restore from backup was just smoking crack... I agree that my understanding of WAL was off, but wow... that statement just shouts "drinking the cool-aid"... – Linuxx Jul 2 '13 at 23:34
  • "&should be able to survive almost everything". Except for inconsistent files, which is what you get when you use disk snapshotting or VM snapshotting or SAN mirroring any other tactic like that. This is why Volume Shadow Copy was invented. – Greenstone Walker Dec 16 '13 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.