The main purpose of backing up the Verba database is to provide increased reliability and system recovery (fault tolerance) of the system. In case of a media or database failure, data can be restored from earlier database backups.

It is important to note, that the Verba media files (recordings) are stored in the file system, and backing up the database does not provide fault tolerance for the media files. Verba administrators have to choose another method to backup media files regularly to provide the reliability of the system. The Verba media file backup procedures have to be synchronized with the Verba database backup in order to provide the ability to restore a consistent Verba system in case of a failure.

Microsoft SQL Server provides high-performance backup and restore capabilities. The SQL Server backup and restore component provides an essential safeguard for protecting critical data stored in SQL Server databases. Implementing a well-planned backup and restore strategy helps protect databases against data loss because of damage caused by a variety of failures. Testing your strategy by restoring a set of backups and recovering your database prepares you to respond effectively to a disaster.

The following topics provide a brief explanation of the most important backup topics.

For detailed information about SQL Server backup and restore features, refer to https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases.

This page has the following content:

For further information:

Selecting a recovery model

SQL Server provides three recovery models to:

Each of these models addresses different needs for performance, disk and tape space, and protection against data loss.  For example, when you choose a recovery model, you must consider the tradeoffs between the following business requirements:

Depending on what operations you are performing, more than one model may be appropriate. After you have chosen a recovery model or models, plan the required backup and recovery procedures.

This table provides an overview of the benefits and implications of the three recovery models.

Recovery models comparison table

Recovery model


Work loss exposure

Recover to point in time?


Permits high-performance bulk copy operations.

Reclaims log space to keep space requirements small.

Changes since the most recent database or differential backup must be redone.

Can recover to the end of any backup. Then changes must be redone.


No work is lost due to a lost or damaged data file.

Can recover to an arbitrary point in time (for example, prior to application or user error).

Normally none.

If the log is damaged, changes since the most recent log backup must be redone.

Can recover to any point in time.


Permits high-performance bulk copy operations.

Minimal log space is used by bulk operations.

If the log is damaged, or bulk operations occurred since the most recent log backup, changes since that last backup must be redone.

Otherwise, no work is lost.

Can recover to the end of any backup. Then changes must be redone.

Simple Recovery

Simple Recovery requires the least administration. In the Simple Recovery model, data is recoverable only to the most recent full database or differential backup. Transaction log backups are not used and minimal transaction log space is used. After the log space is no longer needed for recovery from server failure, it is reused.

The Simple Recovery model is easier to manage than the Full or Bulk-Logged models, but at the expense of higher data loss exposure if a data file is damaged.

Simple Recovery is not an appropriate choice for production systems where the loss of recent changes is unacceptable.

When using Simple Recovery, the backup interval should be long enough to keep the backup overhead from affecting production work, yet short enough to prevent the loss of significant amount of data.

The backup strategy for simple recovery consists of:

To recover in the event of media failure:

Full and Bulk-Logged Recovery

Full Recovery and Bulk-Logged Recovery models provide the greatest protection for data. These models rely on the transaction log to provide full recoverability and to prevent work loss in the broadest range of failure scenarios. The Full Recovery model provides the most flexibility for recovering databases to an earlier point in time.

The Bulk-Logged model provides higher performance and lower log space consumption for certain large-scale operations (for example, create index or bulk copy). It does this at the expense of some flexibility of point-in-time recovery.

The backup strategy for full recovery consists of:

Full and bulk-logged recovery are similar and many users of the Full Recovery model will use the Bulk-Logged model on occasion.

You can restore a database to the state it was in at the point of failure if the current transaction log file for the database is available and undamaged.

To restore the database to the point of failure:

The backup strategy for bulk-logged recovery consists of:

Backing up a log that contains bulk-logged operations requires access to all data files in the database. If the data files are not accessible, the final transaction log cannot be backed up and all committed operations in that log will be lost.

To recover in the event of media failure:

Database backups

Full database backups

A database backup creates a duplicate of the data that is in the database when the backup completes. This is a single operation, usually scheduled at regular intervals. Database backups are self-contained.

You can re-create the entire database from a database backup in one step by restoring the database. The restore process overwrites the existing database or creates the database if it does not exist. The restored database will match the state of the database at the time the backup completed, minus any uncommitted transactions. Uncommitted transactions are rolled back when the database is recovered.

A database backup uses more storage space per backup than transaction log and differential database backups. Consequently, database backups need more time to complete the backup operation and so are typically created less frequently than a differential database or transaction log backups.

Differential database backups

A differential database backup records only the data that has changed since the last database backup. You can make more frequent backups because differential database backups are smaller and faster than database backups. Making frequent backups decreases your risk of losing data.

If you have created any file backups since the last full database backup, those files will be scanned by SQL Server at the beginning of a differential database backup. This may cause some degradation of performance in the differential database backup.

You use differential database backups to restore the database to the point at which the differential database backup was completed. To recover to the exact point of failure, you must use transaction log backups.

Consider using differential database backups when:

A recommended process for implementing differential database backups is:

The sequence for restoring differential database backups is: