Exchange Server Pro » Backups

How to Set Up an Automated Exchange 2010 Database Backup Alert Email

Paul Cunningham — Mon, 30 Apr 2012 13:11:21 +0000

In recent articles I’ve taken you step by step through some techniques for sending email from PowerShell scripts. If you haven’t read those articles yet you can find them here:

I also shared with you a script that can be used to check Exchange Server 2010 database backups and alert you to any that have not had a recent backup.

Now it’s time to bring all of that information together and demonstrate how you can set up an automated database backup alert email for your Exchange Server 2010 environment.

The two components of this are:

The PowerShell script itself (we’ll use the one mentioned earlier but with some modifications to email-enable it)
Task Scheduler for automatically running the script each day

Script for Exchange Server 2010 Database Backup Email Alerts

To email-enable the script I’ve made just a few modifications. The original script used this conditional logic to display the report in the PowerShell window.

#If alert flag is true output the report
if ($alertflag -eq $true )
{
	Write-Host "The following databases have not been backed up in" $threshold "hours."
	$alerts | ft -AutoSize
}
else
{
	Write-Host "No backup alerts required."
}

To change this to send an email alert we can use this code instead:

#If alert flag is true send the email alert
if ($alertflag -eq $true )
{
	#HTML styles for nice formatting
        $style = ""

        #SMTP options for sending the report email
	$smtpServer = "ho-ex2010-caht1.exchangeserverpro.net"
	$smtpFrom = "reports@exchangeserverpro.net"
	$smtpTo = "administrator@exchangeserverpro.net"
	$messageSubject = "Exchange Backup Alerts"

        $intro = "The following databases have not been backed up in " + $threshold + " hours.

"
	$report = $alerts | ConvertTo-Html -Fragment

	#Get ready to send email message
	$message = New-Object System.Net.Mail.MailMessage $smtpfrom, $smtpto
	$message.Subject = $messageSubject
	$message.IsBodyHTML = $true
	$message.Body = ConvertTo-Html -Body "$intro $report" -Head $style

	#Send email message
	$smtp = New-Object Net.Mail.SmtpClient($smtpServer)
	$smtp.Send($message)

}

If any parts of that don’t make sense just refer to the previous tutorials on sending email with PowerShell.

Download the script file here: Get-DailyBackupAlerts.ps1 (downloaded 197 times so far)

If you’re using this script in your environment you will need to change the SMTP options to suit.

#SMTP options for sending the report email
$smtpServer = "ho-ex2010-caht1.exchangeserverpro.net"
$smtpFrom = "reports@exchangeserverpro.net"
$smtpTo = "administrator@exchangeserverpro.net"
$messageSubject = "Exchange Backup Alerts"

Save the script as Get-DailyBackupAlerts.ps1 in a folder called C:\Scripts on the server where you would like it to run each day. Note that the script depends on the Exchange Server 2010 management tools, so they will also need to be installed.

Using Task Scheduler to Run PowerShell Scripts

Now we need to configure the scheduled task in Task Scheduler. On a Windows Server 2008 server you’ll find this in the Administrative Tools. After you’ve launched Task Scheduler click on Create Task.

Give the task a meaningful name, set it to Run whether user is logged on or not, and also if necessary change the user account that it will run as (you may wish to create a special Exchange administrative account with a strong password for running these types of scripts).

On the Triggers tab click new and add a Weekly trigger for each of your normal business days that you want the script to run (eg Monday – Friday). Set the Start time to suit your normal backups finishing time and your own work schedule.

On the Actions tab click New and add an action of Start a program. Configure the program of powershell.exe and the arguments -command “c:\scripts\get-dailybackupalerts.ps1″

Click OK to finish creating the new task. You will be prompted to enter the credentials for the account that you configured the task to run as.

Now you can test the scheduled task by right-clicking on it in the Task Scheduler Library and choosing Run.

Assuming you have some databases that have not backed up recently you should receive an alert email shortly after running the scheduled task.

Note: if your backups are all up to date you can test the script by changing the $threshold variable to something very low such as 1.

Download the script file here: Get-DailyBackupAlerts.ps1 (downloaded 197 times so far)

Get more Exchange Server tips at ExchangeServerPro.com

Avoid Running Out of Transaction Log Disk Space on Exchange Servers

Paul Cunningham — Sat, 28 Jan 2012 12:45:12 +0000

Paul Robichaux’s recent Windows IT Pro column contains this passage:

If you don’t know when you’re about to run out of disk space on the log LUN, you’re totally doing it wrong. It leaves me slack-jawed with astonishment that in 2012 we still have administrators who suffer unplanned downtime due to log volumes filling up because of poor design or problems with backups. Stop the madness! Check your backups regularly and use monitoring, be it however primitive, to ensure that you don’t have this problem.

