Compartir a través de

Copias de seguridad automatizadas en Azure SQL Managed Instance

  • Artículo

Se aplica a: Azure SQL Managed Instance

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

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é son las copias de seguridad automatizadas de bases 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. Con Azure SQL Managed Instance, Microsoft administra automáticamente las copias de seguridad del motor de base de datos de SQL Server y se almacenan en cuentas de almacenamiento de Azure administradas por Microsoft.

Use estas copias de seguridad para restaurar la base de datos a un punto específico en el tiempo dentro del período de retención configurado, hasta 35 días. Sin embargo, si sus normas de protección de datos exigen que las copias de seguridad estén disponibles durante un periodo prolongado (hasta 10 años), puede configurar políticas de retención a largo plazo (LTR) por cada base de datos.

Frecuencia de copia de seguridad

Azure SQL Managed Instance crea:

La frecuencia de las copias de seguridad del registro de transacciones se basa en el tamaño de proceso y en la cantidad de actividad de la base de datos. Los registros de transacciones se toman aproximadamente cada 10 minutos, pero pueden variar. Al restaurar una base de datos, el servicio determina qué copias de seguridad completas, diferenciales y del registro de transacciones deben restaurarse, en su orden respectivo.

Precaución

Las copias de seguridad completas automáticas se inician una vez a la semana en función de una programación determinada por Microsoft. Las copias de seguridad iniciadas por el usuario tienen prioridad sobre las copias de seguridad completas automáticas, por lo que una copia de seguridad de solo copia de ejecución prolongada puede afectar al tiempo de la siguiente copia de seguridad completa automática.

Redundancia del almacenamiento de copia de seguridad

De manera predeterminada, Azure SQL Managed Instance almacena las copias de seguridad en blobs de almacenamiento con redundancia geográfica 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 la instancia en otra región en caso de desastre.

El mecanismo de redundancia de almacenamiento almacena varias copias de los datos para que esté protegida frente a eventos planeados y no planeados. Estos eventos podrían incluir errores transitorios de hardware, cortes de red o de energía o desastres naturales masivos.

Para asegurarse de que las copias de seguridad permanecen dentro de la misma región donde se implementa la base de datos, puede cambiar la redundancia del almacenamiento de copia de seguridad del almacenamiento con redundancia geográfica predeterminada a otros tipos de almacenamiento que mantienen los datos dentro de la región. Para obtener más información acerca de la redundancia de almacenamiento, consulte Redundancia de datos.

Puede configurar la redundancia del almacenamiento de copia de seguridad al crear la instancia y actualizarla más adelante en el nivel de instancia. Los cambios que hace en una instancia existente solo se aplican a las copias de seguridad futuras. Una vez actualizada la redundancia del almacenamiento de copia de seguridad de una instancia existente, los cambios pueden tardar hasta 24 horas en aplicarse. Los cambios realizados en la redundancia de almacenamiento de copia de seguridad solo se aplican a las copias de seguridad a corto plazo. Las directivas de retención a largo plazo heredan la opción de redundancia de las copias de seguridad a corto plazo cuando se crea la directiva. La opción de redundancia persiste para las copias de seguridad a largo plazo, incluso si la opción de redundancia para las copias de seguridad a corto plazo cambia posteriormente.

Nota:

