Buenas prácticas de respaldo y recuperación de datos en SQL Server

Acorte la duración del backup de datos

Si el rendimiento global se está resintiendo debido a la duración de los backups, se pueden hacer varios backups cortos para abreviar la duración total del tiempo dedicado al backup. Una manera de acortar los backups consiste en utilizar la compresión de datos de backup. Otra forma de abreviar la duración del backup consiste en hacer la copia de seguridad de la base de datos en un disco. Ahora bien, si se hace backup en un disco, no hay que hacerlo en el mismo disco utilizado para guardar la base de datos o el registro de transacciones. De lo contrario, no sólo se merma el rendimiento, sino que también puede afectar a la posibilidad de recuperación de la información en caso de fallo del disco.

Métodos de backup combinados

SQL Server ofrece tres métodos de backup básicos: completo, diferencial y de transacciones. Son opciones de backup incorporadas en el propio SQL Server, por lo que no es necesaria una aplicación de backup independiente. Un backup completo realiza una copia de seguridad de todo. Es el más largo, el que más tarda y el que más recursos utiliza. Un backup diferencial sólo copia lo que ha cambiado desde el último backup completo. Esto hace que los backups sean más rápidos, pero las restauraciones son más lentas, puesto que es necesario reconstruir la base de datos. Un backup del registro de transacciones sólo copia el registro de transacciones desde el backup anterior del mismo. Es muy rápido, pero la reconstrucción de una base de datos a partir de una cadena de backups de registros de transacciones es el más lento de los métodos de restauración.

Además de estos tres métodos de backup de toda la base de datos; SQL Server también permite backup individualmente archivos o grupos de archivos, lo cual puede resultar útil para proteger archivos importantes o para hacer backups de  bases de datos muy grandes.

La selección del método de backup más adecuado para cada organización depende de la índole de la base de datos que se desea proteger, y concretamente de la frecuencia con la que cambia, de su tamaño, y de su importancia para la entidad. Algunas bases de datos no son muy grandes y cambian con relativamente poca frecuencia. Se pueden proteger mediante backups completos realizados diariamente o a intervalos semanales. Otras, en especial las bases de datos de transacciones críticas, son objeto de backup completo con la mayor frecuencia viable.

Hacer backup con frecuencia del registro de transacciones

Aparte de la propia base de datos, el registro de transacciones contiene los datos más críticos de una base de datos SQL Server. El registro de transacciones recoge toda la actividad y se puede utilizar para realizar restauraciones hasta un momento determinado (point-in-time, PIT). La ventaja del registro de transacciones es que se puede hacer backup con frecuencia, manteniéndolo muy actualizado. También dispone de backups PIT o casi PIT, entre otras más convencionales. Hay que señalar que un backup de transacciones sólo copia hasta el anterior backup de transacciones. Eso significa que para conseguir una restauración completa, hay que restaurar una secuencia de backups de transacciones. La fuerza del backup de un registro de transacciones reside en su capacidad de restaurar hasta el minuto anterior, o casi.

El registro de transacciones se debería hacer backup varias veces al día. Muchas organizaciones que utilizan una base de datos activa, como una base de datos de transacciones, le hacen backup  cada 10 minutos más o menos.

Hacer backup de bases de datos del sistema SQL Server

El otro componente vital de una aplicación SQL son las bases de datos del sistema, entre ellas msdb y master. Contienen información vital, como la configuración del sistema, y son necesarias en caso de restauración completa. Cambian con menor frecuencia y se deberían de hacer backup  al menos una vez por semana, o a diario si se trata de un entorno activo (donde las transacciones de datos son frecuentes): En el caso de las bases de datos master, hay que realizar backups al menos cada vez que se produce un cambio en los ajustes a nivel de configuración del servidor o de la base de datos, o si se introduce cualquier cambio en los detalles de las cuentas de inicio. Se puede copiar las bases de datos del sistema mientras se está ejecutando la aplicación.

Hacer backup de  la partición del sistema al menos cada vez que se modifique la configuración

Técnicamente, la partición del sistema no forma parte de SQL Server, pero una partición del sistema sin hacer backup puede dificultar la recuperación de la base de datos. Es importante mantener un backup  actualizado de la partición del sistema, lo cual significa que hay que hacer backup al menos cada vez que se introduzca un cambio en la configuración del sistema; los backup periódicos son aún mejores.

Garantice la seguridad de la base de datos

Cerciórese de que su base de datos está bien protegida. Por ejemplo, cuando utilice el sistema de archivos para realizar backups, sólo debe permitir que accedan las carpetas y archivos la cuenta de servicio de SQL y el administrador de la base de datos.

En la orden de backup no utilice la opción de contraseña para proteger con ella el backup. Ha sido objeto de críticas y está previsto que desaparezca en las versiones futuras de SQL Server.

Cuando realice backups, utilice la opción de suma de comprobación de la orden de backup y compruebe periódicamente sus backups mediante la orden Comprobar solamente la restauración.

Por último, cerciórese de que sus parches de seguridad estén actualizados y correctamente instalados – no sólo en el servidor SQL, sino también en el hardware y el sistema operativo que lo sustentan.

Sobre el autor: Rick Cook está especializado en temas relacionados con el almacenamiento y la administración del almacenamiento.