Microsoft Database Applications and Multiple Backup Sources

For the purposes of this article, a backup source is any application or process that uses the Volume Shadowcopy Services (VSS) to interface with a database application in order to obtain a backup copy of data in the database.

The process must do all of those things to count as a backup source. For example, copying the files on disk does not count as a backup source. Even a VSS-based file-level backup of the database files on disk is not a backup source, because it did not interface with the database application.

It is very risky to back up the same database with multiple backup sources. It is safe to use multiple backup sources if all of the backup sources use full backups only.

The risk is great when there are multiple backup sources, if there are incremental and/or differential backups involved. Incremental and differential backups will usually fail if there is more than one backup source acting on any given database. Worse, sometimes the backups do not fail, but cannot be restored by any means!

In most cases, the second backup source damages the first backup source's ability to take good incremental or differential backups, but the effect is cyclical. If you fix the first backup source you are likely breaking the second source! Then, when you fix the second source, you break the first source again.

The exact behavior depends on which database application is being backed up, the configuration of the databases within the application, which version of the database application is in use, and what method the backup sources use to perform backups.

It is only safe to use multiple backup sources when all of the backup sources are using full backups. If any backup source is running incremental or differential backups, there is a risk of data loss as described below.

Microsoft Exchange Backups:

For Exchange, incremental and/or differential backups usually start to fail after the second backup source completes a backup.

When this happens, the Exchange VSS Writer will go into a failed state. With CSSB, all future backups will fail until you restart the Microsoft Exchange Information Service (MEIS) and take a new full backup. Simply restarting MEIS is not enough to resume your incremental and/or differential backups.

In certain rare cases, the incremental and/or differential backups will not fail and the Exchange Writer will not go into a failed state. However, incremental/differential backups after the second backup source completed its backup cannot be restored!

Microsoft SQL Server and SharePoint Backups:

Much like Exchange, the incremental and/or differential backups usually start to fail after the second backup sources completes a backup. If incremental and/or differential backups begin to fail due to the presence of another backup source, future backups will fail until you take a new full backup.

Unlike Exchange, the VSS Writers usually do not go into a failed state, and there is no service to restart before you can take a new full backup.

Just like Exchange, there are times where the incremental and/or differential backups do not fail. Incremental/differential backups taken after the second backup source completed a backup cannot be restored!

This second scenario, where the incremental/differential backups complete but cannot be restored, is far more likely for SQL Server and SharePoint than for Exchange. Older versions of SQL Server and SharePoint are more likely to experience this behavior than newer versions.

It is never safe to use multiple backup sources when incremental or differential backups are involved. The backup sources do not have to run at the same time. The second backup simply has to complete successfully to damage the first backup source's ability to take incremental and/or differential backups.

It is safe to use multiple backup sources if all backup sources are doing full backups without incremental or differential backups.

Usually, the system administrator or database administrator keeps track of when backups occur and what applications are performing those backups. If you're not the admin, the first step is to speak to the admin! If you are the admin, you must investigate further.

The Windows Application Event Log is the easiest place to spot another backup source. All three Microsoft databases log events in the Application event log when they are backed up.

The event number may vary based on the version of the database application. These events usually contain the word backup or backed up, and can be found easily by searching.

CSSB logs its own events (Event IDs 501, 502, and 503), and you can safely ignore those on your search.

When you find a backup event for your database, check the time that it occurred. Was Carbonite Safe Server Backup running a backup of your database at that time? If not, something else must have performed a backup of the database!

Below, you'll find a partial list of known backup sources. Please note that it is impossible to list every possible backup source. This list is intended only as a point of reference.

It is also the responsibility of the system's administrator to make sure that their databases are backed up properly. This includes ensuring that each database is backed up by only one source.

Some backup sets in Carbonite Safe Server Backup act as a backup source

Many backup types in Carbonite Safe Server Backup act as a backup source for their respective databases.

• Microsoft SQL Server backup sets act as a backup source for Microsoft SQL Server and Microsoft SharePoint databases.
  • All SharePoint installations include a Microsoft SQL Server component, which can (but should not) be selected for backup in a Microsoft SQL Server backup set.
• Microsoft Exchange Database backup sets act as a backup source for Microsoft Exchange.
  • However, Exchange Local Mailbox and Exchange Online Mailbox backup sets are not a backup source.
• Microsoft SharePoint backup sets act as a backup source for Microsoft SharePoint databases.
• Hyper-V backup sets can act as a backup source for any of the Microsoft databases within guest VMs, if any of those databases are installed on a VM selected for backup.
  • The Child Snapshot method of backup interfaces with VSS on the guest VM in order to obtain a backup copy of data in the database. Please see our User Guide for more information on the Child Snapshot method of backup.
  • This means you should take care if you plan to back up a VM from both the host and from within the VM itself.

All other backup sets, including File System and Bare Metal Image backup sets, do not count as a backup source for the Microsoft databases. There is no need to exclude your databases from these backup sets.

Built-in backup processes and applications can act as a backup source

Here are some examples of backup sources that can come with Windows or with the database application itself:

• Windows Server Backup
• Windows NTBackup
• Scheduled backup jobs within the SQL Server Management Studio
• Applications that have an embedded database often include some form of built-in backup function.
  • It varies by application, but this built-in backup can act as a backup source.

Full-system imaging applications often act as a backup source

Full-system imaging backup applications often interface with VSS in order to obtain a backup copy of data in any or all databases on the system.

Likewise, a virtual machine host may have an application that backs up guest VMs. These applications often interface with VSS within the guest VMs to obtain a backup copy of data in any or all databases on the system.

CSSB's own Bare Metal Image backup type does not act as a backup source. However, Hyper-V backup sets often do. Remember, any application that interfaces with VSS in order to obtain a backup copy of data in a database counts as a backup source.

Other products that provide full system imaging or virtual machine backup may act as a backup source. Please refer to the product's documentation.