Copias de seguridad automatizadas en Azure SQL Database

Se aplica a:Azure SQL Database

En este artículo se describe la característica de copia de seguridad automatizada para Azure SQL Database.

Para cambiar la configuración de copia de seguridad, consulte Cambiar la configuración. Para restaurar una copia de seguridad, consulte Recuperación mediante copias de seguridad automatizadas de bases de datos.

¿Qué es una copia de seguridad de base de datos?

Las copias de seguridad de base de datos son una parte esencial de cualquier estrategia de continuidad empresarial y recuperación ante desastres, ya que ayudan a proteger los datos de daños o eliminaciones. Estas copias de seguridad habilitan la restauración de la base de datos a un momento dado dentro del período de retención configurado. Si las reglas de protección de datos exigen que las copias de seguridad estén disponibles durante un tiempo prolongado (hasta 10 años), puede configurar la retención a largo plazo (LTR) para bases de datos únicas y agrupadas.

En el caso de los niveles de servicio distintos de Hiperescala, Azure SQL Database usa tecnología de motor de SQL Server para realizar copias de seguridad y restaurar datos. Las bases de datos de Hiperescala usan copias de seguridad y restauración en función de las instantáneas de almacenamiento. Con la tecnología tradicional de copias de seguridad SQL Server, las bases de datos más grandes tienen largos tiempos de copia de seguridad y restauración. Al utilizar instantáneas, Hyperscale proporciona copias de seguridad instantáneas y capacidades de restauración rápida independientemente del tamaño de la base de datos. Para obtener más información, consulte Copias de seguridad de Hiperescala.

Frecuencia de copia de seguridad

Azure SQL Database crea:

• Copias de seguridad completas cada semana.
• Copias de seguridad diferenciales cada 12 a 24 horas.
• Copias de seguridad del registro de transacciones aproximadamente cada 10 minutos.

La frecuencia exacta de las copias de seguridad de los registros de transacciones depende del tamaño del cómputo y de la cantidad de actividad de la base de datos. Cuando restauras una base de datos, Azure SQL Database determina qué copias de seguridad completas, diferenciales y de transacciones restaurar.

La arquitectura de Hiperescala no requiere copias de seguridad completas, diferenciales ni de registros. Para obtener más información, consulte Copias de seguridad de Hiperescala.

Redundancia del almacenamiento de copia de seguridad

El mecanismo de redundancia almacena varias copias de tus datos para protegerlos de eventos planificados e imprevistos. Estos eventos podrían incluir errores transitorios de hardware, cortes de red o de energía o desastres naturales masivos.

De manera predeterminada, las nuevas bases de datos en Azure SQL Database almacenan copias de seguridad en blobs de almacenamiento georredundantes que se replican en una región emparejada. La redundancia geográfica ofrece protección contra interrupciones que afectan al almacenamiento de copia de seguridad de la región primaria. También permite restaurar las bases de datos en otra región en caso de una interrupción regional.

Azure Portal proporciona una opción de entorno de carga de trabajo que ayuda a establecer previamente algunas opciones de configuración. Puedes anular estos ajustes. Esta opción solo se aplica a la página Crear portal de SQL Database .

• Al elegir el entorno de carga de trabajo de desarrollo, se establece la opción Redundancia de almacenamiento de copia de seguridad para usar el almacenamiento con redundancia local. El almacenamiento con redundancia local incurre en menos costes y es adecuado para entornos de preproducción que no necesitan la redundancia del almacenamiento con replicación geográfica o de zona.
• Al elegir el entorno de producción, se establece la redundancia de almacenamiento de respaldo en el almacenamiento con redundancia geográfica, por defecto.
• La opción de entorno de carga de trabajo también cambia la configuración inicial de computación, aunque puedes anular esta configuración. De lo contrario, la opción Entorno de carga de trabajo no afecta a las licencias ni a otras opciones de configuración de base de datos.

Para asegurarte de que tus copias de seguridad permanezcan dentro de la misma región donde se despliega tu base de datos, cambia la redundancia del almacenamiento geo-redundante predeterminado a otros tipos de almacenamiento que mantengan tus datos dentro de la región. La redundancia de almacenamiento de copia de seguridad configurada se aplica a las copias de seguridad de retención a corto plazo (STR) y a las copias de seguridad de retención a largo plazo (LTR). Para obtener más información acerca de la redundancia de almacenamiento, consulte Redundancia de datos.

