Copias de seguridad automatizadas para bases de datos de Hiperescala

Se aplica a: Azure SQL Database

En este artículo se explica la característica de copia de seguridad automatizada con bases de datos de Hiperescala en Azure SQL Database.

Las bases de datos de Hiperescala usan una arquitectura única con niveles de rendimiento de proceso y almacenamiento altamente escalables. Las copias de seguridad de Hiperescala se basan en instantáneas y son casi instantáneas. Las copias de seguridad de registros se guardan en el almacenamiento de Azure a largo plazo durante el período de retención de copia de seguridad.

Una arquitectura de Hiperescala no requiere copias de seguridad completas, diferenciales ni de registros. Por lo tanto, la frecuencia de copia de seguridad, los costos de almacenamiento, la programación, la redundancia de almacenamiento y las funcionalidades de restauración difieren de otras bases de datos de Azure SQL Database.

Rendimiento de copias de seguridad y restauración en SQL Server

La separación del almacenamiento y los procesos permite a Hiperescala insertar operaciones de copia de seguridad y restauración en la capa de almacenamiento para eliminar el consumo de recursos en las replica de proceso. Las copias de seguridad de base de datos no afectan al rendimiento de la réplica de proceso principal o la secundaria.

Las operaciones de copia de seguridad y restauración de bases de datos de Hiperescala son rápidas independientemente del tamaño de los datos debido al uso de instantáneas de almacenamiento. La copia de seguridad es prácticamente instantánea.

Una base de datos se puede restaurar a cualquier momento dado dentro de su período de retención de copia de seguridad al:

1. Revertir a instantáneas de archivo aplicables.
2. Aplicar registros de transacciones para que la base de datos restaurada sea coherente transaccionalmente.

Por lo tanto, la restauración no es una operación de tamaño de datos que permanece igual. La restauración de una base de datos de Hiperescala dentro de la misma región de Azure finaliza en minutos en lugar de horas o días, incluso para bases de datos de varios terabytes.

Cambiar la redundancia de almacenamiento al emitir una restauración puede dar lugar a tiempos de restauración más largos, ya que la restauración es el tamaño de los datos y, por tanto, el tiempo es proporcional al tamaño de la base de datos.

La creación de nuevas bases de datos mediante la restauración de una copia de seguridad existente o la copia de la base de datos también aprovecha la separación de proceso y almacenamiento en Hiperescala. Puede crear copias con fines de desarrollo o pruebas, incluso bases de datos de varios terabytes, en cuestión de minutos dentro de la misma región cuando usa el mismo tipo de almacenamiento.

Retención de copias de seguridad

La retención de copias de seguridad a corto plazo predeterminada para las bases de datos de Hiperescala es de 7 días.

La retención a corto plazo de copias de seguridad en el rango de 1 a 35 días y la capacidad de retención de copias de seguridad a largo plazo (LTR) para bases de datos de Hiperescala está disponible con carácter general desde septiembre de 2023. Para obtener más información, consulte Retención a largo plazo: Azure SQL Database y Azure SQL Managed Instance.

Programación de copias de seguridad

No hay copias de seguridad tradicionales completas, diferenciales y de registro de transacciones para las bases de datos de Hiperescala. En su lugar, se toman instantáneas normales de almacenamiento de archivos de datos.

Los registros de transacciones generados se conservan tal y como están durante el período de retención configurado. En el momento de la restauración, los registros de transacciones pertinentes se aplican a la instantánes de almacenamiento restaurada. Esto genera una base de datos coherente en sus transacciones sin pérdidas de datos en el momento indicado dentro del período de retención.

Supervisar el consumo del almacenamiento de copia de seguridad

En Hiperescala, las métricas de Azure Monitor notifican la siguiente información de consumo:

• Tamaño de almacenamiento de copia de seguridad de datos (tamaño de copia de seguridad de instantáneas)
• Tamaño de almacenamiento de datos (tamaño de base de datos asignado)
• Tamaño de almacenamiento de copia de seguridad de registros (tamaño de copia de seguridad del registro de transacciones)

