Truncate logs

[trackstar]

Hello,

Can somebody confirm that the truncate of the logs occur right after the snapshot has been removed for the latest version? I remember the previous version it issued the commands before the snapshot removal.

Thanks,
TT

[Gostev]

Confirming.

[trackstar]

Thanks.

[ChrisGrijzen]

Case ID# 01688004 Truncating Exchange transaction logs after Removing VM snapshot

Why is the step "Truncating Exchange transaction logs" performed after the step "Removing VM snapshot"?

During the removal of the snapshot Exchange circular logging is not active, causing the disk to fill up with transaction log files. The sooner Exchange returns to circular logging, the sooner the (write) stress on the disk, including the stress on the snapshot being removed, is relieved. I see no reason why Exchange cannot return to circular logging sooner. The consistent Exchange database is already saved in the snapshot, and the snapshot is already saved on the repository. What kind of extra safety is gained by waiting for the snapshot to be removed?

Kind regards,

Chris Grijzen

[ChrisGrijzen]

I am sorry to see my post merged with a dead thread without any relevant information.

@Anton Gostev: could you please shed some light on the design decision to perform Exchange backups using this sequence of steps?

Kind regards,

Chris Grijzen

[PTide]

Hi and welcome to the community!

There is another reason to perform truncation after snapshot removal beside what's been told by support engineer - if backup does not complete successfully, you will not have a good backup, and your transaction logs will be gone. You will not be able to restore in case of disaster. Backup is considered successful only after snapshot has been deleted - that happens only after successful commit. Does such behaviour cause problems in your environment? Please provide more details.

Thank you.

[ChrisGrijzen]

The way I see it, the success or failure of the removal of the VMware snapshot of the virtual machine has no impact on the success of the backup, or the ability to restore it. It only impacts the result status of Veeam job (success/failed), because one of the steps of the Veeam job failed. The Exchange data is successfully transfered to the Veeam repository. There is no risk of losing a recovery point. VMware snapshot removal can be a very lenghty operation. Nothing is gained by waiting for the VMware snapshot removal to finish (successfully or not), while a big negative side effect is introduced: during the long waiting period (Case ID# 01688004 describes a waiting period of several hours) Exchange is not operating in circular logging mode. Inside the virtual machine, Exchange transaction logfiles are filling up the filesystem. An extension of the filesystem is not possible, because of the VMware snapshot that is being removed. Outside the virtual machine, the extra deltas in the vmdk, caused by Exchange writing to both the database files and the transaction log files, enlarge the VMware snapshot and delay the removal of the VMware snapshot. In this particular case, the sequence of the steps in which Veeam has designed Exchange backups caused a big risk to the availability of Exchange. In this particular case, availability of Exchange was more important than a backup. I think we can agree to disagree on the optimal sequence of steps to perform an Exchange backup. Most environments are probably best served by what Veeam is offering. It would be nice if we could tune the sequence of steps ourselves in this particular case.

Kind regards,

Chris Grijzen

[ChrisGrijzen]

I have thought about this some more. Most Exchange environments are probably not using circular logging and for these environments Veeam is probably offering an excellent way to perform backups. The minority of Exchange environments that use circular logging would probably benefit from returning to circular logging as soon as possible by performing the truncate logs step earlier in the job sequence (maybe even right after creating the VMware snapshot).

Kind regards,

Chris Grijzen

[PTide]

Thank you for your feedback! All what you have said sounds reasonable, however new features are implemented based on the demand. If you want to push for that feature you can open a separate feature request thread with a brief description of the problem so other users can vote and leave comments.

Thank you.

[zoltank]

I'm currently backing up my Exchange 2010 environment (2 server DAG) with Veeam and application aware processing turned on. It works great and I regularly use the item level restore to recover emails, etc.

We're about to do a cross forest migration which is going to generate a lot of log files. More log files than we have space on the drive for. Therefore I need to enable circular logging on the databases before the migration begins. However, Microsoft recommends against using circular logging with VSS backups as the backup can fail: http://blogs.technet.com/b/exchange/arc ... 10672.aspx

So, if I perform Veeam application aware backups of my Exchange 2010 with circular logging, will those backups still be viable?