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.
Multiple Backup Applications
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.
- The best solution is to pick one backup application, and use only that application.
- If multiple backup applications must be used, configure both to take only Full backups.