Copia de seguridad y restauración
En organizaciones grandes o pequeñas, se pueden producir accidentes e incidentes. Por ese motivo siempre debe tener un plan de cómo restaurar los sistemas en caso de interrupción. En SQL Server, si quiere restaurar una base de datos a un momento dado, solo puede hacerlo si se ejecuta en el modelo de recuperación completa. En el modelo de recuperación optimizado para cargas masivas de registros, es más probable que tenga que recuperar la base de datos al final de la copia de seguridad del registro de transacciones.
Una de las ventajas de Azure SQL es que Azure puede encargarse de todo esto automáticamente. Como Azure SQL administra las copias de seguridad y se ejecuta en el modelo de recuperación completa, puede restaurar la base de datos a cualquier momento dado. Incluso puede restaurar una base de datos eliminada en el marco de la directiva de retención que se haya configurado. Microsoft también cifra de forma automática las copias de seguridad si TDE está habilitado en el servidor lógico o la instancia.
De forma predeterminada, se realiza una copia de seguridad completa de la base de datos una vez a la semana. Las copias de seguridad de los registros se realizan cada 5-10 minutos, y las copias de seguridad diferenciales, cada 12-24 horas. Los archivos de copia de seguridad se almacenan en Azure Storage en almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) de forma predeterminada. Aun así, puede optar por almacenar las copias de seguridad en almacenamiento con redundancia de zona (ZRS) o en almacenamiento con redundancia local (LRS). De forma continuada, el equipo de ingeniería de Azure SQL comprueba automáticamente la restauración de las copias de seguridad automatizadas de las bases de datos colocadas en servidores lógicos y grupos de bases de datos elásticas. Para las migraciones a Azure SQL Managed Instance, se completa una copia de seguridad inicial automática con la suma de comprobación de las bases de datos restauradas con el comando nativo RESTORE, o bien con Azure Database Migration Service. Además, en Azure SQL Managed Instance, opcionalmente puede realizar una copia de seguridad nativa de solo copia y almacenarla en Azure Blob Storage.
Creación de una estrategia de copia de seguridad para Azure SQL Managed Instance y Azure SQL Database
Azure SQL se encarga del trabajo pesado, pero es importante comprender cómo se almacenan y procesan las copias de seguridad y cuáles son las opciones de retención y restauración. En última instancia, sigue siendo responsable de la estrategia general de la restauración a un momento dado, la retención a largo plazo y la restauración geográfica.
Restauración a un momento dado (PITR)
En Azure SQL Database y Azure SQL Managed Instance, puede realizar un autoservicio de restauración. Puede elegir el punto exacto en el tiempo al que quiere restaurar e iniciar el proceso mediante Azure Portal, PowerShell o la CLI de Azure, o las API REST. La restauración a un momento dado (PITR) creará una base de datos (con otro nombre) en el mismo servidor lógico. Si tiene que reemplazar la base de datos original por la base de datos de PITR, tendrá que cambiar el nombre de la base de datos original y la nueva para volver a una condición de trabajo. No tendrá que actualizar las cadenas de conexión.
La retención de PITR, varía entre 1 y 35 días. De forma predeterminada, el período de retención (para todos los niveles de servicio y opciones de implementación) es de siete días. En la mayoría de las opciones de implementación y los niveles de servicio, puede configurar la directiva para que sea de 1 a 35 días, en función de los requisitos del escenario. Por ejemplo, es posible que solo necesite 1 día para una base de datos de prueba, pero que elija el máximo de 35 días para una base de datos crítica.
Retención a largo plazo (LTR)
Si 35 días no son suficientes para satisfacer las necesidades o el cumplimiento de la organización, puede elegir la retención a largo plazo (LTR). Esta opción permite crear automáticamente copias de seguridad completas de la base de datos que se guardan en el almacenamiento RA-GRS, ZRS o LRS durante un máximo de 10 años. Para Azure SQL Database, LTR está disponible con carácter general. Para Azure SQL Managed Instance, LTR está disponible en una versión preliminar pública limitada.
Restauración geográfica
Si hay un evento catastrófico, la organización debe ser capaz de recuperarse. Las copias de seguridad se almacenan automáticamente en RA-GRS (a menos que elija ZRS o LRS), es decir, se almacenan en la región emparejada. Por tanto, si una región completa deja de funcionar y las bases de datos o instancias administradas se encuentran en esa región, está protegido. Puede realizar una restauración geográfica en cualquier otra región a partir de la copia de seguridad con replicación geográfica más reciente. Esta copia de seguridad puede estar algo atrasada con respecto a la principal, ya que se tarda en replicar el blob de Azure en otra región. Puede realizar una restauración geográfica con facilidad mediante Azure Portal, PowerShell o la CLI de Azure, o las API de REST.