Puedes configurar la redundancia del almacenamiento de copia de seguridad cuando crees tu base de datos, y puedes actualizarla más adelante. Los cambios que hagas en una base de datos existente solo se aplican a futuras copias de seguridad. Una vez actualizada la redundancia del almacenamiento de copia de seguridad de una base de datos, los cambios pueden tardar hasta 48 horas en aplicarse.

Puede elegir una de las siguientes redundancias de almacenamiento para copias de seguridad:

• Almacenamiento con redundancia local (LRS): copia las copias de seguridad de forma sincrónica tres veces dentro de una única ubicación física en la región primaria. LRS es la opción de almacenamiento más económica, pero no se recomienda para aplicaciones que requieren resiliencia frente a cortes regionales ni garantía de alta durabilidad de los datos.

  

• Almacenamiento con redundancia de zona (ZRS): copia las copias de seguridad de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria. Está disponible actualmente solo en determinadas regiones.

  

• Almacenamiento con redundancia geográfica (GRS): copia las copias de seguridad de forma sincrónica tres veces dentro de una única ubicación física en la región primaria mediante LRS. A continuación, copia los datos de forma asincrónica tres veces en una sola ubicación física en la región secundaria emparejada.

  El resultado es el siguiente:

  • Tres copias sincrónicas en la región primaria.
  • Tres copias sincrónicas en la región emparejada que se copiaron de la región primaria a la región secundaria de forma asincrónica.

  

• Almacenamiento redundante de zona geográfica (GZRS): el almacenamiento con redundancia de zona geográfica (GZRS) combina la alta disponibilidad proporcionada por la redundancia entre zonas de disponibilidad (ZRS) con protección frente a interrupciones regionales proporcionadas por la replicación geográfica (GRS). En GZRS, Azure copia tus copias de seguridad de forma sincrónica a través de tres zonas de disponibilidad de Azure en la región primaria, y de forma asíncrona tres veces a una única ubicación física en la región secundaria emparejada.

  Microsoft recomienda el uso de GZRS en aplicaciones que requieran de coherencia, durabilidad y disponibilidad máximas, además de rendimiento excelente y resistencia para la recuperación ante desastres.

  El resultado es el siguiente:

  • Tres copias sincrónicas en Availability Zones, en la región primaria.

  • Tres copias sincrónicas en la región emparejada, copiadas de forma asincrónica desde la región primaria a la región secundaria.

    En el diagrama siguiente se muestra cómo se replican los datos con GZRS o RA-GZRS:

  

Uso de copia de seguridad

Utiliza copias de seguridad creadas automáticamente en los siguientes escenarios:

• Restaurar una base de datos existente a un momento dado dentro del período de retención mediante Azure Portal, Azure PowerShell, la CLI de Azure o la API de REST. Esta operación crea una nueva base de datos en el mismo servidor que la base de datos original, pero usa un nombre diferente para evitar sobrescribir la base de datos original.

  Una vez finalizada la restauración, puede optar por eliminar la base de datos original y cambiar el nombre de la base de datos restaurada al de la original. Como alternativa, en lugar de eliminarla puede cambiar el nombre de la base de datos original y, luego, el de la base de datos restaurada para que tenga el nombre de la original.

• Restaurar una base de datos eliminada al momento dado dentro del período de retención, incluyendo el momento de su eliminación. Solo puedes restaurar la base de datos eliminada en el mismo servidor donde creaste la base de datos original. Antes de eliminar una base de datos, Azure SQL Database realiza una copia de seguridad final del registro de transacciones para evitar cualquier pérdida de datos.

• Restaurar una base de datos en otra región geográfica. La restauración geográfica te ayuda a recuperarte de una interrupción regional cuando no puedes acceder a tu base de datos o copias de seguridad en la región principal. Crea una base de datos en cualquier servidor existente en cualquier región de Azure.

  Importante

  La restauración geográfica solo está disponible para bases de datos configuradas con almacenamiento de copia de seguridad con redundancia geográfica. Si actualmente no estás usando copias de seguridad geo-replicadas para una base de datos, puedes cambiar esta configuración configurando la redundancia de almacenamiento de copia de seguridad.