Paul is referring to this post on the MS Exchange Team blog, which mentions that:

…the number one reason why our Premier customers open Exchange 2010 critical situations is because Mailbox databases dismount due to running out of disk space on the transaction log LUN.

Either I missed that post when it was published a few months ago or I glossed over it and it didn’t catch my attention enough.

I’ve been stung by transaction log disks running out of space, even as recently as last year. I work in a very large Exchange environment where backups and storage monitoring are performed by two different teams, both of them outside of my team.

That puts us in the situation where failed backups, combined with either a storage monitoring problem or a human error in the escalation processes can (and has) caused a log volume to fill up. Another situation that can arise is when new servers are provisioned, our help desks begin putting mailboxes on them before they’ve been added to the backups.

Which is why I wrote this script to check the Exchange database backups and alert my team when they have not been backed up in the 48 hours or more. In fact that script is a better version than the one we run in production (I haven’t ported over the improvements I later made at home to the original).

Ever since we put it in place that script has alerted us to numerous situations before they could evolve into disasters.

Setting it up as a scheduled task to run daily is a job that will take you less than half an hour. I highly recommend it, not just because I wrote the script, but because it adds a valuable layer of protection to your environment.

Get more Exchange Server tips at ExchangeServerPro.com

PowerShell Script: Check Exchange 2010 Database Backups

Paul Cunningham — Sun, 06 Nov 2011 11:23:58 +0000

In almost any Exchange Server 2010 environment there will be a good reason for adding some additional monitoring of backups.

Perhaps the environment is large enough that the backups are managed by a separate team to the Exchange administrators, and so the Exchange admins just want to keep an eye on their database backups. Or even in a smaller environment the administrators may just want to be sure that their backup software isn’t reporting successful backups when in fact they may be failing.

In this post I will demonstrate a PowerShell script that you can run in an Exchange Server 2010 environment to report on any databases that have not successfully backed up in the last 48 hours. Let’s take a look at how this works.

Firstly, backup time stamps are retrievable using the Get-MailboxDatabase cmdlet for mailbox databases, or Get-PublicFolderDatabase for public folder databases. Here is an example:

PS C:\Scripts> Get-MailboxDatabase -Status | ft name,last* -auto

Name     LastFullBackup       LastIncrementalBackup LastDifferentialBackup LastCopyBackup
----     --------------       --------------------- ---------------------- --------------
MB-HO-01 11/6/2011 1:40:19 PM
MB-HO-02
MB-HO-03
MB-BR-01

You can see that one of the databases above has been backed up, but the others have not. In a script that checks both mailbox and public folder databases we could use this code to generate the report.

$dbs = Get-MailboxDatabase -Status
$dbs = $dbs += Get-PublicFolderDatabase -Status
$dbs | ft name,last*

Now we can see both the mailbox and the public folder databases.

Name                    LastFullBackup          LastIncrementalBackup   LastDifferentialBackup  LastCopyBackup
----                    --------------          ---------------------   ----------------------  --------------
MB-HO-01                11/6/2011 1:40:19 PM
MB-HO-02
MB-HO-03
MB-BR-01
PF-HO-01                11/6/2011 1:40:20 PM
PF-BR-01

It would be a simple matter to run that command and read the output every single day, but that would not be the most efficient way of checking database backups. There could be dozens or even hundreds of databases in that output, and we’d have to mentally perform the calculations to determine whether the backup time stamp is within the last 48 hours or not.

Instead we want to only to see databases that have not been backed up within the 48 hour threshold. To do this we can use some date maths. Because we’ve already retrieved the database objects into a collection called $dbs we can loop through them to perform the date calculations like this. Note that in this example only Full and Incremental backups are being considered.

foreach ($db in $dbs)
{
	Write-Host -ForegroundColor Gray "Checking" $db.name"..."

	$lastbackup = @{}
	$ago = @()
	[bool]$alertflag = $false

	if ( $db.LastFullBackup -eq $nul -and $db.LastIncrementalBackup -eq $nul)
	{
		$lastbackup.time = "Never"
		$lastbackup.type = "Never"
		[string]$ago = "Never"
	}
	elseif ( $db.LastFullBackup -lt $db.LastIncrementalBackup )
	{
		$lastbackup.time = $db.LastIncrementalBackup
		$lastbackup.type = "Incremental"
		[int]$ago = ($now - $lastbackup.time).TotalHours
		$ago = "{0:N0}" -f $ago
	}
	elseif ( $db.LastIncrementalBackup -lt $db.LastFullBackup )
	{
		$lastbackup.time = $db.LastFullBackup
		$lastbackup.type = "Full"
		[int]$ago = ($now - $lastbackup.time).TotalHours
		$ago = "{0:N0}" -f $ago
	}
}

