SQL Server 2012 : Backup and Recovery Planning - Recovery Models (part 2) - Simple Recovery Model, The Full Recovery Model

Simple Recovery Model

The simple recovery model is suitable for databases that require that each transaction be atomic but not necessarily durable. The simple recovery model directs SQL Server to truncate, or empty, the transaction log on checkpoints. The transaction log keeps a transaction until it is confirmed in the data file, but after that point the space may be reused by another transaction in a round-robin style. This is the reason why a simple recovery model does not support a transaction log backup.

A simple recovery model has the benefit of keeping the transaction log small, at the cost of potentially losing all transactions since the last full or differential backup.

A recovery plan based on a simple recovery model might include performing full backups once a week and differential backups every weeknight, as shown in Figure 1. The full backup copies the entire database, and the differential backup copies all changes that have been made since the last full backup.

Figure 1 A typical recovery plan using the simple recovery model includes only full and differential backups.

When restoring from a simple recovery plan:

The Full Recovery Model

The full recovery model offers the most robust recovery plan. Under this model all transactions, including bulk-logged operations, are fully logged in the transaction log. Even system functions such as index creation are fully logged. The primary benefit of this model is that every committed transaction in the database can be restored right up to the point when failure occurred.

The trade-off for this high level of transactional integrity is a certain amount of performance:

• Bulk-logged and select-into operations will be slower. If the database doesn't import data using these methods, this is a moot point.
• Depending on the database activities, the transaction log may be huge. You can control this by performing regularly scheduled transaction log backups. Also, if copious drive space is available, this too is a moot point.
• Backing up and restoring the transaction log can take longer than it does with the other recovery models. However, in a crisis, restoring all the data is likely more important than quickly restoring partial data.

The full recovery model can use all types of database backups. Figure 2 shows a typical backup schedule.

Figure 2 A sample recovery plan using the full recovery model, using full, differential, and transaction-log backups.

A sample full-recovery backup plan typically does a full database backup once or twice a week and differential backups every day or every other night. The transaction log is backed up throughout the day, from as little as two times a day to as often as every 15 minutes. Or you could do a daily full backup, with a differential backup every 6 hours and transaction log backups every 2 hours in between. The frequency of the transaction log backup is based around the maximum amount of acceptable data loss. For example, perform a transaction log backup every 15 minutes if you can afford to lose up to 15 minutes of data. You can mix and match options that make the most sense for your databases, your environment, and most importantly your resources (i.e. storage available for backup purposes).

To restore from the full-recovery model, do the following: