Comprehensive data protection for all workloads
Post Reply
raugustine
Influencer
Posts: 11
Liked: 3 times
Joined: Mar 05, 2015 1:22 pm
Full Name: Ryan Augustine
Contact:

Transaction logs with backups and replications

Post by raugustine » Mar 05, 2015 2:19 pm

I did some digging in the forum, and couldn't find anything that answered this question.

Here is the sceanrio: I have a customer that backs up their VMware environment once per day with Veeam. They also do multiple replication jobs to their DR site at different frequencies (30 min, 6 hour, once daily) depending on the critical nature of the server.

If I am doing one backup per day of a VM, but also doing multiple replications per day of the same VM, how should I handle truncation of Exchange/SQL logs?

Should I only truncate the transaction logs for the machines in the backup job for recoverability purposes and disable the replication log truncation, or should I have log truncation turned on for all of the jobs?

Currently, the application aware processing is truncating transaction logs on all of the jobs. I am thinking that leaving the application aware processing on but having it just copy the logs not truncate them on the replication jobs, and having the backup jobs handle log truncation would probably be the correct route. My thinking behind this is that if say I back up the Exchange server at 8pm, and it crashes the next day at 4pm, I would need to restore the machine from backup and then copy the entire database and log folders (150+ GB) from the last replica, since I can't just roll the Exchange logs forward.

Any suggestions on which route to go would be appreciated. Thanks.

Ryan

Vitaliy S.
Product Manager
Posts: 23619
Liked: 1708 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Transaction logs with backups and replications

Post by Vitaliy S. » Mar 05, 2015 2:31 pm

raugustine wrote:If I am doing one backup per day of a VM, but also doing multiple replications per day of the same VM, how should I handle truncation of Exchange/SQL logs?
We recommend to do logs handling by the backup job. Replication does not do anything with the logs by default when you enable application-aware image processing.
raugustine wrote:Should I only truncate the transaction logs for the machines in the backup job for recoverability purposes and disable the replication log truncation, or should I have log truncation turned on for all of the jobs?
The recommendation is to enable it for backup jobs only.
raugustine wrote:Currently, the application aware processing is truncating transaction logs on all of the jobs. I am thinking that leaving the application aware processing on but having it just copy the logs not truncate them on the replication jobs, and having the backup jobs handle log truncation would probably be the correct route. My thinking behind this is that if say I back up the Exchange server at 8pm, and it crashes the next day at 4pm, I would need to restore the machine from backup and then copy the entire database and log folders (150+ GB) from the last replica, since I can't just roll the Exchange logs forward.
Yes, your thinking is in-line with our recommendation on logs handling.

raugustine
Influencer
Posts: 11
Liked: 3 times
Joined: Mar 05, 2015 1:22 pm
Full Name: Ryan Augustine
Contact:

Re: Transaction logs with backups and replications

Post by raugustine » Mar 05, 2015 3:56 pm

Thanks for the reply. I will check my replication job settings and make sure they are all just set to copy. I do not recall ever changing the settings per VM, but they are configured to truncate logs on multiple machines. This was an upgrade from Veeam 7 to 8, so maybe that was on in V7 by default when you set up replication jobs.

Vitaliy S.
Product Manager
Posts: 23619
Liked: 1708 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Transaction logs with backups and replications

Post by Vitaliy S. » Mar 05, 2015 4:00 pm

Yes, you do want to manage your logs by 1 job only. Thanks!

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 69 guests