One of three possible scenarios will be true:

If the database has not been backed up at all then both Full and Incremental time stamps will be nul, so all of the resulting values are set to “Never”
If the most recent backup was an Incremental then the type is set to “Incremental” and the $ago variable is set to the number of hours that has passed since that Incremental backup finished
If the most recent backup was a Full then the type is set to “Full” and the $ago variable is set to the number of hours that has passed since that Full backup finished

Now, because we’re only interested in databases that haven’t backed up in the last 48 hours (or have never been backed up at all) we can compare the $ago variable to our threshold of 48 hours, and if an alert needs to be raised set the alert flag to True and create an object with all of the desired information for our report.

if ( $ago -gt $threshold -or $ago -eq "Never")
	{
		$alertflag = $true
		$dbObj = New-Object PSObject
		$dbObj | Add-Member NoteProperty -Name "Server/DAG" -Value $db.MasterServerOrAvailabilityGroup
		$dbObj | Add-Member NoteProperty -Name "Database" -Value $db.name
		$dbObj | Add-Member NoteProperty -Name "Database Type" -Value $dbtype
		$dbObj | Add-Member NoteProperty -Name "Last Backup Type" -Value $lastbackup.type
		$dbObj | Add-Member NoteProperty -Name "Hrs Ago" -Value $ago
		$dbObj | Add-Member NoteProperty -Name "Time Stamp" -Value $lastbackup.time
		$alerts = $alerts += $dbObj
	}

That code actually goes inside the ForEach loop for the $dbs collection.

The final piece of the script is the report itself. We output it based on whether the alert flag is set to True or False.

if ($alertflag = $true )
{
	Write-Host "The following databases have not been backed up in" $threshold "hours."
	$alerts | ft -AutoSize
}
else
{
	Write-Host "No backup alerts required."
}

This example outputs the report to the PowerShell window but you could write your PowerShell script to send an email report instead if you wish.

Here is an example report:

PS C:\Scripts> .\Check-DatabaseBackups.ps1
Getting database list...
Checking MB-HO-01 ...
Checking MB-HO-02 ...
Checking MB-HO-03 ...
Checking MB-BR-01 ...
Checking PF-HO-01 ...
Checking PF-BR-01 ...
The following databases have not been backed up in 48 hours.

Server/DAG     Database Database Type Last Backup Type Hrs Ago Time Stamp
----------     -------- ------------- ---------------- ------- ----------
dag-headoffice MB-HO-02 Mailbox       Never            Never   Never
dag-headoffice MB-HO-03 Mailbox       Never            Never   Never
BR-EX2010-MB   MB-BR-01 Mailbox       Never            Never   Never
BR-EX2010-MB   PF-BR-01 Public Folder Never            Never   Never

And here is the complete script.

#
#.SYNOPSIS
#Checks the backup timestamps for the servers
#and alerts if a database hasn't been backed up
#in the last 48 hours
#
#.EXAMPLE
#.\Check-DatabaseBackups.ps1
#

#...................................
# Variables
#...................................

$ErrorActionPreference = "SilentlyContinue"
$WarningPreference = "SilentlyContinue"

$alerts = @()
[int]$threshold = 48

$now = [DateTime]::Now

#...................................
# Script
#...................................

#Get all Mailbox and Public Folder databases
Write-Host -ForegroundColor Gray "Getting database list..."
$dbs = Get-MailboxDatabase -Status
$dbs = $dbs += Get-PublicFolderDatabase -Status

#Check each database for most recent backup
foreach ($db in $dbs)
{
	Write-Host -ForegroundColor Gray "Checking" $db.name"..."

	$lastbackup = @{}
	$ago = @()
	[bool]$alertflag = $false

	if ( $db.LastFullBackup -eq $null -and $db.LastIncrementalBackup -eq $nul)
	{
		$lastbackup.time = "Never"
		$lastbackup.type = "Never"
		[string]$ago = "Never"
	}
	elseif ( $db.LastFullBackup -lt $db.LastIncrementalBackup )
	{
		$lastbackup.time = $db.LastIncrementalBackup
		$lastbackup.type = "Incremental"
		[int]$ago = ($now - $lastbackup.time).TotalHours
		$ago = "{0:N0}" -f $ago
	}
	elseif ( $db.LastIncrementalBackup -lt $db.LastFullBackup )
	{
		$lastbackup.time = $db.LastFullBackup
		$lastbackup.type = "Full"
		[int]$ago = ($now - $lastbackup.time).TotalHours
		$ago = "{0:N0}" -f $ago
	}

	if ($db.IsMailboxDatabase -eq $true) {$dbtype = "Mailbox"}
	if ($db.IsPublicFolderDatabase -eq $true) {$dbtype = "Public Folder"}

	#If backup time stamp older than threshold set alert flag and create object for alerting
	if ( $ago -gt $threshold -or $ago -eq "Never")
	{
		$alertflag = $true
		$dbObj = New-Object PSObject
		$dbObj | Add-Member NoteProperty -Name "Server/DAG" -Value $db.MasterServerOrAvailabilityGroup
		$dbObj | Add-Member NoteProperty -Name "Database" -Value $db.name
		$dbObj | Add-Member NoteProperty -Name "Database Type" -Value $dbtype
		$dbObj | Add-Member NoteProperty -Name "Last Backup Type" -Value $lastbackup.type
		$dbObj | Add-Member NoteProperty -Name "Hrs Ago" -Value $ago
		$dbObj | Add-Member NoteProperty -Name "Time Stamp" -Value $lastbackup.time
		$alerts = $alerts += $dbObj
	}
}