Cambiar la redundancia de copia de seguridad es una operación de administración de actualizaciones que inicia una conmutación por error.

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 replicación menos costosa, pero no lo recomendamos para las aplicaciones que requieran alta disponibilidad o durabilidad.

    Diagrama que muestra la opción de almacenamiento con redundancia local (LRS).

  • 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 en determinadas regiones.

    Diagrama que muestra la opción de almacenamiento con redundancia de zona (ZRS).

  • 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. Luego copia los datos de forma asincrónica en una única ubicación física en la región secundaria emparejada.

    El resultado es el siguiente:

    • Tres copias sincrónicas en la región primaria dentro de una sola zona de disponibilidad.
    • Tres copias síncronas en la región emparejada dentro de una única zona de disponibilidad que se copiaron de la región primaria a la región secundaria de forma asíncrona.

    Diagrama que muestra la opción de almacenamiento con redundancia geográfica (GRS).

  • Almacenamiento con redundancia de zona geográfica (GZRS) : combina la alta disponibilidad que proporciona la redundancia entre zonas de disponibilidad con la protección frente a interrupciones regionales que proporciona la replicación geográfica. Los datos en una cuenta de GZRS se copian en tres zonas de disponibilidad de Azure en la región primaria. Los datos también se replican en una región geográfica secundaria para la protección frente a desastres regionales. En esa región, también tiene tres copias síncronas en una única zona de disponibilidad que se copiaron de la región primaria a la región secundaria de forma asíncrona.

    Diagrama en el que se muestra la opción de almacenamiento con redundancia de zona geográfica (GZRS).

Advertencia

  • La restauración geográfica se deshabilita en cuanto se actualiza una base de datos para usar almacenamiento con redundancia local o redundancia de zona.
  • Los diagramas de redundancia de almacenamiento muestran todas las regiones con varias zonas de disponibilidad (multi-az). Sin embargo, hay algunas regiones que proporcionan solo una sola zona de disponibilidad y no admiten ZRS ni GZRS.

Uso de copia de seguridad

Puede utilizar estas copias de seguridad para realizar lo siguiente:

  • Restaurar una base de datos existente a un momento en el tiempo pasado 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 la misma instancia que la base de datos original o una instancia diferente en la misma suscripción y región. Usa un nombre diferente para evitar sobrescribir la base de datos original. También puede usar Azure Portal para restaurar la copia de seguridad de la base de datos a un momento dado en una instancia de una suscripción diferente de la instancia de origen.

    Una vez terminada la restauración, puede eliminar la base de datos original. Como alternativa, puede cambiar el nombre de la base de datos original y cambiar el nombre de la base de datos restaurada para que tenga el nombre de la original.

  • Restaurar una base de datos eliminada al momento dentro del período de retención, incluyendo el momento de su eliminación. Puede restaurar la base de datos eliminada en la misma instancia administrada en la que se realizó la copia de seguridad, otra instancia en la misma suscripción o en una suscripción diferente a la instancia de origen. Antes de eliminar una base de datos, el servicio toma una copia de seguridad del registro de transacciones final, para evitar la pérdida de datos.

  • Restaurar una base de datos en otra región geográfica. La restauración geográfica le permite recuperarse de un desastre en una región geográfica cuando no puede acceder a la base de datos o a las copias de seguridad en la región primaria. Crea una base de datos en cualquier instancia administrada 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 usa copias de seguridad con replicación geográfica para una base de datos, puede cambiarlo configurando la redundancia de almacenamiento de copia de seguridad.

  • Restaurar una base de datos a partir de una copia de seguridad a largo plazo de una base de datos, si la base de datos tiene una política LTR configurada. 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 obtener más información, revise la página de información general de retención a largo plazo.

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.