• Restaurar una base de datos a partir de una copia de seguridad a largo plazo específica de una base de datos única o de una base de datos agrupada, si la base de datos está configurada con una política LTR. LTR permite restaurar una versión antigua de la base de datos con Azure Portal, la CLI de Azure o Azure PowerShell para satisfacer una solicitud de cumplimiento o para ejecutar una versión antigua de la aplicación. Para más información, consulte retención a largo plazo.

Copias de seguridad automáticas en réplicas secundarias

El nivel de servicio Business Critical acepta copias automáticas de una réplica secundaria. Dado que los datos se replican entre procesos de SQL Server en cada nodo, el servicio de copia de seguridad toma la copia de seguridad de las réplicas secundarias no legibles. Este diseño garantiza que la réplica principal se mantenga dedicada a su carga de trabajo principal, y que la réplica secundaria legible esté dedicada a cargas de trabajo de solo lectura. Las copias de seguridad automáticas en el nivel de servicio Crítico para la empresa se toman de una réplica secundaria la mayor parte del tiempo. Si falla una copia de seguridad automática en una réplica secundaria, el servicio de copia de seguridad toma la copia de seguridad de la réplica principal.

Copias de seguridad automáticas en réplicas secundarias:

• Están habilitadas de manera predeterminada.
• Están incluidos sin coste adicional más allá del precio del nivel de servicio.
• Mejore el rendimiento y la previsibilidad en el nivel de servicio Crítico para la empresa.

Restaurar características y funcionalidades

En esta tabla se resumen las funcionalidades y características de la restauración a un momento dado (PITR), la restauración geográfica y la retención a largo plazo.

Para obtener información sobre los tiempos de recuperación, consulte RTO y RPO.

¹ En el caso de las aplicaciones críticas para la empresa que necesitan bases de datos grandes y deben garantizar la continuidad empresarial, utiliza grupos de conmutación por error.
² Todas las copias de seguridad de PITR se almacenan en almacenamiento georedundante de forma predeterminada, por lo que la restauración geográfica está habilitada de forma predeterminada.
³ La solución alternativa consiste en realizar la restauración en un nuevo servidor y usar el movimiento de recursos para mover el servidor a otra suscripción, o utilizar una copia de base de datos entre suscripciones.

Restauración de una base de datos desde una copia de seguridad

Para más información sobre cómo restaurar una base de datos, consulte Restaurar una base de datos a partir de copias de seguridad. Para explorar la configuración de copias de seguridad y las operaciones de restauración, utiliza los siguientes ejemplos.

Exportación de una base de datos

No puedes descargar ni acceder directamente a las copias de seguridad automáticas que realiza el servicio de Azure. Azure solo utiliza estas copias de seguridad para operaciones de restauración.

Para exportar una Azure SQL Database, considera otras alternativas.

• Cuando necesites exportar una base de datos para archivar o para trasladarla a otra plataforma, exporta el esquema y los datos de la base de datos a un archivo BACPAC . Un archivo BACPAC es un archivo ZIP con una extensión de BACPAC que contiene los metadatos y los datos de la base de datos. Puedes almacenar un archivo BACPAC en Azure Blob storage o en almacenamiento local en una ubicación local. Más adelante, puedes importarlo de nuevo en Azure SQL Database, Azure SQL Managed Instance o una instancia de SQL Server.
• También puede Importar o exportar una base de datos de Azure SQL mediante un vínculo privado o Importar o exportar una base de datos de Azure SQL sin permitir que los servicios de Azure accedan al servidor.

Programación de copias de seguridad

La primera copia de seguridad completa se programa justo después de crear o restaurar una nueva base de datos. Normalmente, esta copia de seguridad finaliza en 30 minutos, pero puede tardar más si la base de datos es grande. Por ejemplo, la copia de seguridad inicial puede tardar más en una base de datos restaurada o en una copia de base de datos.