#If alert flag is true output the report
if ($alertflag -eq $true )
{
	Write-Host "The following databases have not been backed up in" $threshold "hours."
	$alerts | ft -AutoSize
}
else
{
	Write-Host "No backup alerts required."
}

If you’d like to schedule this report to run each day and alert you by email when databases are not being backed up then click here

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010: Are Passive Database Copies Included in Backups of DAG Members?

Paul Cunningham — Sun, 06 Nov 2011 04:23:45 +0000

In my article on backup error event id 2137 and what it means for Exchange 2010 a reader asked whether backups of Exchange 2010 DAG members include both the active and passive database copies.

Update: according to Microsoft, “All database copies can be backed up using an Exchange-aware, Volume Shadow Copy Service (VSS)-based backup application. However, the built-in support for Windows Server Backup is for active copies only. You can’t use Windows Server Backup to back up passive copies.” The rest of the article below has been left unedited, however be aware that the example demonstrated is of an unsupported scenario

The short answer is yes, however there are some important considerations to be aware of. From Microsoft TechNet:

Passive mailbox database copies are backed up using a separate VSS writer in the Microsoft Exchange Replication service. The Microsoft Exchange Replication service VSS Writer doesn’t support restores. Although you can back up a passive mailbox database copy using Microsoft System Center Data Protection Manager or a third-party Exchange-aware VSS-based application, you can’t perform a VSS restore directly to a passive mailbox database copy. However, you can perform a VSS restore to an alternate location, suspend replication to the passive copy, and then copy the database and log files from the alternate location to the location of the passive database copy in the file system.

To demonstrate this, here you can see the mailbox databases MB-HO-* that are currently active on server HO-EX2010-MB2. They have no LastFullBackup timestamp because they have never been backed up.

[PS] C:\>Get-MailboxDatabase -status | ft name,mounted*,lastfull* -auto

Name     MountedOnServer                     Mounted LastFullBackup
----     ---------------                     ------- --------------
MB-HO-01 HO-EX2010-MB2.exchangeserverpro.net    True
MB-HO-02 HO-EX2010-MB2.exchangeserverpro.net    True
MB-HO-03 HO-EX2010-MB2.exchangeserverpro.net    True
MB-BR-01 BR-EX2010-MB.exchangeserverpro.net     True

On server HO-EX2010-MB1 I ran a mailbox server backup using Windows Server Backup.

After the backup completed the following can be seen. First, the LastFullBackup time stamp has not been written.

[PS] C:\>Get-MailboxDatabase -status | ft name,mounted*,lastfull* -auto

Name     MountedOnServer                     Mounted LastFullBackup
----     ---------------                     ------- --------------
MB-HO-02 HO-EX2010-MB2.exchangeserverpro.net    True
MB-HO-01 HO-EX2010-MB2.exchangeserverpro.net    True
MB-HO-03 HO-EX2010-MB2.exchangeserverpro.net    True

Next, the disk that the backups were written to contain VHD files matching the size of the data stored on the backed up volumes. For example, the F: (Data) drive holds about 2Gb of data, and the VHD for that volume is about the same size.

Because we can mount the VHD as a disk on the server we have the opportunity to inspect the contents inside of it.

We can see that even though it was not the active databases at the time of the backup, the EDB file for database MB-HO-01 (and others) was still backed up by the server.

[PS] C:\>Get-ChildItem H:\ -Recurse | where {$_.name -like "*.edb"} | select name

Name
----
HO-PF-01.edb
MB-HO-01.edb
MB-HO-02.edb
MB-HO-03.edb
PF-HO-01.edb

Next I’ll run another backup of HO-EX2010-MB1, but this time the mailbox database MB-HO-01 has been made active on HO-EX2010-MB1.

This time the LastFullBackup time stamp is written to the database.

