Selecting a Recovery Model
Microsoft® SQL Server™ provides three recovery models to:
- Simplify recovery planning.
- Simplify backup and recovery procedures.
- Clarify tradeoffs between system operational requirements.
These models each address 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:
- Performance of large-scale operation (for example, index creation or bulk loads).
- Data loss exposure (for example, the loss of committed transactions).
- Transaction log space consumption.
- Simplicity of backup and recovery procedures.
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 model | Benefits |
Work loss exposure |
Recover to point in time? |
|---|---|---|---|
| Simple | 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. |
| Full | 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. |
| Bulk-Logged | 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. |
When a database is created, it has the same recovery model as the model database. To alter the default recovery model, use ALTER DATABASE to change the recovery model of the model database. You set the recovery model with the RECOVERY clause of the ALTER DATABASE statement. For more information, see ALTER DATABASE.
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.
Important Simple Recovery is not an appropriate choice for production systems where 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 amounts of data.
For more information, see Simple Recovery.
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. For more information, see Full Recovery.
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. For more information, see Bulk-Logged Recovery.
Because many databases undergo periods of bulk loading or index creation, you may want to switch between Bulk-Logged and Full Recovery models. For more information, see Switching Recovery Models.