Compartir por

Copias de seguridad automatizadas en Azure SQL Database

  • Artigo

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 copia de seguridad de SQL Server, las bases de datos más grandes tienen tiempos de copia de seguridad y restauración largos. Con el uso de instantáneas, Hiperescala proporciona funcionalidades de copia de seguridad instantáneas y restauración rápida, independientemente del tamaño de la base de datos. Para obtener más información, consulte Copias de seguirdad de Hiperescala.

Frecuencia de copia de seguridad

Azure SQL Database crea:

La frecuencia exacta 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. Cuando una base de datos se restaura, el servicio averigua qué copia de seguridad completa, diferencial o del registro de transacciones es necesario restaurar.

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

Redundancia del almacenamiento de copia de seguridad

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.

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. Estos parámetros se pueden anular. 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 carga de trabajo producción , se establece la redundancia de almacenamiento de copia de seguridad en el almacenamiento con redundancia geográfica, el valor predeterminado.
  • La opción Entorno de carga de trabajo también cambia la configuración inicial del proceso, aunque esto se puede invalidar. 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 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. 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.

Puede configurar la redundancia del almacenamiento de copia de seguridad al crear la base de datos y actualizarla más adelante. Los cambios que hace en una base de datos existente solo se aplican a las copias de seguridad futuras. 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 menos costosa, pero no se recomienda para las aplicaciones que requieren resistencia a interrupciones regionales o una garantía de alta durabilidad de los datos.

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

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

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.
  • La redundancia de almacenamiento de copia de seguridad para bases de datos de Hiperescala solo se puede establecer durante la creación. No se puede modificar esta configuración después de aprovisionar el recurso. Use la replicación geográfica activa para actualizar la configuración de redundancia del almacenamiento de copia de seguridad para una base de datos de Hiperescala existente con un tiempo de inactividad mínimo. Como alternativa, puede usar la copia de base de datos. Obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.

Uso de copia de seguridad

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

  • 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 eliminar la base de datos original y, luego, para que tenga el nombre de la original, cambiar también el de la restaurada. 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. La base de datos eliminada solo se puede restaurar en el mismo servidor donde se creara la original. 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 interrupción regional 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 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 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.

  • Restaure una base de datos desde una copia de seguridad a largo plazo específica de una base de datos independiente o agrupada, si la base de datos se ha configurado con una directiva de 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

Las copias de seguridad automáticas ahora se toman de una réplica secundaria en el nivel de servicio Crítico para la empresa. 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 permanece dedicada a la carga de trabajo principal y 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 se produce un error en 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.
  • Se incluyen sin costo 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.

Nota:

  • Cree una incidencia de soporte técnico de Microsoft para inhabilitar la característica de la instancia.

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.

Propiedad de Copia de seguridad PITR Geo-restore LTR
Tipos de copia de seguridad de SQL Completa, diferencial y registro. Copias replicadas geográficamente más recientes de copias de seguridad de recuperación a un momento dado. Solo copias de seguridad completas.
Objetivo de punto de recuperación (RPO) 10 minutos, en función del tamaño del proceso 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 7 días de forma predeterminada, configurables entre 1 y 35 días (excepto las bases de datos básicas, que se pueden configurar entre 1 y 7 días). Se habilita de manera 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
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 No compatible No se admite3 No se admite3
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 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.
2 Todas las copias de seguridad con restauración a un momento dado se almacenan en el almacenamiento con redundancia geográfica de manera predeterminada; por lo que la restauración geográfica está habilitada de forma predeterminada.
3 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 llevar a cabo una restauración, vea Recuperación de una base de datos mediante copias de seguridad. Puede explorar 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 SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL
Cambio del período de retención de copia de seguridad a largo plazo SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL
Restauración de una base de datos desde un momento dado SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL
Restauración de una base de datos eliminada SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL		 SQL Database
Instancia administrada de SQL

Exportación de una base de datos