[PS] C:\>Get-MailboxDatabase -status | ft name,mounted*,lastfull* -auto

Name     MountedOnServer                     Mounted LastFullBackup
----     ---------------                     ------- --------------
MB-HO-01 HO-EX2010-MB1.exchangeserverpro.net    True 11/6/2011 1:40:19 PM
MB-HO-02 HO-EX2010-MB2.exchangeserverpro.net    True
MB-HO-03 HO-EX2010-MB2.exchangeserverpro.net    True
MB-BR-01 BR-EX2010-MB.exchangeserverpro.net     True

So what do we learn from this?

Reminder, the below should be read in conjunction with the notice at the start of the article, as backing up passive database copies using Windows Server Backup is not a supported scenario

Yes, passive database copies stored on a volume are backed up by Windows Server Backup
Yes, this allows backups of passive database copies to be restored, although not directly
Yes, this would allow a backup of a passive database copy to be used for disaster recovery of a database
No, the backup time stamp is not written when a passive database copy is backed up, so any monitoring of backups that involves checking that time stamp needs to take that into consideration

Get more Exchange Server tips at ExchangeServerPro.com

Review: Exchange Server 2010 Backup and Recovery Training

Paul Cunningham — Sun, 21 Aug 2011 12:23:35 +0000

How many times have you seen a forums thread that goes something like this:

System administrator has recently started at a new job
Something goes wrong – an Exchange server crashes or somebody deletes some emails they didn’t mean to
System administrator looks into it, and discovers that the Exchange server is not being backed up
They don’t know what to do next

I’ve seen that a lot. I’ve also had my fair share of phone calls with customers dealing with Exchange server problems and asked them when was their last successful backup. Sadly the answer is often “I don’t know”.

Exchange Server Backups – Serious Business

Sometimes I really do wonder if people realise how important Exchange Server backups are. Often the people that do realise it are those that have been burned by a serious disaster in the past.

Nobody wants to be the IT guy who has to explain why data has been lost forever. But a stunning number of people I meet really don’t know that much about backup and recovery, particular for Exchange servers.

I suspect that one of the reasons is that there is no Microsoft certification for backup and recovery. With no exam to study for, and no credential to earn, it just isn’t a topic that many people seem to proactively learn.

But take it from me, Exchange Server backup and recovery skills are among the most important ones that you can have as an IT professional.

Exchange Server 2010 Backup and Recovery Training

Because of how important these skills are, and because of how many nights I’ve lost trying to recover data for customers, I’m very glad to see that TrainSignal has come out with an Exchange Server 2010 Backup and Recovery training course.

The instructor for this course is J. Peter Bruzzese, the same guy who teaches the 70-662 and 70-663 training courses from TrainSignal. As an Exchange MVP, MCT, and long time consultant J. Peter is the right person to teach this subject, and he has delivered yet another high quality training program.

The training goes into more depth on the concepts of Exchange Server 2010 backup and recovery than most other training I’ve seen. Backups tend to get shoe horned into a single module of broader product training. This is the first training program I’ve seen that sticks to just the topic of backup and recovery – deep dive training at it’s best.

There is a good mix of theory and practice in the 16 lessons. To give you an example of why the theory is so important here is the overview for Lesson 5: Storage Architecture and Backup/Recovery Basics.

If you truly want to be able to recover your data, you need to understand the storage architecture in Exchange. That may sound deeper than it is, but ultimately we are looking at how Exchange takes an email and puts it in a database, and the steps along the way. Then we will discuss some best practices and theory with those databases, along with an understanding of Exchange provides some built in resiliency to help you avoid having to restore from a backup (because that is the LAST thing you really want to do).

That is the kind of deep understanding that is hard to pick up just from on the job experience.

The practical lessons are also very useful. It would be difficult to create a practical training course that covers everything about backup and recovery because there are just too many different backup products out there.

In this training program you’ll learn how to use Windows Server Backup and Microsoft Data Protection Manager to backup and restore Exchange Server 2010. Those are fine, but probably aren’t going to be the most common backup solutions you encounter in the real world.

However they do teach you the most important side of Exchange Server 2010 backup and recovery – the Exchange server side of it. Those are the most important skills to have, and you can carry them between different backup solutions as you need to.

What You Get with TrainSignal’s Exchange Server 2010 Backup and Recovery Training

When you buy the training package you get instant online access to the lessons, as well as a set of physical DVD’s that are shipped out to you. I’ve always enjoyed how quickly they show up at my door, usually within 7 days and for me they have to be shipped all the way to Australia. I’m used to waiting weeks for stuff to arrive from overseas.

There are nearly 8 hours of video lessons. This is focussed training that you can sit down and work through in a few days or a week and quickly achieve a result.