Tras la primera copia de seguridad completa, Azure programa y gestiona automáticamente todas las copias posteriores. El servicio de base de datos SQL determina el momento exacto de todas las copias de seguridad de la base de datos mientras equilibra la carga de trabajo global del sistema. No se puede cambiar la programación de trabajos de copia de seguridad ni deshabilitarlos.

Consumo del almacenamiento de copia de seguridad

Con la tecnología de copias de seguridad y restauración de SQL Server, restaurar una base de datos hasta un momento dado requiere una cadena de copia de seguridad ininterrumpida. Esa cadena consta de una copia de seguridad completa, opcionalmente una copia de seguridad diferencial y una o varias copias de seguridad del registro de transacciones.

Azure SQL Database programa una copia de seguridad completa cada semana. Para proporcionar PITR dentro de todo el periodo de retención, Azure debe almacenar copias de seguridad completas, diferenciales y de transacciones adicionales durante hasta una semana más que el periodo de retención configurado.

En otras palabras, en cualquier momento durante el período de retención, debe haber una copia de seguridad completa que tenga una antigüedad mayor que la fecha más antigua del período de retención. También debe haber una cadena ininterrumpida de copias de seguridad diferenciales y del registro de transacciones desde esa copia de seguridad completa hasta la siguiente copia de seguridad completa.

Las bases de datos de Hiperescala usan un mecanismo de programación de copia de seguridad diferente. Para obtener más información, consulte Programación de copias de seguridad de Hiperescala.

Azure elimina automáticamente las copias de seguridad que ya no son necesarias para proporcionar funcionalidad PIR. Dado que las copias de seguridad diferenciales y de registro requieren una copia de seguridad completa anterior para ser restaurables, Azure purga los tres tipos de copia de seguridad juntos en conjuntos semanales.

Para todas las bases de datos, incluidas las cifradas por TDE, Azure comprime todas las copias de seguridad completas y diferenciales para reducir la compresión y los costes del almacenamiento de respaldo. La relación media de compresión de respaldo es de tres a cuatro veces. Sin embargo, puede ser menor o mayor, en función de la naturaleza de los datos y de si se usa la compresión de datos en la base de datos.

Azure SQL Database calcula el almacenamiento de copia de seguridad total usado como un valor acumulativo. Cada hora, Azure informa este valor a la cadena de facturación. La canalización de facturación se encarga de agregar este uso por hora para calcular el consumo al final de cada mes. Después de eliminar una base de datos, el consumo disminuye a medida que las copias de seguridad se agotan y se eliminan. Una vez que se han eliminado todas las copias de seguridad y PITR ya no es posible, se detiene la facturación.

Supervisión del consumo

Para bases de datos vCore en Azure SQL Database, el panel de monitorización de la base de datos informa del almacenamiento que consume cada tipo de copia de seguridad (completa, diferencial y log) como una métrica separada. En esta captura de pantalla se muestra cómo supervisar el consumo de almacenamiento de copia de seguridad para una única base de datos.

Para obtener instrucciones sobre cómo supervisar el consumo de Hiperescala, consulte Supervisar el consumo de copia de seguridad de Hiperescala.

Optimización del consumo del almacenamiento de copia de seguridad

No se te cobra por el consumo de almacenamiento de copia de seguridad hasta el tamaño máximo de datos de una base de datos. Para reducir el consumo de almacenamiento de copia de seguridad, considera algunas de las siguientes técnicas de ajuste:

• Reduzca el período de retención de copias de seguridad al mínimo para sus necesidades.
• Evite realizar operaciones de escritura de gran tamaño (como recompilaciones de índices) con más frecuencia de la debida.
• En el caso de las operaciones de carga de datos de gran tamaño, considere la posibilidad de usar índices de almacén de columnas agrupados, siga los procedimientos recomendados relacionados. Considera también la posibilidad de reducir el número de índices no clúster.
• En el nivel de servicio De uso general, el almacenamiento de datos aprovisionado es más económico que el precio del almacenamiento de copia de seguridad. Si tienes costes de almacenamiento de copia de seguridad continuamente elevados, considera aumentar el almacenamiento de datos para ahorrar en el almacenamiento de copia de seguridad.
• En la lógica de aplicación, use tempdb en lugar de tablas permanentes para almacenar resultados temporales o datos transitorios.
• Use el almacenamiento de copia de seguridad con redundancia local siempre que sea posible (por ejemplo, en entornos de desarrollo y pruebas).

