Antes de entrar en detalle sobre los diferentes Modelos de Recuperación de bases de datos en SQL Server, repasemos qué es el Modelo de Recuperación.

«A recovery model is a database property that controls how transactions are logged, whether the transaction log requires (and allows) backing up, and what kinds of restore operations are available.» MSDN

«Un modelo de recuperación es una propiedad de la base de datos que controla cómo se registran las transacciones, si el registro de transacciones requiere (y permite) copia de seguridad, y qué tipos de operaciones de restauración están disponibles».

Es decir, el recovery model determina el mantenimiento del registro de transacciones, y las opciones a la hora de hacer copias de seguridad, backups, y restaurar una base de datos.

Otro concepto importante a entender antes de continuar, es el del registro de transacciones, o transaction log. Toda base de datos SQL Server tiene un registro de transacciones que guarda todas las transacciones y las modificaciones hechas en la base de datos por cada una de las transacciones.

Ahora veamos qué Recovery Models tenemos en SQL Server:

• Simple Recovery Model, en castellano, modo de recuperación simple.
• Full Recovery Model, o modo de recuperación completa.
• Bulk Logged Model, o modo de registro de operaciones masivas.

En este artículo, nos centramos en el primero, y a continuación vemos sus características más destacadas:

1. Elimina la necesidad de gestionar el transaction log. Se reclama automáticamente el espacio del transaction log, para mantenerlo tan reducido como sea posible. Se simplifica parte del mantenimiento.
2. Consecuencia de lo anterior, es que no es posible hacer copias de seguridad del transaction log.
3. Tampoco es posible el uso de las siguientes funcionalidades, ya que se apoyan en el registro de transacciones:
   • Log Shipping, mecanismo de sincronización con otros servidores de SQL Server, típicamente usado como solución económica y sencilla para Disaster Recovery.
   • Opciones de alta disponibilidad, como DB Mirroring, o Always On.
   • Change Data Capture.
4. No se pueden hacer recuperaciones de la base de datos en un punto determinado en el tiempo (PITR). Tampoco se pueden hacer recuperaciones sin perdida de datos.

Ejemplo de escenario de desastre y perdida de datos posible usando Simple Recovery Model. Fuente

5. Permite hacer differentials backups. Estos backups solo contienen las modificaciones hechas en la base de datos desde el full backup más reciente. Son más rápidos y de menor tamaño que un full backup. Este tipo de backups también es posible en los otros modelos de recuperación.

Llegados a este punto, nos podemos preguntar ¿En qué casos podemos configurar una base de datos con Simple Recovery Model ? La respuesta es sencilla: aquellos casos en los que las desventajas no importen. Algunos casos típicos:

• Bases de datos con contenido estático o semi estático, cuyo contenido cambia con muy poca frecuencia.
• Cuando no hay objetivos de recuperación exigentes, siempre que sea aceptable una posible pérdida de datos si un desastre ocurriera.
• Cuando no se requiera de alta disponibilidad. Esto es que haya otra instancia de la base de datos sincronizada en tiempo real.
• Cuando la información es temporal y/o se pueda regenerar los datos facilmente.
• Etc.

Para finalizar, espero que haya sido aclaratorio el artículo y que el lector tenga una mejor idea sobre esta opción para cualquier base de datos en SQL Server. En futuros articulos 101 de SQL Server, revisaremos los otros modelos de recuperación.

¡Hasta la próxima!