The DVD’s also include MP3 audio versions of the lessons. I’m a big fan of audio based learning, especially for the more theory-based lessons. Listening to them multiple times while travelling or doing other tasks really helps the information sink in.

Like I said earlier, there is no certification exam for this topic. You won’t earn an MCP or MCTS by completing the training. But you will learn some of the most valuable, and unfortunately the most rare, technical skills for IT professionals working with Microsoft Exchange Server.

Click here to find out more about TrainSignal’s Exchange Server 2010 Backup and Recovery Training.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 FAQ: Why is My Disk Filling Up with Log Files?

Paul Cunningham — Tue, 17 May 2011 12:00:56 +0000

Exchange Server 2010 customers sometimes ask why their server disk drive is filling up with log files. Usually they are referring to the transaction log files created by the mailbox databases.

Each Exchange 2010 mailbox database comprises two main parts:

the transaction log files
the database file itself

The folder containing the log files will look something like this.

A best practice for Exchange 2010 mailbox servers is to store the database and transaction log files on completely separate disks. This is to protect the server from data loss if one disk or the other has a failure.

The way this works is that each database change is written to a memory buffer and also recorded in a transaction log file. Periodically the memory buffer information is also written to the database file. When this occurs a checkpoint is updated that tells the server which transaction log entries have and have not been written to the database yet.

If the server was to unexpectedly restart, the database comes online in a “dirty shutdown” state and the checkpoint is used to tell the server which transaction log entries need to be replayed into the database to recover the information that was lost in the memory buffer when the server failed.

Over time these transaction logs will grow, because of course the mailbox database is continually changing as new mail arrives in mailboxes (as just one example). Eventually the log files will fill up the disk if they are not removed.

To remove the transaction log files the database needs to be backed up. When an Exchange Server database is backed up by a proper application-aware backup product, after the backup is finished the backup program will issue a command to VSS (Volume Shadow-copy Service) on the server that the backup was successful and to go ahead and truncate the transaction logs.

The server then proceeds to remove the transaction log files up to the nearest checkpoint prior to the backup commencing. Because the database can continue to change and write new transaction log files while a backup is in progress it is not unusual for multiple transaction log files to still be present after a backup has completed. However most of them will be removed, and regular backups are the method by which transaction logs can be kept from consuming all free disk space on the server (as well as the obvious benefit of having your Exchange databases safely backed up).

So if your Exchange Server disk is being filled up by transaction log files, the issue is likely to be one of the following:

Cause: You aren’t backing up the mailbox server

Solution: Back up the mailbox server with a proper Exchange Server application-aware backup product. There are commercial products available for this such as Symantec Backup Exec or you can use the built-in Windows Server Backup for the task.

Cause: You’re using the wrong type of backup

Solution: Make sure you’re running a backup job type that will truncate the logs. Full and Incremental backups will truncate the transaction log files, whereas Differential and Copy will not.

Cause: The backup is not completing successfully

Solution: Check your backup product for log file entries that indicate what the issue is.

Cause: The backup is completing successfully but transaction logs are not truncating

Solution: Check the Application Event Log on the mailbox server for errors with the log truncation process.

Get more Exchange Server tips at ExchangeServerPro.com

PowerShell Script: Check Exchange Mailbox Database Last Backup Time

Paul Cunningham — Sun, 27 Mar 2011 13:14:31 +0000

Here is a simple script you can use to check the last backup time for the mailbox databases on an Exchange Server. Run the script from the Exchange Management Shell on a Mailbox Server to check the local server’s databases.

[PS] C:\Scripts>.\check-dbbackups.ps1
Server: ESP-HO-EX2010B
Current time: 03/27/2011 22:21:39

Database                                Last Full (hrs ago)                     Last Inc (hrs ago)
--------                                -------------------                     ------------------
MB-HO-01                                1                                       n/a
MB-HO-02                                1                                       n/a
MB-HO-Archive-01                        n/a                                     n/a

Here is the script code.

$server = $env:computername

$now = [DateTime]::Now

"Server: " + $server
"Current time: " + $now

$db = get-MailboxDatabase -server $server -status
foreach ($objItem in $db)
{
$lastfull = $objItem.lastfullbackup
	if (!$lastfull)
	{
		$fullago = "n/a"
	}
	else
	{
		$fullago = $now - $lastfull
		$fullago = $fullago.TotalHours
		$fullago = "{0:N0}" -f $fullago
	}

	$lastinc = $objItem.lastincrementalbackup
	if (!$lastinc)
	{
		$incago = "n/a"
	}
	else
	{
		$incago = $now - $lastinc
		$incago = $incago.TotalHours
		$incago = "{0:N0}" -f $incago
	}

$returnedObj = new-object PSObject
$returnedObj | add-member NoteProperty -name "Database" -value $objItem.Name
$returnedObj | add-member NoteProperty -name "Last Full (hrs ago)" -value $fullago
$returnedObj | Add-Member NoteProperty -name "Last Inc (hrs ago)" -value $incago
$returnedObj
}