Propiedades de copia de seguridad PITR Geo-restore LTR
Tipos de copia de seguridad de SQL Copias de seguridad completas, diferenciales y del registro de transacciones. Copias replicadas de copias de seguridad de recuperación a un momento dado. Solo copias de seguridad completas.
Objetivo de punto de recuperación (RPO) Aproximadamente 10 minutos, según el tamaño del cálculo y la cantidad de actividad de la base de datos. Hasta 1 hora, en función de la replicación geográfica. 1 Una semana (o directiva del usuario).
Objetivo de tiempo de recuperación (RTO) La restauración suele tardar menos de 12 horas, pero podría tardar más en función del tamaño y la actividad. Consulte Recuperación. La restauración suele tardar menos de 12 horas, pero podría tardar más en función del tamaño y la actividad. Consulte Recuperación. La restauración suele tardar menos de 12 horas, pero podría tardar más en función del tamaño y la actividad. Consulte Recuperación.
Retención De 1 a 35 días. Se habilita de forma predeterminada, igual que el origen. 2 Esta opción no está habilitada de forma predeterminada. La retención es de hasta 10 años.
Almacenamiento de Azure Con redundancia de zona de forma predeterminada. Opcionalmente, se puede configurar el almacenamiento con redundancia local o de zona. Disponible cuando la redundancia del almacenamiento de copia de seguridad con restauración a un momento dado está establecida con redundancia geográfica. No disponible cuando el almacén de copia de seguridad PITR es almacenamiento con redundancia de zona o con redundancia local. Con redundancia de zona de forma predeterminada. Se puede configurar el almacenamiento con redundancia local o de zona.
Configuración de copias de seguridad como inmutables No se admite No compatible No compatible
Directiva de actualización3 Debe coincidir o actualizarse Debe coincidir o actualizarse Debe coincidir o actualizarse
Restauración de una nueva base de datos en la misma región Compatible Admitido Compatible
Restauración de una nueva base de datos en otra región No compatible Compatible con cualquier región de Azure Compatible con cualquier región de Azure
Restauración de una base de datos en otra suscripción Compatible No compatible.4 No compatible.4
Restauración a través de Azure Portal Sí Sí Sí
Restauración a través de PowerShell Sí Sí Sí
Restauración a través de Azure CLI Sí Sí Sí

1 Para aplicaciones críticas que requieren grandes bases de datos y deben garantizar la continuidad del negocio, consulta grupos de conmutación por error.
2 Todas las copias de seguridad PITR se almacenan por defecto en almacenamiento georredundante, lo que significa que la georrestauración está activada por defecto.
3 Las copias de seguridad de base de datos tomadas de instancias configuradas con la directiva de actualización de SQL Server 2022 se pueden restaurar en instancias configuradas con la directiva de actualización de SQL Server 2022 o la directiva de actualización siempre actualizada. Las copias de seguridad de base de datos tomadas de instancias configuradas con la directiva de actualización siempre actualizada se pueden restaurar en instancias configuradas también con la directiva de actualización siempre actualizada.
4 La solución alternativa consiste en restaurar a un nuevo servidor y utilizar la función Mover recursos para mover el servidor a otra suscripción.

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

Para llevar a cabo una restauración, vea Recuperación de una base de datos mediante copias de seguridad. Puede probar las operaciones de configuración de copia de seguridad y restauración con los ejemplos siguientes.

Operación Azure portal Azure CLI Azure PowerShell
Cambio del período de retención de copia de seguridad Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance
Cambio del período de retención de copia de seguridad a largo plazo Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance
Restauración de una base de datos desde un momento dado Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance
Restauración de una base de datos eliminada Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance Bases de datos de SQL / SQL Managed Instance
Restauración de una base de datos desde Azure Blob Storage Instancia administrada de SQL

Programación de copias de seguridad automáticas

Azure SQL Managed Instance administrada automáticamente las copias de seguridad mediante la creación de copias de seguridad completas, diferenciales y del registro de transacciones. Este proceso se rige por una programación interna.

Copia de seguridad inicial

  • Bases de datos nuevas: la primera copia de seguridad completa se inicia inmediatamente después de la creación o restauración de una base de datos, o después de cambios en la redundancia de copias de seguridad. Normalmente, esta copia de seguridad se completa en un plazo de 30 minutos, aunque puede tardar más tiempo en bases de datos mayores.

  • Bases de datos restauradas: la duración de la copia de seguridad inicial de las bases de datos restauradas varía y depende del tamaño de la base de datos. Las bases de datos restauradas o las copias de base de datos, que a menudo son mayores, pueden requerir más tiempo para la copia de seguridad inicial.

Importante

La primera copia de seguridad completa de una nueva base de datos tiene prioridad sobre otras copias de seguridad de base de datos, por lo que es la primera copia de seguridad realizada durante la primera ventana de copia de seguridad completa. Si la ventana de copia de seguridad completa ya está activa y se realiza una copia de seguridad de otras bases de datos, la primera copia de seguridad completa de la nueva base de datos se realiza inmediatamente después de completar la copia de seguridad completa de otra base de datos.