Retención de copias de seguridad

Azure SQL Database proporciona retención a corto y largo plazo de copias de seguridad. La retención a corto plazo permite la restauración a un momento dado dentro del período de retención de la base de datos. La retención a largo plazo proporciona copias de seguridad para diversos requisitos de cumplimiento.

Retención a corto plazo

Para todas las bases de datos nuevas, restauradas y copiadas, Azure SQL Database conserva suficientes copias de seguridad para permitir PITR en los últimos siete días por defecto. Azure SQL Database realiza copias de seguridad completas, diferenciales y de registro periódicas para garantizar que las bases de datos sean restaurables en cualquier momento dentro del periodo de retención de la base de datos.

Puedes configurar copias de seguridad diferenciales para que ocurran una vez cada 12 horas o una vez cada 24 horas. Una frecuencia diferencial de copia de seguridad de 24 horas podría aumentar el tiempo necesario para restaurar la base de datos, en comparación con la frecuencia de 12 horas. En el modelo de núcleo virtual, la frecuencia predeterminada para las copias de seguridad diferenciales es una vez en 12 horas. En el modelo de DTU, la frecuencia predeterminada es una vez cada 24 horas.

Puedes especificar la opción de redundancia de almacenamiento de copia de seguridad para STR cuando crees tu base de datos, y luego cambiarla más adelante. Si cambias la opción de redundancia de copias de seguridad en una base de datos existente, las nuevas copias de seguridad usan la nueva opción de redundancia. Azure no mueve ni copia copias de seguridad hechas con la opción anterior de redundancia a corto plazo. Azure los deja en la cuenta de almacenamiento original hasta que expire el periodo de retención, que puede ser de 1 a 35 días.

Se puede cambiar el período de retención de la copia de seguridad para cada base de datos activa en el rango de 1 a 35 días, excepto en el caso de las bases de datos básicas, que son configurables de 1 a 7 días. Como se describe en Consumo de almacenamiento de copia de seguridad, las copias de seguridad almacenadas para habilitar PITR podrían ser anteriores al período de retención. Si tiene que mantener las copias de seguridad durante más tiempo del período de retención a corto plazo máximo de 35 días, puede habilitar la retención a largo plazo.

Si eliminas una base de datos, Azure mantiene copias de seguridad de la misma manera que para una base de datos online con su periodo específico de retención. No se puede cambiar el período de retención de copia de seguridad de una base de datos eliminada.

Retención a largo plazo

En el caso de SQL Database, se puede configurar una retención a largo plazo (LTR) de las copias de seguridad completas de hasta 10 años en Azure Blob Storage. Después de configurar la política de LTR, Azure copia automáticamente copias de seguridad completas a un contenedor de almacenamiento diferente cada semana.

Para cumplir con los distintos requisitos de cumplimiento, selecciona diferentes periodos de retención para copias de seguridad completas semanales, mensuales y anuales. La frecuencia depende de la directiva. Por ejemplo, establecer W=0, M=1 crea una copia LTR cada mes. Para más información sobre LTR, vea Retención a largo plazo.

Actualizar la redundancia del almacenamiento de copia de seguridad para una base de datos existente aplica el cambio solo a copias de seguridad posteriores realizadas en el futuro y no a copias de seguridad existentes. Todas las copias de seguridad de retención a largo plazo de la base de datos existentes residen en el blob de almacenamiento existente. Las nuevas copias de seguridad se replican en función de la redundancia de almacenamiento de copia de seguridad configurada.

El consumo de almacenamiento depende de la frecuencia seleccionada y de los pe.ríodos de retención de las copias de seguridad de LTR. Utiliza la calculadora de precios de LTR para estimar el coste del almacenamiento de LTR.

Al restaurar una base de datos de hiperescala a partir de una copia de seguridad de LTR, se desactiva la propiedad de escala de lectura. Para habilitar la lectura de la escala en la base de datos restaurada, actualice la base de datos después de haber sido creada. Cuando se restaura a partir de una copia de seguridad LTR, es necesario especificar el objetivo de nivel de servicio de destino.

