Comprehensive data protection for all workloads
Post Reply
trackstar
Expert
Posts: 167
Liked: 4 times
Joined: Mar 11, 2013 9:47 pm
Contact:

Truncate logs

Post by 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
Chief Product Officer
Posts: 31805
Liked: 7299 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Truncate logs

Post by Gostev »

Confirming.
trackstar
Expert
Posts: 167
Liked: 4 times
Joined: Mar 11, 2013 9:47 pm
Contact:

Re: Truncate logs

Post by trackstar »

Thanks.
ChrisGrijzen
Novice
Posts: 4
Liked: never
Joined: Nov 22, 2015 11:52 am
Full Name: Chris Grijzen
Contact:

[MERGED] Truncating Exchange transaction logs

Post by 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
Novice
Posts: 4
Liked: never
Joined: Nov 22, 2015 11:52 am
Full Name: Chris Grijzen
Contact:

Re: Truncate logs

Post by 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
Product Manager
Posts: 6551
Liked: 765 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Truncate logs

Post by 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
Novice
Posts: 4
Liked: never
Joined: Nov 22, 2015 11:52 am
Full Name: Chris Grijzen
Contact:

Re: Truncate logs

Post by 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
Novice
Posts: 4
Liked: never
Joined: Nov 22, 2015 11:52 am
Full Name: Chris Grijzen
Contact:

Re: Truncate logs

Post by 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
Product Manager
Posts: 6551
Liked: 765 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Truncate logs

Post by 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
Expert
Posts: 230
Liked: 41 times
Joined: Feb 18, 2011 5:01 pm
Contact:

[MERGED]: Exchange 2010 circular logging?

Post by 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?
Post Reply

Who is online

Users browsing this forum: AdsBot [Google], Google [Bot], miguel.salinas and 133 guests