Copias de seguridad completas programadas

  • Programación semanal: el sistema establece un período de copia de seguridad completa semanal para toda la instancia.
  • Período de copia de seguridad completa: se trata de un período designado en el que se realizan copias de seguridad completas. Aunque el sistema tiene como objetivo completar copias de seguridad completas dentro de este período, si es necesario, la copia de seguridad puede continuar más allá de la hora programada hasta que se complete.
  • Programación adaptable: el algoritmo de copia de seguridad evalúa el impacto del período de copia de seguridad sobre la carga de trabajo aproximadamente una vez a la semana, basándose en el uso de CPU y el rendimiento de E/S como indicadores. En función de la carga de trabajo de la semana anterior, es posible que se ajuste el período de copia de seguridad completa.
  • Configuración de usuario: es fundamental tener en cuenta que los usuarios no pueden modificar ni deshabilitar la programación de copia de seguridad.

Importante

Para una base de datos nueva, restaurada o copiada, la capacidad de restauración a un momento dado (PITR) está disponible cuando se completa la copia de seguridad inicial del registro de transacciones que sigue a la copia de seguridad completa inicial.

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.

Las programaciones de copias de seguridad de Azure SQL Managed Instance incluyen una copia de seguridad completa cada semana. Para proporcionar PITR en todo el período de retención, el sistema debe almacenar copias de seguridad completas, diferenciales y del registro de transacciones durante una semana más transcurrido el período de retención configurado.

En otras palabras, para un momento dado durante el período de retención, debe haber una copia de seguridad completa que sea más antigua que la hora 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 copias de seguridad que ya no sean necesarias para proporcionar la funcionalidad PITR se eliminan automáticamente. Como las copias de seguridad diferenciales y las del registro necesitan una copia de seguridad completa anterior para que se puedan restaurar, los tres tipos de copia de seguridad se depuran en conjuntos semanales.

Para todas las bases de datos, incluidas las cifradas con TDE, las copias de seguridad diferenciales se comprimen para reducir los costos y la compresión del almacenamiento de copia de seguridad. La relación media de compresión de copia de seguridad es de 3 a 4 veces. Sin embargo, puede ser significativamente 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.

Importante

En el caso de las bases de datos cifradas con TDE, los archivos de copia de seguridad de registros no se comprimen por motivos de rendimiento. Las copias de seguridad de registros para bases de datos no cifradas con TDE se comprimen.

Azure SQL Managed Instance calculan el almacenamiento de copia de seguridad total usado como un valor acumulativo. Cada hora, este valor se notifica a la canalización de facturación de Azure. 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 la base de datos, el consumo disminuye a medida que las copias de seguridad caducan 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.

Importante

Las copias de seguridad de una base de datos eliminada se conservan para la restauración a un momento dado (PITR), lo que puede aumentar los costos de almacenamiento a medida que se mantienen las copias de seguridad aunque se elimine la base de datos. Para reducir costes, puede establecer el periodo de conservación de las copias de seguridad en 0 días, pero sólo para las bases de datos eliminadas. En el caso de las bases de datos normales, el período de retención mínimo es de 1 día.

Ajuste del consumo del almacenamiento de copia de seguridad

No se cobra el consumo de almacenamiento de copia de seguridad hasta el tamaño máximo de los datos de una base de datos. El exceso de consumo del almacenamiento de copia de seguridad depende de la carga de trabajo y del tamaño máximo de las bases de datos individuales. Considere la posibilidad de poner en marcha algunas de las siguientes técnicas de optimización para reducir el consumo de almacenamiento de copia de seguridad:

  • Reduzca el período de retención de copias de seguridad de la base de datos 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 los costos de exceso de almacenamiento de copia de seguridad siempre son elevados, le conviene valorar aumentar el almacenamiento de datos para ahorrar en 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 Managed Instance proporciona retención de copias de seguridad a corto y largo plazo. La retención a corto plazo permite PITR 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 Managed Instance conservan copias de seguridad suficientes para permitir PITR en los últimos siete días de forma predeterminada. Esta configuración se puede cambiar en el intervalo de 1 a 35 días. El servicio toma copias de seguridad completas, diferenciales y de registro periódicas para garantizar que las bases de datos se pueden restaurar a cualquier momento dado dentro del período de retención definido para la base de datos o la instancia administrada.

