En este post, veremos los modelos de backup y restauración que dispone un entorno Azure SQL Database para la recuperación de datos. Azure SQL Database como servicio autogestionado, nos facilita las tareas relacionadas en este tipo de procesos, desde la definición de una política de backup robusta hasta una restauración segura con posibilidad de mantener una retención de hasta 10 años.
¡Comenzamos!
En el post que se desarrolla a continuación, tratamos de analizar las opciones que disponen los recursos Azure SQL Database para la salvaguarda y recuperación de datos. Al ser un servicio autogestionado, Azure SQL Database facilita las tareas de backup y recuperación llegando a cubrir todas las necesidades de cualquier organización.
En este post veremos con ejemplos reales, los modelos de backup existentes y las opciones de restauración para la recuperación de los datos, a partir de dichos backups.
También veremos la opción de recuperación de datos a partir del modelos export/import Data-tier Application desde SSMS. Esta opción nos puede ser útil para recuperar una base de datos en escenarios de depuración de incidencias, por ejemplo.
¡Vamos allá!
Antes de adentrarnos en el detalle de la gestión de backups, veamos, de forma resumida, las propiedades de este tipo de recursos.
Azure SQL Database es un servicio de base de datos relacional totalmente gestionado incluida en la oferta de servicios de Microsoft Azure y diseñado para manejar una amplia gama de necesidades de bases de datos. Ofrece los siguientes beneficios:
- Escalabilidad y rendimiento
- Pools Elásticos: Conjunto de recursos agrupados, compartidos por varias bases de datos y que permiten la asignación dinámica de los recursos del pool en función d la carga de cada base de datos.
- Hyperscale: Soporta un alto rendimiento para bases de datos grandes, escalando hasta 100 TB.
- Niveles de computación provisioned (rendimiento y coste predecibles) y serverless (modelo con recursos no provisionados que escalan automáticamente según la demanda de la carga de trabajo y pago por el uso de computación por segundo)
- Automatización de backups
- Copias de Seguridad Automáticas: Dispone de dos paradigmas PITR (point-in-time recovery y LTR (Long-term retention).
Backups en entorno Azure SQL Database
En Azure SQL Database, las copias de seguridad (backups) son una parte fundamental del servicio gestionado. Estas copias de seguridad se realizan automáticamente para asegurar la protección de los datos y permitir la recuperación en caso de pérdida o corrupción de datos.
Tipos de backup PITR (point-in-time-recovery) y LTR (Long-term retention)
A la hora Configurar los backup automatizados de una Azure SQL Database, es importante hacer la distinción entre backups PITR y LTR.
Backups PITR
Los backups PITR permiten la recuperación de datos de forma flexible, manteniendo la integridad de los datos con posibilidad de restablecer los datos contenidos en un momento temporal.
En cuanto a la retención los backups PITR se conservan por un período predeterminado (7 a 35 días).
Backups LTR
Las copias de seguridad a largo plazo (LTR) en Azure SQL Database es la solución en Azure SQL Databases para el almacenamiento y la recuperación de datos a largo plazo (semanales, mensuales o anuales hasta 10 años de retención) permitiendo el cumplimiento de las políticas de retención de datos.
Restauración de bases de datos en entornos Azure SQL Database
Tras describir las opciones disponibles para definir políticas de backups en el apartado anterior, a continuación se abordan las distintas opciones de restauración que nos permite un recurso Azure SQL Database.
Restauración de backups desde el portal de Azure
En este apartado de abordarán las distintas opciones de restauración y recuperación de datos disponibles para los entornos Azure SQL Database:
- PITR
- LTR
- BACPAC
PITR
LTR
BACPAC
Para estos ejemplos, se configuran las directivas de backup que se muestran a continuación:
Con la configuración de backup que se muestra en las ilustraciones anteriores, podemos restaurar la base de datos ‘adventuredworks’ a cualquier punto en el tiempo de los últimos 7 días, teniendo en cuenta que se realizan backup diferenciales cada 12 horas.
Téngase en cuenta que las directivas de backup se configuran por cada base de datos. En el ejemplo partimos de la base de datos ‘Adventuredworks’, que se encuentra creada y con datos precargados.
Restauración en una nueva base de datos
En base a las directivas de backup mostradas en el apartado anterior, procedemos a restaurar la base de datos ‘adventuredworks’ en la base de datos ‘adventuredowrks_2024-05.28T13-00Z’ en es estaba en el que se encontraba el 28/05/2024 a las 13:00UTC.
Para restaurar vamos, desde el servidor a la base de datos que queremos restaurar, que en nuestro caso es ‘adventuredworks’.
Una vez posicionados en la base de datos que queremos restaurar, seleccionamos la función ‘Restore’ en la que se nos presentarán las opciones de restauración.
Base de datos que queremos restaurar
Seleccionamos el punto de restauración y la base de datos destino (adventuredowrks_2024-05.28T13-00Z)
Con estas opciones, se restaurará la base de datos ‘adventuredworks’ en ‘adventuredowrks_2024-05.28T13-00Z’ en es estaba en el que se encontraba el 28/05/2024 a las 13:00UTC.
Ya solo nos quedaría la revisión y la creación.
Restauración de bases de datos borradas
Como hemos visto en el ejemplo anterior, no es posible restaurar sobre bases de datos existentes. En caso de necesidad de restaurar sobre una base de datos existente, hemos de borrarlas antes de proceder.
CAUTION: Sólo podremos restaurar bases de datos cuyos backups estén dentro del periodo de retención, es decir, en nuestro caso, si borramos la base de datos ‘adventuredworks’, tendríamos opción de restaurarla solo en los próximos 7 días, en base a la configuración de retención de los backups.
El procedimiento que se describe a continuación, es similar al que hemos descrito en el apartado anterior solo, que en este caso, se ha procedido al borrado de la base de datos ‘adventuredworks’ previo al proceso de restauración.
Partimos de la configuración que ya teníamos y que ha sido utilizada para los backups de ‘adventureworks’.
En este caso en el que se restauran backups de bases de datos borradas, hemos de localizar dichos backups en la opción ‘Deleted’ del repositorio.
Nos posicionamos sobre la opción backups en el servidor (Data management -> Backups) y pulsamos sobre la función ‘Restore’.
Seleccionamos el backup de la base de datos a restaurar en el contenedor ‘Deleted’
Restauración de base de datos con PowerShell
Una vez vista la restauración de una Azure SQL Database desde el propio portal de Azure, vamos a reproducir los mismos escenarios pero, esta vez, haciendo uso del módulo de Azure de PowerShell. Antes de empezar, hemos de asegurar que disponemos de dicho módulo para operar con él.
Exportación e importación de bases de datos bajo demanda
El proceso que se describe a continuación, no es una restauración tal cual sino exportación y importación con archivos .bacpac.
Un archivo .bacpac es un contenedor que almacena esquema de la base de batos (incluyendo tablas, vistas, procedimientos almacenados, funciones, índices, y otros objetos de base de datos) y datos (datos almacenados en las tablas de la base de datos).
El proceso de export e import que se describe a continuación, se ejecuta sobre SSMS pero puede ser ejecutado también con scripts de PowerShell.
Exportación de base de datos a .bacpac
Para la exportación, nos conectamos al servidor al que se encuentra enlazado la base de datos sobre la que queremos operar, nos posicionamos sobre la base de datos que queremos exportar y seleccionamos la opción ‘Export Data-tier Application’.
Conexión y localización de la opción de exportación
A continuación, seleccionamos los archivos en el que se volcará la importación. En nuestro caso será en un archivo local, aunque tenemos la opción de volcarlo en un contenedor incluido en una cuenta de almacenamiento de Azure.
Archivo destino del import
Resumen del proceso a ejecutar
Ejecución del proceso
Importación de base de datos a partir de un .bacpac
Para la importación, ejecutamos el proceso inverso al descrito en la importación.
Al igual que en el proceso de exportación, nos conectamos al servidor al que se encuentra enlazado la base de datos sobre la que queremos operar, y en este caso, nos posicionamos en el contenedor principal ‘Databases’. Sobre dicho contenedor (botón derecho de ratón), seleccionamos la opción ‘Import Data-tier Application’.
Seleccionamos el archivo que va a exportarse y la parametrización de la base de datos destino.
Archivo desde el que se importa
Parametrización de la base de datos destino (exportAdventuredworks)
Resumen de la importación
Ejecución del proceso
Conclusión
Debes plasmar en uno o dos párrafos las ideas esenciales del artículo e indicarles cómo y porqué, utilizando los conocimientos expuestos, podrán solventar o llevar a cabo las ideas que previamente tenían.
El resultado debe ser doble:
- Aportar un valor en tus lectores con tu nuevo artículo. Los habrás enriquecido con nuevos conocimientos técnicos, aumentado su motivación y ganas de seguir adelante con su proyecto.
- Establecer un vínculo contigo de tal forma que sepan que pueden contar con tu ayuda puesto que te habrás convertido en algo útil, resolutivo y profesional.
En el post hemos podido analizar la versatilidad en las tareas de backup y restauración de datos en entorno Azure SQL Database.
Como hemos visto, en Azure SQL Database se diferencian dos tipos de backup en función de la retención: PITR (point-in-time recovery) y LTR (long-term retention). Dichas opciones nos permite definir la retención de los backups desde dos vertientes, por un, lado backups con posibilidad de restauración de datos de un punto determinado en el tiempo y, por otro lado, nos permite mantener backups (full backups) de largo plazo con opción de mantener hasta 10 años de retención.
Como parte de post, se analizan escenarios reales de restauración de datos tanto desde el entorno del portal, como backup con opción de automatizar con scripts de PowerShell.
Por último se analiza la opción de recuperación de datos a partir de exports e imports desde el propio SSMS. Esta opción es una forma rápida para generar una copia de una base de datos que pudiera ser utilizada en tareas de depuración en incidencias.
Antonio Llompart Freire
Data & Cloud Mentor