Puedes habilitar la retención a largo plazo para bases de datos Hyperscale creadas o migradas desde otros niveles de servicio. Si intentas habilitar LTR para una base de datos de Hiperescala en la que aún no se admite, recibirá el siguiente error: «Se ha producido un error al habilitar la retención de copia de seguridad a largo plazo para esta base de datos. Por favor, contacta con el soporte de Microsoft para habilitar la retención de copias de seguridad a largo plazo." En este caso, contacta con el soporte de Microsoft y crea un ticket de soporte para resolverlo.

Costos de almacenamiento de copia de seguridad

El precio del almacenamiento de copia de seguridad varía y depende del modelo de compra (DTU o núcleo virtual), la opción de redundancia del almacenamiento de copia de seguridad elegida y la región. Pagas por el almacenamiento de copia de seguridad en función de gigabytes consumidos al mes, al mismo ritmo para todas las copias de seguridad.

Para obtener información acerca de los precios, consulte la página de precios de Azure SQL Database.

Modelo de DTU

En el modelo DTU, para bases de datos y pools elásticos no hay cargo adicional por almacenamiento de respaldo PITR para la retención predeterminada de siete días o más. El precio del almacenamiento de respaldo PITR forma parte del precio de la base de datos o del pool.

En el modelo DTU, pagas por el almacenamiento de respaldo LTR para bases de datos y pools elásticos en función del almacenamiento real que consumen las copias de seguridad LTR.

Modelo de vCore

Azure SQL Database calcula el total de almacenamiento facturable de respaldo como un valor acumulativo en todos los archivos de copia de seguridad. Cada hora, Azure envía este valor a la cadena de facturación. La tubería agrega este uso por hora para determinar tu consumo de almacenamiento de respaldo al final de cada mes.

Si eliminas una base de datos, el consumo de almacenamiento de copias de seguridad disminuye gradualmente a medida que las copias antiguas se agotan y se eliminan. Dado que las copias de seguridad diferenciales y de registro requieren una copia de seguridad completa anterior para ser restaurables, Azure purga los tres tipos de copia de seguridad juntos en conjuntos semanales. Después de que se hayan eliminado todas las copias de seguridad, se detiene la facturación.

Las bases de datos hiperescaladas utilizan un método diferente para calcular los costes de almacenamiento de copias de seguridad. Para obtener más información, consulte Costos de almacenamiento de copias de seguridad a gran escala.

Para bases de datos individuales, obtienes una cantidad de almacenamiento de copia de seguridad igual al tamaño máximo de almacenamiento de datos para la base de datos sin coste adicional. La siguiente ecuación calcula el uso total facturable de almacenamiento de respaldo:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Para pools elásticos, obtienes una cantidad de almacenamiento de respaldo igual al máximo de almacenamiento de datos para el tamaño del pool sin coste adicional. En el caso de las bases de datos agrupadas, el tamaño total del almacenamiento de copia de seguridad facturable se agrega en el nivel de grupo y se calcula de la siguiente manera:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Pagas el almacenamiento total facturable de copia de seguridad, si lo hay, en gigabytes al mes según la redundancia del almacenamiento de copia de seguridad. Este consumo del almacenamiento de copia de seguridad dependerá de la carga de trabajo y del tamaño de las bases de datos individuales, los grupos elásticos y las instancias administradas. Las bases de datos que se modifiquen con mucha frecuencia tienen copias de seguridad diferenciales y de registro mayores, ya que su tamaño es proporcional a la cantidad de cambios en los datos. Por tanto, estas bases de datos tienen mayores cargos de copia de seguridad.

Como ejemplo simplificado, supongamos que una base de datos acumula 744 GB de almacenamiento de respaldo y que esta cantidad se mantiene constante durante todo un mes porque la base de datos está completamente inactiva. Para convertir este consumo de almacenamiento acumulativo en un uso por hora, lo dividimos entre 744,0 (31 días al mes x 24 horas al día). SQL Database notifica a la canalización de facturación de Azure que la base de datos ha consumido 1 GB de copia de seguridad PITR cada hora, a una velocidad constante. La facturación de Azure agrega este consumo y muestra un uso de 744 GB para todo el mes. Este coste se basa en la tarifa de gigabytes por mes en tu región.