Puede especificar su opción de redundancia de almacenamiento de copia de seguridad para STR cuando cree su instancia, y cambiarla más tarde. Si cambia la opción de redundancia de copia de seguridad después de crear la instancia, las nuevas copias de seguridad usarán la nueva opción de redundancia. Las copias de seguridad realizadas con la opción de redundancia STR anterior no se mueven ni copian. Se dejan en la cuenta de almacenamiento original hasta que expira el periodo de conservación. Como se describe en Consumo de almacenamiento de copias de seguridad, las copias de seguridad almacenadas para permitir PITR podrían ser más antiguas que el periodo de retención para garantizar una restauración precisa de los datos.

Si elimina una base de datos, el sistema conserva las copias de seguridad de la misma manera que en una base de datos en línea con su período de retención específico. Sin embargo, para una base de datos eliminada, el período de retención se actualiza de 1 a 35 días a 0 a 35 días, lo que permite eliminar las copias de seguridad manualmente. 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.

Importante

Si elimina una instancia administrada, también se eliminan todas las bases de datos en esa instancia gestionada y no se pueden recuperar. No se puede restaurar una instancia administrada que se ha eliminado. Pero si ha configurado la retención a largo plazo para una instancia administrada, no se eliminan las copias de seguridad de LTR. Después, puede usar esas copias de seguridad para restaurar bases de datos en una instancia administrada diferente de la misma suscripción, a un momento dado en el que se realizó una copia de seguridad ltr. Para más información, consulte Restaurar copia de seguridad a largo plazo.

Retención a largo plazo (LTR)

Con SQL Managed Instance, puede configurar el almacenamiento de copias de seguridad LTR completas de hasta 10 años en Azure Blob Storage. Una vez configurada la directiva LTR, las copias de seguridad completas se copian automáticamente en un contenedor de almacenamiento diferente.

Para satisfacer los distintos requisitos de cumplimiento, puede seleccionar otros períodos de retención para copias de seguridad completas semanales, mensuales o anuales. La frecuencia depende de la directiva. Por ejemplo, al establecer W=0, M=1, Y=0 se crearía una copia LTR mensualmente. Para más información sobre LTR, vea Retención a largo plazo.

La redundancia del almacenamiento de copia de seguridad LTR en Azure SQL Managed Instance se hereda de la redundancia de almacenamiento de copia de seguridad usada por STR en el momento en que se define la directiva LTR. No se puede cambiar, aunque la redundancia del almacenamiento de copia de seguridad de STR cambie en el futuro.

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. Para estimar el costo del almacenamiento de LTR, se puede usar la calculadora de precios de LTR.

Costos de almacenamiento de copia de seguridad

Azure SQL Managed Instance calculan el almacenamiento de copia de seguridad facturable total como un valor acumulativo entre todos los archivos de copia de seguridad. Cada hora, este valor se notifica a la canalización de facturación de Azure. La canalización suma este uso por horas para obtener el consumo de almacenamiento de copia de seguridad al final de cada mes.

Si se elimina una base de datos, el consumo de almacenamiento de copia de seguridad disminuirá gradualmente a medida que las copias de seguridad antiguas expiren y se eliminen. Como las copias de seguridad diferenciales y las del registro necesitan una copia de seguridad completa anterior para que se puedan restaurar, los tres tipos de copia de seguridad se depuran en conjuntos semanales. Después de que se hayan eliminado todas las copias de seguridad, se detiene la facturación.

