Most modern databases, including (but not limited to) Microsoft SQL Server and Exchange, operate under the transaction log model. Information that needs to be added to a database is first written to a file called a transaction log. Later, during a backup, the contents of that transaction log are written to the database. The process of writing the transaction logs to the database is known as purging, truncating, or committing, depending on which database is in question.
The transaction log model allows users to continue to access the database during backups. If data were written directly to the database, the administrator would have to close the database before it could be backed up. The database would be unavailable to users during that period of time.
Transaction logs are the cornerstone of VSS-based backup processes, including those used by ZCB.
The use of multiple backup applications on the same database will usually cause Differential and Incremental backups to fail for one or more of the backup applications.
In some cases, the backups will not fail but the incremental/differential backups will not be restorable.
Differential and Incremental backups require a linear, uninterrupted chain of events–which includes the transaction logs. If the transaction logs have been purged by a different application, this linear chain of events is broken. The backup application cannot pick up where it left off, and the backup usually fails.
If your Differential and/or Incremental backups are failing due to the use of multiple backup applications, you must take a new Full Backup before Differentials and/or Incrementals will function again.
If you are backing up Exchange in the above scenario, you must also restart the Microsoft Exchange Information Store service before taking the new Full Backup.