Este es otro ejemplo. Imagine que la misma base de datos inactiva ha aumentado su retención de 7 a 14 días a mediados de mes. Este aumento hace que el almacenamiento de copia de seguridad total se duplique hasta llegar a 1488 GB. La base de datos SQL informa de 1 GB de uso durante las horas 1 a 372 (la primera mitad del mes). Informa el consumo como 2 GB durante las horas 373 a 744 (la segunda mitad del mes). Este consumo se suma a una factura final de 1.116 GB al mes.

Los escenarios reales de facturación de copia de seguridad son más complejos. Dado que la velocidad de cambios en la base de datos depende de la carga de trabajo y varía a lo largo del tiempo, el tamaño de cada copia de seguridad diferencial y de registro también varía. El consumo por hora del almacenamiento de copia de seguridad fluctúa según corresponda.

Cada copia de seguridad diferencial también contiene todos los cambios realizados en la base de datos desde la última copia de seguridad completa. Por lo tanto, el tamaño total de todas las copias de seguridad diferenciales aumenta gradualmente en el transcurso de una semana. Entonces disminuye drásticamente después de que un conjunto anterior de copias de seguridad completas, diferenciales y de registro pierde su vigencia.

Por ejemplo, supongamos que una actividad de escritura intensiva, como la recompilación de índices, se ejecuta justo después de completar una copia de seguridad completa. Las modificaciones que realiza la reconstrucción del índice se incluyen:

• En las copias de seguridad del registro de transacciones realizadas durante la recompilación.
• En la siguiente copia de seguridad diferencial.
• En cada copia de seguridad diferencial realizada hasta que se produzca la siguiente copia de seguridad completa.

En el último escenario, en bases de datos más grandes, una optimización en Azure crea una copia de seguridad completa en lugar de una copia de seguridad diferencial si de otro modo una copia de seguridad diferencial sería excesivamente grande. Esta optimización reduce el tamaño de todas las copias de seguridad diferenciales hasta la siguiente copia de seguridad completa.

Puede supervisar el consumo total de almacenamiento de copia de seguridad para cada tipo de copia de seguridad (completa, diferencial, del registro de transacciones) en el tiempo, como se describe en Supervisión del consumo.

Supervisión de costos

Para comprender los costos de almacenamiento de copia de seguridad, vaya a Administración de costos + facturación en Azure Portal. Seleccione Cost Management y, luego seleccione Análisis de costes. Seleccione la suscripción deseada para ámbito y, a continuación, filtre por el período de tiempo y el servicio que le interese como se indica a continuación:

1. Agregue un filtro para el nombre de servicio.

2. En la lista desplegable, seleccione sql database para una base de datos única o un grupo de bases de datos elásticas.

3. Agregue otro filtro para la subcategoría del medidor.

4. Para supervisar los costos de copia de seguridad PITR, en la lista desplegable, seleccione single/elastic pool pitr backup storage (almacenamiento de copia de seguridad PITR de base de datos única o de grupo de bases de datos elásticas). Los medidores solo se mostrarán si existe el consumo de almacenamiento de copia de seguridad.

   Para supervisar los costos de copia de seguridad de LTR, en la lista desplegable, seleccione almacenamiento de copia de seguridad de retención a largo plazo en el caso de una sola base de datos o un grupo de bases de datos elásticas. Los medidores solo se mostrarán si existe el consumo de almacenamiento de copia de seguridad.

Las subcategorías Almacenamiento y Proceso pueden interesarle también, pero no están asociadas con los costos de almacenamiento de copia de seguridad.

Para más información, consulte Administración de costos de Azure SQL Database.

Copias de seguridad cifradas

Si cifras tu base de datos usando TDE, las copias de seguridad se cifran automáticamente en reposo, incluidas las copias de seguridad LTR. Todas las bases de datos nuevas de Azure SQL están configuradas con TDE habilitado de forma predeterminada. Para más información sobre TDE, vea Cifrado de datos transparente con SQL Database.