El precio del almacenamiento de copia de seguridad varía. Depende de la opción de redundancia de almacenamiento de copia de seguridad elegida y de la región. El almacenamiento de copia de seguridad se cobra en función de los gigabytes consumidos al mes, a la misma tarifa para todas las copias de seguridad.

La redundancia del almacenamiento de copia de seguridad afecta a los costes de copia de seguridad de la siguiente manera:

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2
  • Geo-zone-redundant price = published price x 3.4

Para ver los precios, revise la página de precios de Azure SQL Managed Instance.

Nota

Una factura de Azure solo muestra el exceso de almacenamiento de copia de seguridad consumido, no todo el consumo de almacenamiento de copia de seguridad. Por ejemplo, en un escenario hipotético, si ha aprovisionado 4 TB de almacenamiento de datos, obtendrá 4 TB de espacio de almacenamiento de copia de seguridad disponible. Si usas un total de 5,8 TB de espacio de almacenamiento de copia de seguridad, la factura de Azure solo muestra 1,8 TB, ya que solo se te cobrará por el exceso de almacenamiento de copia de seguridad que has usado.

En el caso de las instancias administradas, el tamaño total del almacenamiento de copia de seguridad facturable se agrega en el nivel de instancia y se calcula de la siguiente manera:

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

El almacenamiento total de copia de seguridad facturable, si existe, se cobra en gigabytes al mes por cada región, según la tasa de redundancia de almacenamiento de copia de seguridad que ha usado. Este consumo del almacenamiento de copia de seguridad depende de la carga de trabajo y del tamaño de las bases de datos individuales 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 tendrán mayores cargos de copia de seguridad.

Como ejemplo simplificado, imagine que una base de datos ha acumulado 744 GB de almacenamiento de copia de seguridad y esta cantidad permanece constante durante todo un mes porque la base de datos está 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 Managed Instance 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 suma este consumo y refleja un uso de 744 GB durante 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. SQL Managed Instance notificaría un uso de 1 GB para las horas 1 a 372 (la primera mitad del mes). Notificaría un uso de 2 GB para las horas 373 a 744 (la segunda mitad del mes). Este uso se sumaría a una factura final de 1116 GB por mes. Los costes de retención no aumentan inmediatamente. Aumentan gradualmente cada día, ya que las copias de seguridad crecen hasta alcanzar el período máximo de retención de 14 días.

Los escenarios reales de facturación de copia de seguridad son más complejos. Como la tasa de cambios en la base de datos depende de la carga de trabajo y varía con el tiempo, el tamaño de cada copia de seguridad diferencial y de registros también variará. 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. Después de que un conjunto anterior de copias de seguridad completas, diferenciales y de registro agote la antigüedad de las copias de seguridad de registros.

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 recompilación del índice se incluirán a continuación:

  • 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.

Para reducir el tamaño de todas las copias de seguridad diferenciales, las copias de seguridad diferenciales excesivamente grandes que superan los 750 GB y equivalen al 75 % del tamaño de la base de datos se convierten en copias de seguridad completas, en caso de que la última copia de seguridad completa se realizara más de 24 horas antes.

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 instancia administrada de SQL para una instancia administrada.

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

  4. Para supervisar los costos de copia de seguridad de PITR, en la lista desplegable, seleccione Almacenamiento de copia de seguridad de pitr de instancia administrada. Los medidores solo se muestran 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 ltr de instancia administrada de sql. Los medidores solo se muestran 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.

Captura de pantalla en la que se muestra un análisis de costos de almacenamiento de copia de seguridad.

Importante

Los medidores solo son visibles para los contadores que están en uso actualmente. Si un contador no está disponible, es probable que la categoría no se esté usando actualmente. Por ejemplo, los contadores de instancias administradas no estarán presentes para los clientes que no tengan implementada una instancia administrada. Del mismo modo, los contadores de almacenamiento no estarán visibles para los recursos que no consuman almacenamiento. Si no hay ningún consumo del almacenamiento de copia de seguridad PITR o de LTR, estos medidores no serán visibles.

