Internet, Networking, & Security Web Development SQL Server Recovery Models Recovery models balance disk space against complete log files by Mike Chapple Writer Former Lifewire writer Mike Chapple is an IT professional with more than 10 years' experience cybersecurity and extensive knowledge of SQL and database management. our editorial process Twitter Mike Chapple Updated on July 16, 2019 Thomas Barwick / Getty Images Web Development SQL CSS & HTML Web Design Tweet Share Email SQL Server provides three recovery models that allow you to specify the way SQL Server manages log files and prepares your database for recovery after a data loss or other disaster. Each of these represents a different approach to balancing the tradeoff between conserving disk space and providing for granular disaster recovery options. The three disaster recovery models offered by SQL Server are: SimpleFullBulk-logged Let's take a look at each of those models in further detail. Simple Recovery Model The simple recovery model is just that: simple. In this approach, SQL Server maintains only a minimal amount of information in the transaction log. SQL Server truncates the transaction log each time the database reaches a transaction checkpoint, leaving no log entries for disaster recovery purposes.For databases using the simple recovery model, you can restore full or differential backups only. It is not possible to restore such a database to a given point in time — you can only restore it to the exact time when a full or differential backup occurred. Therefore, you will automatically lose any data modifications made between the time of the most recent full/differential backup and the time of the failure. Full Recovery Model The full recovery model also bears a self-descriptive name. With this model, SQL Server preserves the transaction log until you back it up. This allows you to design a disaster recovery plan that includes a combination of full and differential database backups in conjunction with transaction log backups.In the event of a database failure, you have the most flexibility restoring databases using the full recovery model. In addition to preserving data modifications stored in the transaction log, the full recovery model allows you to restore a database to a specific point in time. For example, if an erroneous modification corrupted your data at 2:36 a.m. on Monday, you could use SQL Server’s point-in-time restore to roll your database back to 2:35 a.m., wiping out the effects of the error. Bulk-logged Recovery Model The bulk-logged recovery model is a special-purpose model that works in a similar manner to the full recovery model. The only difference is in the way it handles bulk data modification operations. The bulk-logged model records these operations in the transaction log using a technique known as minimal logging. This saves significantly on processing time but prevents you from using the point-in-time restore option.Microsoft recommends that the bulk-logged recovery model be used only for short periods of time. Best practice dictates that you switch a database to the bulk-logged recovery model immediately before conducting bulk operations and restore it to the full recovery model when those operations complete. Changing Recovery Models Use SQL Server Management Studio to view or change the recovery model: Choose the relevant server — Connect to the relevant instance of the SQL Server Database Engine, then in Object Explorer, click the server name to expand the server tree.Select the database — Expand Databases, and, depending on the database, either select a user database or expand System Databases and select a system database.Open the Database Properties — Right-click the database, and then click Properties, to open the Database Properties dialog box.View the current Recovery Model — In the Select a page pane, click Options to view the current Recovery model selection.Select the new Recovery Model — Select either Full, Bulk-logged, or Simple.Click OK.