Las copias de seguridad automáticas realizadas por el servicio de Azure no están disponibles para descargar ni acceder directamente. Solo se pueden usar para las operaciones de restauración a través de Azure.

Hay alternativas para exportar una instancia de la base de datos de Azure SQL. Cuando necesite exportar una base de datos para archivar o migrar a otra plataforma, puede exportar el esquema de base de datos y los 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. Un archivo BACPAC se puede almacenar en Azure Blob Storage o en una ubicación local y, luego, volver a importarse 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 inmediatamente después de la creación o restauración de una 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 una copia de la base de datos, que normalmente será mayor que una base de datos nueva.

Después de la primera copia de seguridad completa, todas las demás se programan y administran de forma automática. El servicio SQL Database determina el momento exacto en el que se producen todas las copias de seguridad de la base de datos a medida que equilibra la carga de trabajo global del sistema. No se puede cambiar la programación de trabajos de copia de seguridad ni deshabilitarlos.

Importante

  • En una base de datos nueva, restaurada o copiada, la funcionalidad de restauración a un momento dado está disponible cuando se crea la copia de seguridad del registro de transacciones inicial que sigue a la copia de seguridad completa inicial.
  • Las bases de datos de hiperescala se protegen inmediatamente después de la creación, a diferencia de otras bases de datos en las que la copia de seguridad inicial tarda tiempo. La protección es inmediata incluso si la base de datos de Hiperescala se creó con una gran cantidad de datos a través de la copia o restauración. Para obtener más información, consulte Copias de seguridad automatizadas de hiperescala.

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

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 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 las bases de datos no encriptadas con TDE se comprimen.

Azure SQL Database calcula 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 se conservan para proporcionar PITR, aunque la base de datos se haya eliminado. Aunque eliminar y volver a crear una base de datos podría ahorrar costos de almacenamiento y proceso, podría aumentar los costos de almacenamiento de copia de seguridad. El motivo es que el servicio conserva las copias de seguridad de cada base de datos eliminada, cada vez que se elimina.

Supervisión del consumo

En el caso de las bases de datos de núcleo virtual en Azure SQL Database, el almacenamiento que consume cada tipo de copia de seguridad (completa, diferencial y de registro) se notifica en la hoja de supervisión de la base de datos como una métrica independiente. En esta captura de pantalla se muestra cómo supervisar el consumo de almacenamiento de copia de seguridad para una única base de datos.

Captura de pantalla que muestra selecciones de supervisión del consumo de copias de seguridad de bases de datos en Azure Portal.

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

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 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 Database proporciona retención a corto y largo plazo de copias de seguridad. 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

En el caso de todas las bases de datos nuevas, restauradas y copiadas, Azure SQL Database conserva copias de seguridad suficientes para permitir PITR de manera predeterminada en los últimos 7 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.

Las copias de seguridad diferenciales se pueden configurar para que se produzcan 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.

Puede especificar la opción de redundancia de almacenamiento de copia de seguridad para STR al crear la base de datos y, a continuación, cambiarla más adelante. Si cambia la opción de redundancia de copia de seguridad después de crear la base de datos, 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 expire el período 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 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. No se puede cambiar el período de retención de copia de seguridad de una base de datos eliminada.

Importante

Si elimina un servidor, todas las bases de datos de ese servidor también se eliminan y no se pueden recuperar. Un servidor eliminado no se puede restaurar. Pero si ha configurado la retención a largo plazo para una base de datos, no se eliminan las copias de seguridad de LTR. Después, puede usar esas copias de seguridad para restaurar bases de datos en un servidor 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

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 directiva LTR, las copias de seguridad completas se copian de forma automática en otro contenedor de almacenamiento semanalmente.

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 se crearía una copia LTR mensualmente. Para más información sobre LTR, vea Retención a largo plazo.