Get more Exchange Server tips at ExchangeServerPro.com

How to Schedule Windows Server Backup

Paul Cunningham — Sat, 18 Dec 2010 12:30:38 +0000

If you are using Windows Server Backup to backup Exchange Server 2010 then you will want to configure a scheduled back task to automate the process.

Windows Server Backup has scheduling capabilities built in. You can configure a scheduled backup job by clicking on Backup Schedule in the actions pane of the Windows Server Backup console.

Creating a scheduled backup in Windows Server Backup

However you might notice that the scheduling options are limited. You can either perform a daily backup, or more frequent backups, but not less frequent backups.

Windows Server Backup scheduling options

Why would you want to create less frequent scheduled backups of an Exchange server?

Two example scenarios are:

Reducing backups to run weekly because the data is already protected by a Database Availability Group
Running two different backup jobs on alternating days that backup to two different devices or locations

Fortunately you can schedule your Windows Server Backup jobs to run any time you like simply by creating the jobs manually in Task Scheduler.

Launch Task Scheduler by searching for it in the Start Menu of the server you wish to back up.

Launch Task Scheduler

In the Actions pane click on Create Task.

Create a new Scheduled Task

Give the new task a meaningful name, and then configure it to run whether the account is logged on or not. This allows it to run completely unattended.

Configure the scheduled task security options

On the Triggers tab click on the New button.

Create a new trigger for the scheduled task

The trigger for this task will be the schedule you want to run your backups on. In this example the Exchange server will be backed up weekly on Saturdays.

Create a schedule for the backup job

On the Actions tab click the New button.

Create a new Action for the scheduled task

The action for this scheduled task will be to run wbadmin.exe, which is the command-line tool for managing Windows Server Backup.

The full command being configured for the scheduled task is:

wbadmin start backup -backupTarget:F: -include:D:,E: -allCritical -vssfull -quiet

This command line performs the following:

start backup – tells wbadmin.exe to start a backup
-backupTarget – this is the target volume to store the backup on, in this case F: (no trailing backslash)
-include – these are the volumes to include in the backup job, in this case D: and E: because they are the volumes with Exchange databases and transaction logs on them
-allCritical – this tells Windows Server Backup to also include any other volumes or data that are required for a full server recovery, eg the System volume and SystemState. This is optional if you only want to backup the Exchange data.
-vssfull - this tells Windows Server Backup to perform a full VSS backup of Exchange and truncate the transaction logs
-quiet – runs the command silently with no visual interaction

Configure the wbadmin.exe command line

You can inspect the extra conditions and settings to see if you want to configure anything else for your environment.

The wbadmin command-line for the Exchange backup

Otherwise click OK. You will be prompted for the password for the user account you configured to run the scheduled task (note: I recommend you use a proper service account for this and not the Administrator account).

Enter the credentials for the scheduled task

The new scheduled backup job will now appear in Task Scheduler.

Exchange backup job in Task Scheduler

Task scheduler will also display the last run time and result for the scheduled task.

Get more Exchange Server tips at ExchangeServerPro.com

Commvault iDataAgent and Remote Public Folders

Paul Cunningham — Tue, 31 Aug 2010 12:02:04 +0000

There is a change in behaviour between Commvault version 7 and version 8 in the way that the Public Folder iData Agent handles public folders.

In Commvault version 7 the Public Folder iDataAgent will only back up content for local public folders. Any public folders for which there is no local replica on the Exchange server being backed up will not be included in the backup.

In Commvault version 8 the Public Folder iDataAgent will back up both local and remote public folders. This means that if the local public folder database has replicas for say 5Gb of the total 20Gb of data in that public folder hierarchy, it will back up the remaining 15Gb from a remote public folder database.

If the remote public folder database that it connects to is over a slow WAN connection then you run the risk of two undesirable outcomes:

WAN link saturation during the backup window
Very long running public folder backup jobs

There are three approaches that you could take to resolve this:

Replicate all public folder data to any server that is running Public Folder iDataAgent backup jobs. This may increase local storage requirements and WAN utilization caused by public folder replication (though you can optimize this in the public folder replication settings to suit your network).
Only run the Public Folder iDataAgent backup job at a central site that holds replicas for all public folders in the hierarchy. This is probably the least administrative effort. However it requires that any data restores also be run at that site and then replicated to the remote site that needs it, which potentially lengthens the total restoration timeframe.
Narrow the scope of the Public Folder iDataAgent backup job to only those folders in the hierarchy for which there are local replicas. This solves the problem now but could lead to new folders created later not being included in the backup scope.

