Split Exchange Log Truncation, from Backup Job

[ferrus]

When we introduced our new Veeam Backup for Exchange, we ran it in parallel with our legacy system for 6 months - and had perfect backups for all that time.
We built a brand new Exchange 2010 passive DAG member VM, that had a copy of all the databases and logs from the active servers.

To cut down on the backup window even further - we created pre and post job scripts, that suspended the DB sync - so there was almost no disk changes during the backup.
This meant a snapshot removal time of usually <1 minute - on an 18TB VM. This also allowed backups during the day. Perfect.

To action the final switchover from our legacy backup system, to pure Veeam - we just had to shutdown the old one, and enable log truncation on the Veeam job.

Straight away we noticed that the logs had stopped truncating.
On advice from this forum - we disabled the pre and post job. This fixed the issue.

Unfortunately - with the database and log sync still occurring during the backup window - we've gone from a <1 minute snapshot removal interval, to several hours.
Last night's was a new record: 9 hours 16 minutes.
This pushes back the merge time (which is already several hours) and means there's basically no time for the Backup Copy Job to Data Domain (which also takes several hours).
It's also removed the ability to take multiple/daytime backups.

To be honest, there are so many problem areas with our Veeam Exchange backup now - that we're looking at redesigning it in a few ways:
Adding a second passive node VM, to double the throughput to the DD.
Converting the backup job repository to 2016/ReFS - to reduce the merge period.
But one of the largest gains we could get, is be reintroducing/re-engineering the DB suspension script.

Is there a way to split Log Truncation from the main Backup Job - and control it via Powershell, for instance?

We could add it to the end of the job, following the command to re-enable the sync. Or just perform it once on a weekend.

[ferrus]

Bump ... perhaps I should have posted this in the Powershell forum

[DeadEyedJacks]

Hi Bump,

My understanding is that Exchange log truncation is not managed by Veeam Backup directly.
It is a process triggered by Microsoft VSS when an Exchange backup is successfully completed.

You can purge Exchange transaction logs independent of Backups, but that would invalidate your backup chains.
You might want to consider circular logging.

Also take a look at the Exchange blog article below
https://blogs.technet.microsoft.com/exc ... er-script/

Hope this helps

[ferrus]

Unfortunately enabling circular logging, is not applicable in our environment.

I think that log truncation - must be a VSS process triggered by Veeam however, as there's an option to enable or disable it within B&R console.
If only the VSS command could be captured, it could be run separately from the Backup Job - and solve the issue.

Ultimately, I don't want to do anything different to the normal backup - but the Veeam Backup workflow means our 18TB Exchange VM has to stay under a VM snapshot, with the DB sync active for the entire time, when it only needs to be active for a minute at the end of the backup.

We're in a crazy situation where Veeam backs up the entire Exchange infrastructure in 1-2 hours, and spends most of the remaining Backup 24hr window - on VMware and Backup file maintenance. This pushes the Backup Copy Job - which used to be the slow operation - out of the window completely.

It's made worse by the fact, that for 6 months - Veeam backed Exchange up perfectly every night - quicker than ever before. But this one requirement has tipped the balance completely.

[DeadEyedJacks]

We have similar issues with daily Exchange backups and extend snapshot removal times.

Our solution will be to move Exchange servers onto all-flash storage arrays !

Your approach of suspending replication is intriguing.

[ferrus]

It worked spectacularly well, and was a lot safer.
Without the pre-job, sometimes the snapshot commit could be a couple of hours, sometimes nine - depending on many factors like mail flow. With the script - its a constant 1-2 minutes, and is absolutely unaffected by large DB changes.
Without the pre-job, daytime backups would result in the VM being suspended until the snapshot committal could catch up. With the script, it's no different to a nighttime backup.

I think I've found the solution. I can't remember it always being there - but there's a scheduler in the pre and post job config screen.
Not for stages in the backup job, as i suggested above - but for every n number of jobs, or for certain weekdays.

So potentially I could run Backups with the scripts (no log truncation) on the weekdays, and without the scripts (logs truncated) on Sat/Sun.
As long as the volumes containing the logs have enough space (ours have), truncating the logs once a week should be fine?

Here is the dialog:



And here are our scripts, if you want to try them ...

pre job script:

Code: Select all

$session = new-pssession -ConfigurationName Microsoft.Exchange -connectionuri http://passive_dag_server_fqdn/powershell/ -Authentication Kerberos

Import-PSSession $session
get-mailboxdatabasecopystatus -server passive_dag_server_fqdn|Suspend-MailboxDatabaseCopy -SuspendComment "Backup" -Confirm:$False
Remove-PSSession $session

post job script:

Code: Select all

$session = new-pssession -ConfigurationName Microsoft.Exchange -connectionuri http://passive_dag_server_fqdn/powershell/ -Authentication Kerberos

Import-PSSession $session
get-mailboxdatabasecopystatus -server passive_dag_server_fqdn|Resume-MailboxDatabaseCopy -Confirm:$False
Remove-PSSession $session

[ferrus]

Together with Windows 2016 and ReFS on the Veeam repository that stores the Exchange Backup job - that should bring the merge time crashing down.

We might see Exchange backups of 1 hour again - instead of 18.