La actualización de la redundancia de almacenamiento de copia de seguridad para una base de datos existente aplica el cambio solo a las copias de seguridad posteriores realizadas en el futuro y no a las 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. Para estimar el costo del almacenamiento de LTR, se puede usar la calculadora de precios 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 habilitarla en la base de datos restaurada, actualice la base de datos después de crearla. Cuando se restaura a partir de una copia de seguridad LTR, es necesario especificar el objetivo de nivel de servicio de destino.

La retención a largo plazo se puede habilitar para las bases de datos de Hiperescala 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. Póngase en contacto con el soporte técnico de Microsoft para activar la retención de copias de seguridad a largo plazo". En este caso, póngase en contacto con el soporte de Microsoft y cree una incidencia de soporte técnico para solucionarlo.

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

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

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.

Modelo de DTU

En el modelo de DTU, para las bases de datos y los grupos elásticos no hay ningún cargo adicional por el almacenamiento de copia de seguridad PITR para la retención predeterminada de 7 días y más. El precio del almacenamiento de copia de seguridad forma parte del de la base de datos o del grupo.

Importante

En el modelo de DTU, las bases de datos y los grupos elásticos se cobran por el almacenamiento de copia de seguridad LTR en función del almacenamiento real consumido por las copias de seguridad de LTR.

Modelo de núcleos virtuales

Azure SQL Database 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 costo del almacenamiento de copia de seguridad se calcula de forma diferente para las bases de datos de Hiperescala. Para obtener más información, consulte Costos de almacenamiento de copias de seguridad de Hiperescala.

En el caso de las bases de datos únicas, se ofrece una cantidad de almacenamiento de copia de seguridad igual al 100 % del tamaño de almacenamiento de datos máximo de la base de datos sin costo adicional. La siguiente ecuación sirve para calcular el uso de almacenamiento de copia de seguridad facturable total:

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

En el caso de los grupos de bases de datos elásticas, se ofrece una cantidad de almacenamiento de copia de seguridad igual al 100 % del tamaño de almacenamiento del grupo sin costo 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

El almacenamiento total de copia de seguridad facturable, si existe, se cobra en gigabytes al mes, según la tasa de redundancia de almacenamiento de copia de seguridad que ha usado. 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, 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 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 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 Database 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 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 el último escenario en bases de datos de mayor tamaño, una optimización en el servicio crea una copia de seguridad completa en lugar de una diferencial si una copia de seguridad diferencial tuviera un tamaño excesivo. Esto 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 grupo elástico/único) en el caso de una sola base de datos o un grupo de bases de datos elásticas. Los medidores solo se muestran si existe el consumo de almacenamiento de copia de seguridad.

    Para supervisar los costos de copia de seguridad PITR, en la lista desplegable, seleccione ltr backup storage (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 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 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.

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

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 más información sobre TDE, vea Cifrado de datos transparente con SQL Database.

Integridad de copia de seguridad

El equipo de ingeniería de Azure SQL prueba permanentemente y de manera automática la restauración de las copias de seguridad de bases de datos automatizadas. Tras la restauración a un momento dado, las bases de datos también reciben comprobaciones de integridad de DBCC CHECKDB.

Los problemas encontrados durante la comprobación de integridad producen una alerta para el equipo de ingeniería. Para más información, consulte Integridad de datos en SQL Database.

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.

Cumplimiento normativo

Al migrar la base de datos de un nivel de servicio basado en DTU a un nivel de servicio basado en núcleos virtuales, se conserva la retención PITR para garantizar que la directiva de recuperación de datos de la aplicación no se ponga en peligro. 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.

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 local o de zona para su instancia de SQL Database 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 habilita la directiva "Azure SQL DB debe evitar el uso de la copia de seguridad de GRS", las bases de datos no se pueden crear con el almacenamiento predeterminado como almacenamiento con redundancia global y se impediría que los usuarios usen GRS con el mensaje de error "Configuración del tipo de cuenta de almacenamiento de copia de seguridad en "Standard_RAGRS" durante la creación o actualización de la base de datos".

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

Importante

Las directivas de Azure no se aplican cuando la base de datos se crea mediante T-SQL. Para especificar 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.

Contenido relacionado