Para ver las métricas de almacenamiento de datos y copia de seguridad en Azure Portal, siga estos pasos:

1. Vaya a la base de datos Hiperescala cuyas métricas de almacenamiento de datos y copia de seguridad desea supervisar.
2. Seleccione la página Métricas en la sección Supervisión.
3. En la lista desplegable Métrica, seleccione las métricas Almacenamiento de copia de seguridad de datos, Tamaño de almacenamiento de datos y Almacenamiento de copia de seguridad de registros con la regla de agregación correspondiente.

Reducir el consumo del almacenamiento de copia de seguridad

El consumo de almacenamiento de copia de seguridad para una base de datos de Hiperescala depende del período de retención, la elección de la región, la redundancia del almacenamiento de copia de seguridad y el tipo de carga de trabajo. 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 en una base de datos de Hiperescala:

• 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 el mantenimiento de índices, con más frecuencia de lo que necesita. Para obtener más información sobre el mantenimiento de índices, consulte Optimización del mantenimiento de índices para mejorar el rendimiento de las consultas y reducir el consumo de recursos.
• Para las operaciones de carga de datos de gran tamaño, considere la posibilidad de usar la compresión de datos cuando corresponda.
• En la lógica de aplicación, use la base de datos tempdb en lugar de tablas permanentes para almacenar resultados temporales o datos transitorios.
• Use el almacenamiento de copia de seguridad con redundancia local o con redundancia de zona cuando la funcionalidad de restauración geográfica no sea necesaria (por ejemplo, para entornos de desarrollo y pruebas).

Costos de almacenamiento de copia de seguridad

El costo del almacenamiento de copia de seguridad de Hiperescala depende de la elección de la región y la redundancia del almacenamiento de copia de seguridad. También depende del tipo de carga de trabajo.

Es más probable que las cargas de trabajo con mucha escritura cambien las páginas de datos con frecuencia, lo que da lugar a instantáneas de almacenamiento más grandes. Estas cargas de trabajo también generan más registros de transacciones, lo que contribuye a los costos generales de copia de seguridad. El almacenamiento de copia de seguridad se cobra en función de los gigabytes consumidos al mes. Para obtener información detallada acerca de los precios, consulte la página de precios de Azure SQL Database.

En el caso de Hiperescala, el almacenamiento de copia de seguridad facturable se calcula de la siguiente manera:

Total billable backup storage size = (data backup storage size + log backup storage size)

El tamaño del almacenamiento de datos no se incluye en la copia de seguridad facturable, porque ya se factura como almacenamiento de base de datos asignado.

Las bases de datos de Hiperescala eliminadas conllevan costos de copia de seguridad para admitir la recuperación en un momento dado antes de su eliminación. En el caso de una base de datos de Hiperescala eliminada, el almacenamiento de copia de seguridad facturable se calcula de la siguiente manera:

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

El tamaño del almacenamiento de datos se incluye en la fórmula, porque el almacenamiento de base de datos asignado no se factura por separado para una base de datos eliminada. En el caso de una base de datos eliminada, los datos se almacenan después de la eliminación para habilitar la recuperación durante el período de retención de copia de seguridad configurado.

El almacenamiento de copia de seguridad facturable para una base de datos eliminada se reduce gradualmente con el tiempo después de su eliminación. Se convierte en cero cuando las copias de seguridad ya no se conservan y la recuperación ya no es posible. Si se trata de una eliminación permanente y ya no necesita copias de seguridad, puede optimizar los costos reduciendo la retención antes de eliminar la base de datos.

Supervisión de los costos de copia de seguridad

Para comprender los costos de almacenamiento de copia de seguridad:

1. En Azure Portal, vaya a Administración de costos + facturación.

2. Seleccione Cost Management>Análisis de costos.

3. Para Ámbito, seleccione la suscripción deseada.

4. Filtre por el período de tiempo y el servicio que le interesen siguiendo estos pasos:

   1. Agregue un filtro para el nombre de servicio.
   2. Seleccione sql-database en la lista desplegable.
   3. Agregue otro filtro para Medidor.
   4. Para supervisar los costos de copia de seguridad de la recuperación a un momento dado, seleccione Datos almacenados: Copia de seguridad: RA en la lista desplegable.