Get more Exchange Server tips at ExchangeServerPro.com

Review of GFI Backup Business Edition

Paul Cunningham — Mon, 21 Jun 2010 13:09:36 +0000

GFI has recently released two backup products, a free one for home users and a paid product for business users. I downloaded and tested the Business Edition to see if it was as easy to install and use as they claim.

Installation

Installing GFI Business Edition was quite simple following an easy to understand setup wizard. I installed it on a virtualized server running Windows Server 2008 with Service Pack 2.

There are no complex set up requirements such as SQL databases to worry about. GFI Backup installs its own web server and listens on a custom port (you can change the port if you wish) for administration access, as well as ports for communications with remote agents.

Though I found this very easy to install I had to manually open firewall ports on the Windows Server 2008 server to allow remote administration access as they weren’t opened automatically by the installer as with some other applications.

Backing Up Files

Remote agent deployment can be performed using Group Policy or by manually initiating it from the remote server. There is no push option available to roll out remote agents.

The GPO deployment option would be suitable for deploying the remote agents to desktops and laptops but not as convenient for servers. For servers the manual agent deployment is best, though the most effort. If you want to save time you could script the server agent install but whether that saves you time will depend on the size of your environment and your scripting skills.

Backup types are file/folder, or SQL only. There is no option to backup Exchange Server or Active Directory. This would seem to be the greatest weakness of GFI Backup however for small businesses that run in a workgroup configuration without Active Directory, or have their email service hosted in the cloud these aren’t going to present a problem.

The default backup inclusions/exclusions that define a broad range of common productivity file types are useful especially when creating backup jobs for PCs.

The backup destination is quite flexible. Backing up to central location (can be disk or tape) on one main server is available, but each agent can also be configured to backup to its own local drive instead. This is again very useful for PC backups, as they can be configured to backup their most important user files to a second hard drive on the machine without consuming more expensive server disk or tape capacity.

The backup files themselves can optionally be compressed using ZIP compression. In my test this saved about 50% space for the Windows Server 2008 server. The ZIP files can also be password protected and AES encrypted.

Backups can be scheduled and include options for email notifications to backup administrators.

Restoring Files

There are two restore options driven by yet another simple wizard. You can restore either an entire system or perform item-level restores.

Unfortunately there is no bare metal restore capability, but with the speed of modern OS installations (ie Windows 2008 and Windows 7) and alternatives such as Windows Deployment Services it would still be feasible to quickly reinstall an operating system or SOE onto bare metal and then use GFI Backup to recover all of the user data for that system.

Overall Impression

GFI delivers on the ease of use promise with only a few trade offs. I found myself looking for the type of features and settings that I normally see in enterprise class backup products, but quickly realised that the ones that aren’t there are not really necessary for most small to medium businesses anyway.

The lack of support for Exchange and Active Directory backups makes GFI Backup less suited to Windows Small Business Server networks. Theoretically you could use pre and post tasks in GFI Backup to run scripted Windows Backups first, and then backup those files using GFI Backup but that adds a little too much complexity for my liking.

You could also use Windows Backup for those components and GFI Backup for everything else but again that detracts from the ease of use benefits of GFI Backup.

My only other complaint was the lightbox effect in the web administration console, which could perform poorly when remotely supporting clients over low bandwidth connections.

Overall I would consider GFI Backup Business Edition and good backup solution for the small or medium sized business that runs email and other applications in the cloud, and needs a simple backup solution for their Windows PC’s, file servers, and database servers.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Backups

How to Set Up an Automated Exchange 2010 Database Backup Alert Email

Script for Exchange Server 2010 Database Backup Email Alerts

Using Task Scheduler to Run PowerShell Scripts

Related posts:

Avoid Running Out of Transaction Log Disk Space on Exchange Servers

Related posts:

PowerShell Script: Check Exchange 2010 Database Backups

Related posts:

Exchange 2010: Are Passive Database Copies Included in Backups of DAG Members?

Related posts:

Review: Exchange Server 2010 Backup and Recovery Training

Exchange Server Backups – Serious Business

Exchange Server 2010 Backup and Recovery Training

What You Get with TrainSignal’s Exchange Server 2010 Backup and Recovery Training

Related posts:

Exchange 2010 FAQ: Why is My Disk Filling Up with Log Files?

Related posts:

PowerShell Script: Check Exchange Mailbox Database Last Backup Time

Related posts:

How to Schedule Windows Server Backup

Related posts:

Commvault iDataAgent and Remote Public Folders

Related posts:

Review of GFI Backup Business Edition

Installation

Backing Up Files

Restoring Files

Overall Impression

Related posts: