En el mundo de las bases de datos es bien conocido que las copias de seguridad son claves para garantizar la integridad continuada de cualquier sistema. Debido a sus características esto es incluso más cierto cuando nos referimos a una instancia SQL Server.
Antes de entrar en detalles técnicos es importante tener un conocimiento mínimo de algunos términos que iremos utilizando a lo largo de este artículo, tales como el tipo de copias de seguridad.
Tipos de copias de seguridad en SQL Server
Los 3 principales tipos de copias de seguridad en SQL Server son:
Copia de seguridad completa:
Una copia de seguridad completa contiene todos los datos de una base de datos, así como el registro suficiente para permitir la recuperación de los datos. Sus principales inconvenientes son su tamaño y el tiempo que pueden tardar en completarse, pero es la base de los otros dos tipos de copias de seguridad.
Copia de seguridad diferencial:
Como hemos mencionado antes una copia de seguridad diferencial requiere de la existencia de una copia de seguridad completa pues se basa en ella a la hora de almacenar los cambios que se hayan podido producir en la base de datos en el tiempo que haya pasado desde esa última. Su ventaja es que ocupan menos espacio y son más rápidas de hacer.
Copia de seguridad del registro de transacciones:
El registro de transacciones contiene todas las transacciones que se han realizado sobre una base de datos desde la última copia de seguridad del propio registro. De este modo podemos reconstruir todas las operaciones realizadas sobre dicha base de datos simplemente restaurando una cadena ininterrumpida de copias de seguridad. Al igual que con la copia diferencial es necesario disponer de una copia completa antes de poder realizar una copia del registro de transacciones.
En este enlace puedes consultar la documentación de Microsoft: Backup Overview (SQL Server) – SQL Server | Microsoft Learn
Aplicaciones prácticas de copias de seguridad en SQL Server
Una vez aclarados los conceptos más básicos podemos empezar a pensar en lo que significan y cómo afectan a nuestro sistema. Pongamos una situación donde nuestras bases de datos están configuradas en modo de recuperación simple y solo hacemos una copia de seguridad completa cada semana. De corromperse la base de datos podríamos perder TODOS los cambios que se hayan generado sobre esa base de datos desde la última copia de seguridad, lo que supondría en este caso hasta una semana de datos.
¿Y si resulta que tenemos las bases de datos configuradas en modo de recuperación completo y las copias de seguridad del registro de transacciones se hacen cada hora? Pues en ese caso perderíamos hasta un máximo de 1 hora de datos. Pero tener que realizar la restauración de más de 150 copias de seguridad (copia completa + registro de transacciones) no suena muy apetecible.
¿Y si al final resulta que tenemos además copias de seguridad diferenciales haciéndose cada 24 horas? Pues nos arriesgamos a perder lo mismo que en la situación anterior, pero la restauración sería más llevadera con 1 copia de seguridad completa, 6 diferenciales y las de registro de transacciones que se hubiesen producido hasta el momento del fallo en la base de datos. Bastante más asequible, ¿verdad?
¿Cómo decidir cuáles son las mejores opciones?
Como hemos podido ver la elección del tipo y frecuencia de las copias de seguridad en SQL es crítica a la hora de mantener la integridad de nuestro sistema gestor de bases de datos. ¿Pero cómo decidimos qué tipos de copias de seguridad utilizar? ¿Por qué configurarlas con esa frecuencia?
Estas preguntan se responden en función de nuestras necesidades y capacidades. ¿Cuál es nuestra ventana de mantenimiento? ¿Qué necesidad de recuperación tenemos?
Pongamos un par de situaciones hipotéticas. En el caso A tenemos una instancia con mucha carga transaccional, pero las bases de datos son de tamaño medio/pequeño ya que no tenemos que guardar muchos datos históricos. Dicha transaccionalidad se produce en su mayor parte de 6 a 22.
Caso B. Tenemos una instancia de tipo “almacén de datos” lo que supone que tenemos bases de datos de gran tamaño, pero la carga transaccional es limitada. Así mismo dicha carga disminuye hasta quedar en casi nada a partir de las 20 y no se reanuda hasta las 9.
En el caso A y dado que las bases de datos son de tamaño intermedio/reducido y disponemos de una ventaja de mantenimiento de unas 8 horas podríamos permitirnos prescindir de copias diferenciales y realizar completas a diario. Por otra parte dada la alta transaccionalidad que sufrimos convendría que las copias de registro transaccional tuviesen una alta frecuencia, quizás de 15 a 30 minutos.
En el caso B, considerando que tenemos unas bases de datos de gran tamaño nos beneficiaríamos de establecer una copia de seguridad completa semanal, apoyada de una diferencial diaria. En cuanto a las copias de del registro de transacciones podríamos permitirnos que fuesen de 1 o 2 horas debido a la baja transaccionalidad.
Obviamente estos casos son bastante simples y es muy posible encontrar situaciones mixtas que requieren análisis y soluciones más complejas, pero eso es algo que ya se irá viendo.
Desde Verne Tech podemos ayudarte con tus copias de seguridad en SQL Server.
Habla con uno de nuestros técnicos y cuéntanos las necesidades de tu empresa.
Conclusiones
Ahora hemos obtenido los conocimientos básicos para comprender qué es una copia de seguridad, los tipos más habituales que podemos encontrar en SQL Server, así como su importancia y qué factores debemos tener en cuenta a la hora de configurarlos.
En futuros artículos entraremos en detalles más técnicos como formas de restaurar las copias de seguridad si algún día ocurre el desastre:
- Recuperación de bases de datos tras pérdidas de ficheros.
- Recuperación de bases de datos tras corrupción de datos.