La siguiente captura de pantalla le muestra un ejemplo de análisis de costo.

Redundancia de almacenamiento de copia de seguridad y datos

Hiperescala admite redundancia de almacenamiento configurable. Al crear una base de datos de Hiperescala, puede elegir el tipo de almacenamiento preferido: almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS), almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) o almacenamiento con redundancia local (LRS).

• Almacenamiento con redundancia de zona geográfica: copia las copias de seguridad de forma sincrónica en tres zonas de disponibilidad de Azure en la región primaria. similar al almacenamiento con redundancia de zona (ZRS). Además, copia los datos de forma asincrónica en una única ubicación física en la región secundaria emparejada. Está disponible actualmente solo en determinadas regiones.

Para obtener más información sobre cómo se replican las copias de seguridad para otros tipos de almacenamiento, consulte Redundancia del almacenamiento de copia de seguridad.

Dado que Hiperescala usa instantáneas de almacenamiento para copias de seguridad, los datos y las copias de seguridad comparten la misma cuenta de almacenamiento. Como resultado, la redundancia del almacenamiento de copia de seguridad seleccionada se aplica tanto a los datos como a las copias de seguridad.

Nota:

Considere cuidadosamente la redundancia del almacenamiento de copia de seguridad al crear una base de datos de Hiperescala, ya que solo se puede establecer durante la creación de la base de datos. 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.

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.
• El almacenamiento con redundancia de zona solo está disponible actualmente en determinadas regiones.
• El almacenamiento con redundancia de zona geográfica solo está disponible actualmente en determinadas regiones.

Restauración de una base de datos de Hiperescala en una región diferente

Es posible que tenga que restaurar la base de datos de Hiperescala en una región diferente de la región actual. Entre los motivos comunes se incluyen una operación de recuperación ante desastres o una exploración en profundidad, o una reubicación. El método principal consiste en realizar una restauración geográfica de la base de datos. Usará los mismos pasos que seguiría para restaurar cualquier otra base de datos de Azure SQL Database en una región diferente:

1. Cree un servidor en la región de destino si ahí todavía no tiene un servidor adecuado. Este servidor debe pertenecer a la misma suscripción que el servidor original (origen).
2. Siga las instrucciones de la sección Restauración geográfica de la página dedicada a la restauración de una base de datos de Azure SQL a partir de copias de seguridad automáticas.

Nota

Dado que el origen y el destino están en regiones distintas, la base de datos no puede compartir el almacenamiento de instantáneas con la base de datos de origen como lo hace en las restauraciones no geográficas. Las restauraciones no geográficas finalizan rápidamente independientemente del tamaño de la base de datos.

Una restauración geográfica de una base de datos Hiperescala es una operación de tamaño de datos, incluso si el destino está en la región emparejada del almacenamiento con replicación geográfica. Por lo tanto, una restauración geográfica tardará mucho más tiempo en comparación con una restauración a un momento dado en la misma región.

Si el destino está en la región emparejada, la transferencia de datos estará dentro de una región. Esa transferencia será significativamente más rápida que una transferencia de datos entre regiones. Pero seguirá siendo una operación de tamaño de datos.

Si lo prefiere, puede copiar la base de datos en otra región. Use este método si la restauración geográfica no está disponible porque no se admite con el tipo de redundancia de almacenamiento seleccionado. Para obtener más información, consulte Copia de base de datos para Hiperescala.

Contenido relacionado

Las copias de seguridad de base de datos son una parte esencial de cualquier estrategia de recuperación ante desastres y continuidad del negocio, ya que ayudar a proteger los datos de daños o eliminaciones accidentales.

• Introducción a la continuidad empresarial con Azure SQL Database
• Administración de la retención de copias de seguridad a largo plazo de Azure SQL Database
• Restauración de una base de datos desde una copia de seguridad en Azure SQL Database
• Uso de PowerShell para restaurar una base de datos a un momento anterior