Copias de seguridad cifradas

Si la base de datos se cifra con TDE, las copias de seguridad se cifran de forma automática 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 obtener más información sobre TDE, vea Cifrado de datos transparente con SQL Managed Instance.

Microsoft es totalmente responsable de mantener y rotar claves para las bases de datos con claves administradas por el servicio (SMK). Microsoft puede restaurar las copias de seguridad, ya sea PITR o LTR, tomadas de instancias que tienen TDE con SMK habilitado.

Azure Storage cifra automáticamente las copias de seguridad automáticas almacenadas en cuentas de almacenamiento administradas por Azure. Más información acerca del cifrado de Azure Storage para datos en reposo.

Integridad de copia de seguridad

Todas las copias de seguridad de base de datos se llevan a cabo con la opción CHECKSUM para proporcionar una mayor integridad de copia de seguridad. Las pruebas automáticas de copias de seguridad automatizadas de bases de datos por parte del equipo de ingeniería de Azure SQL no están disponibles actualmente para Azure SQL Managed Instance. Programe la restauración de copias de seguridad de prueba y DBCC CHECKDB en las bases de datos en SQL Managed Instance alrededor de la carga de trabajo.

Aunque el sistema no comprueba la integridad de las copias de seguridad, todavía hay protección integrada de las copias de seguridad que alertan a Microsoft en caso de que haya un problema con el servicio de copia de seguridad. Además, Microsoft te proporciona asistencia si se produce un problema con una copia de seguridad como, por ejemplo, si no se realiza una copia de seguridad completa, el servicio de copia de seguridad está bloqueado, una copia de seguridad de registros está fuera del Acuerdo de Nivel de Servicio, o si el hardware o el software de copia de seguridad están dañados.

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

Si tiene que cumplir requisitos de residencia de datos que le exigen que mantenga todos los datos en una única región de Azure, es posible que desee aplicar copias de seguridad con redundancia con redundancia local o de zona para su instancia de SQL Database o Managed Instance mediante 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 le permite mantener esos recursos conforme a lo establecido en los estándares corporativos y los contratos de nivel de servicio. Para más información, consulte la Introducción a Azure Policy.

Directivas de redundancia del almacenamiento de copia de seguridad integradas

Para aplicar los requisitos de residencia de datos en un nivel organizativo, puede asignar directivas a una suscripción mediante el Azure Portal o el Azure PowerShell. Por ejemplo, si asigna la siguiente directiva integrada en el nivel de suscripción o grupo de recursos, los usuarios de la suscripción no podrán crear una instancia administrada con almacenamiento de copia de seguridad con redundancia geográfica a través de la Azure Portal o Azure PowerShell: Las instancias administradas de SQL deben evitar el uso de redundancia de copia de seguridad grS.

Para obtener una lista completa de las definiciones de directivas integradas para SQL Managed Instance, revise la referencia de directiva.

Importante

Las directivas de Azure no se aplican cuando la base de datos se crea mediante T-SQL. Para aplicar la residencia de datos al crear una base de datos mediante T-SQL, use "LOCAL" o "ZONE" como entrada del parámetro BACKUP_STORAGE_REDUNDANCY en la instrucción CREATE DATABASE.

Cumplimiento normativo

Si el período de retención predeterminado no satisface los requisitos de cumplimiento, puede cambiar el período de retención PITR. Para más información, vea Cambio del período de retención de copia de seguridad PITR.

Nota

En el artículo Cambio de la configuración de copia de seguridad automatizada se indican los pasos para eliminar los datos personales del dispositivo o del servicio y puede utilizarse para cumplir con sus obligaciones según el Reglamento general de protección de datos (RGPD). Para obtener información general sobre RGPD, consulte Información sobre los procedimientos recomendados para el cumplimiento del RGPD y la sección RGPD del portal de confianza de servicios.

Pasos siguientes