Integridad de copia de seguridad

Azure SQL Database gestiona automáticamente ciertos tipos de corrupción de datos utilizando técnicas integradas cuando es necesario, sin pérdida de datos. En Azure SQL Database, SQL Motor de base de datos realiza la verificación de páginas durante las copias de seguridad gestionadas por servicios y durante cada operación de restauración. Los problemas encontrados durante la comprobación de integridad producen una alerta para el equipo de ingeniería.

Como capa extra de protección, puedes probar la restauración de copias de seguridad y realizar comprobaciones de integridad. Para más información, consulta Data Integrity in Azure SQL Database.

Todas las copias de seguridad de la base de datos usan la opción CHECKSUM para proporcionar una integridad adicional de las copias de seguridad.

Protección de copia de seguridad

Las suscripciones de Azure, propiedad de Microsoft, gestionan copias de seguridad de Azure SQL Database utilizando cuentas internas de Azure Storage seguras. No puedes acceder a estas copias externamente, por lo que proporcionan un fuerte aislamiento y protección de datos. Dentro de Microsoft, solo los servicios de backend pueden acceder, crear, copiar o restaurar estas copias de seguridad. Los ingenieros de Microsoft, incluidos los desarrolladores, no tienen acceso permanente. Para minimizar la exposición y maximizar la seguridad, Microsoft solo puede obtener acceso Just-In-Time (JIT) bajo controles de auditoría estrictos cuando sea absolutamente necesario para solucionar problemas específicos del cliente.

Las copias de seguridad se eliminan automáticamente una vez que expira el periodo de retención.

Cumplimiento a través de la retención de copia de seguridad

Si la retención por defecto no cumple con tus requisitos de cumplimiento, cambia el periodo de retención del PIR. Para más información, vea Cambio del período de retención de copia de seguridad PITR.

Cuando migras tu base de datos de un nivel de servicio basado en DTU a uno basado en vCore, la migración preserva la retención de PITR para asegurar que la política de recuperación de datos de tu aplicación no se vea comprometida.

Uso de Azure Policy para aplicar la redundancia del almacenamiento de copia de seguridad

Si tienes requisitos de residencia de datos que requieren que mantengas todos tus datos en una única región de Azure, puedes hacer cumplir copias de seguridad redundantes por zonas o redundantes localmente para tu base de datos SQL usando Azure Policy.

Azure Policy es un servicio que puede usar para crear, asignar y administrar directivas que aplican reglas a los recursos de Azure. Azure Policy te ayuda a mantener estos recursos en cumplimiento con tus estándares corporativos y acuerdos de nivel de servicio. Para más información, consulte la Introducción a Azure Policy.

Directivas integradas de redundancia del almacenamiento de copia de seguridad

Para hacer cumplir los requisitos de residencia de datos a nivel organizativo, asigna políticas a una suscripción utilizando el portal de Azure o Azure PowerShell.

Por ejemplo, si activas la política "Azure SQL DB debe evitar usar copias de seguridad GRS", los usuarios no pueden crear bases de datos con el almacenamiento predeterminado como almacenamiento globalmente redundante. La política impide que los usuarios utilicen GRS y devuelve el mensaje de error "Configuración del tipo de cuenta de almacenamiento de copia de seguridad a 'Standard_RAGRS' falló durante la creación o actualización de la base de datos."

Para una lista completa de definiciones de políticas integradas para SQL Database, consulte la referencia de políticas.

Contenido relacionado

• Para descubrir otras soluciones de continuidad empresarial de SQL Database, consulte el artículo de información general sobre la continuidad empresarial.
• Para cambiar la configuración de copia de seguridad, consulte Cambiar la configuración.
• Para restaurar una copia de seguridad, consulte Recuperación mediante copias de seguridad o Restauración de una base de datos a un momento dado mediante PowerShell.
• Para más información sobre cómo configurar, administrar y restaurar desde la retención a largo plazo de copias de seguridad automatizadas en Azure Blob Storage, vea Administración de la retención de copia de seguridad a largo plazo.
• Para Azure SQL Managed Instance, consulte Copias de seguridad automatizadas para SQL Managed Instance.