Copias de seguridad automatizadas: Azure SQL Database y &Azure SQL Managed Instance

SE APLICA A: Azure SQL Database Azure SQL Managed Instance

Nota

En este artículo 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.

¿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 protegen 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 para bases de datos únicas y agrupadas.

Copia de seguridad y restauración de elementos básicos

Las bases de datos de Azure SQL Managed Instance y las bases de datos que no son de Hiperescala en Azure SQL Database usan la tecnología del motor de SQL Server para realizar copias de seguridad de datos y restaurarlos. Las bases de datos de Hiperescala tienen una arquitectura única y aprovechan una tecnología diferente para la copia de seguridad y restauración. Para obtener más información, consulte Copias de seguridad de Hiperescala y redundancia de almacenamiento.

Frecuencia de copia de seguridad

Tanto Azure SQL Database como Azure SQL Managed Instance usan tecnología de SQL Server para crear copias de seguridad completas cada semana, copias de seguridad diferenciales cada 12 o 24 horas y copias de seguridad del registro de transacciones cada 5 o 10 minutos. 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.

Cuando una base de datos se restaura, el servicio averigua qué copia de seguridad completa, diferencial o del registro de transacciones es necesario restaurar.

Las bases de datos de Hiperescala usan tecnología de copia de seguridad de instantáneas.

Redundancia del almacenamiento de copia de seguridad

De forma predeterminada, Azure SQL Database y Azure SQL Managed Instance almacenan datos en blobs de almacenamiento de redundancia geográfica que se replican en una región emparejada. La redundancia geográfica ayuda a proteger frente a interrupciones que afectan al almacenamiento de copia de seguridad en la región primaria y permiten restaurar el servidor en una región diferente en caso de desastre.

La opción para configurar la redundancia del almacenamiento de copia de seguridad ofrece la flexibilidad de elegir entre blobs de almacenamiento con redundancia local, con redundancia de zona o con redundancia geográfica. Para asegurarse de que los datos permanecen dentro de la misma región donde está implementada la instancia administrada o la base de datos en Azure SQL Database, puede cambiar la opción predeterminada de almacenamiento de copia de seguridad con redundancia geográfica y configurar blobs de almacenamiento con redundancia local o con redundancia de zona para las copias de seguridad. Los mecanismos de redundancia de Storage almacenan varias copias de los datos, con el fin de protegerlos de eventos planeados y no planeados, como errores transitorios del hardware, interrupciones del suministro eléctrico o cortes de la red, y desastres naturales masivos. La redundancia de copia de seguridad establecida se aplica a la configuración de retención de la copia de seguridad a corto plazo que se usa para la restauración a un momento dado (PITR) y la configuración de retención a largo plazo que se usa para copias de seguridad a largo plazo (LTR).

En el caso de una instancia de Azure SQL Database, la redundancia del almacenamiento de copia de seguridad se puede configurar en el momento de crear la base de datos, o se puede actualizar para una base de datos existente; los cambios realizados 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 existente, los cambios pueden tardar hasta 48 horas en aplicarse. La restauración geográfica se deshabilita en cuanto se actualiza una base de datos para usar almacenamiento con redundancia local o de zona. Para bases de datos de Hiperescala, la opción de redundancia de almacenamiento seleccionada se usará durante la vigencia de la base de datos tanto para la redundancia de almacenamiento de datos como para la redundancia de almacenamiento de copia de seguridad. Obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.

Importante

El almacenamiento con redundancia de zona solo está disponible actualmente en determinadas regiones.

Uso de copia de seguridad

Puede utilizar estas copias de seguridad para realizar lo siguiente:

  • Restauración a un momento dado de una base de datos existente - 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 una API REST. En el caso de SQL Database, esta operación crea una base de datos en el mismo servidor que la original, pero usa otro nombre para evitar sobrescribirla. Una vez finalizada la restauración, puede eliminar la base de datos original. Como alternativa, puede cambiar el nombre de la base de datos original y, luego, de la base de datos restaurada para que tenga el nombre de la original. De igual forma, en SQL Managed Instance esta operación crea una copia de la base de datos en la misma instancia administrada (o en otra) en la misma suscripción y región.
  • Restauración a un momento dado de una base de datos eliminada - Restaurar una base de datos eliminada al momento de su eliminación o a cualquier otro punto dentro del período de retención. La base de datos eliminada solo se puede restaurar en el mismo servidor o instancia administrada donde se ha creado la base de datos original. Al eliminar una base de datos, el servicio toma una copia de seguridad del registro de transacciones final antes de la eliminación, para evitar la pérdida de datos.
  • Restauración geográfica - 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 servidor o instancia administrada existente, en cualquier región de Azure.

    Importante

    La restauración geográfica solo está disponible para bases de datos en Azure SQL Database o instancias administradas 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 cambiarla configurando la redundancia de almacenamiento de copia de seguridad.

  • Restauración desde una copia de seguridad a largo plazo - Restaurar una base de datos desde una copia de seguridad a largo plazo específica de una base de datos única o agrupada, si la base de datos se ha configurado con una directiva de retención a largo plazo (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.

Nota

En Azure Storage, el término replicación hace referencia a la copia de blobs desde una ubicación a otra. En SQL, la replicación de base de datos se refiere a las distintas tecnologías que se usan para mantener varias bases de datos secundarias sincronizadas con una base de datos principal.

Funcionalidades y características de restauración de Azure SQL Database y Azure SQL Managed Instance

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 las copias de seguridad de retención a largo plazo.

Propiedades de copia de seguridad  Recuperación a un momento dado (PITR) Geo-restore Restauración de copias de seguridad a largo plazo
Tipos de copia de seguridad de SQL Completa, diferencial y registro Copias replicadas de copias de seguridad PITR Solo copias de seguridad completas
Objetivo de punto de recuperación (RPO)   De 5 a 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.   Una semana (o directiva del usuario).
Objetivo de tiempo de recuperación (RTO) La restauración suele tardar más 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 más 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 más 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, hasta 35 días   Se habilita de forma predeterminada, igual que el origen.** No se habilita de forma predeterminada, retención 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 PITR está establecida en Con redundancia geográfica. No disponible cuando el almacén de copia de seguridad PITR es almacenamiento de zona o con redundancia local.  Con redundancia de zona de forma predeterminada. Se puede configurar el almacenamiento con redundancia local o de zona.
Use to create new database in same region (Usar para crear una base de datos en la misma región) Compatible Compatible  Compatible
Use to create new database in another region (Usar para crear una base de datos en otra región) No compatible Compatible con cualquier región de Azure Compatible con cualquier región de Azure
Use to create new database in another Subscription (Usar para crear una base de datos en otra suscripción) No compatible No compatible *** No compatible ***
Restore via Azure portal (Restaurar mediante Azure Portal)
Restore via PowerShell (Restaurar mediante PowerShell)
Restore via Azure CLI (Restaurar mediante la CLI de Azure)

En el caso de las aplicaciones críticas para la empresa que necesitan bases de datos grandes y deben garantizar la continuidad empresarial, use grupos de conmutación por error automática.

Todas las copias de seguridad PITR se almacenan de forma predeterminada en el almacenamiento con redundancia geográfica. Por lo tanto, la restauración geográfica está habilitada de forma predeterminada.

La solución consiste en realizar la restauración en un nuevo servidor y usar el movimiento de recursos para mover el servidor a otra suscripción.

Restauración de una base de datos de las copias 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 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
Restauración de una base de datos desde Azure Blob Storage
Instancia administrada de SQL

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 se completa 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 o SQL Managed Instance determina el momento exacto en el que se producen todas las copias de seguridad de la base de datos a medida que se equilibra la carga de trabajo global del sistema. No se puede cambiar la programación de trabajos de copia de seguridad ni deshabilitarlos. Hiperescala usa un mecanismo de programación de copia de seguridad diferente; consulte Programación de copias de seguridad de Hiperescala para obtener más información.

Importante

En una base de datos nueva, restaurada o copiada, la funcionalidad de restauración a un momento dado está disponible desde el momento en el que se crea la copia de seguridad del registro de transacciones inicial que sigue a la copia de seguridad completa inicial.

Consumo del almacenamiento de copia de seguridad

Con la tecnología de copia de seguridad y restauración de SQL Server, la restauración de una base de datos a un momento dado requiere una cadena de copia de seguridad ininterrumpida que conste de una copia de seguridad completa, una copia de seguridad diferencial (opcional) y una o varias copias de seguridad del registro de transacciones. Las programaciones de copias de seguridad de Azure SQL Database y Azure SQL Managed Instance incluyen una copia de seguridad completa cada semana. Por tanto, 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.

Es decir, para cualquier punto en el tiempo durante el período de retención, debe haber una copia de seguridad completa que sea anterior a la hora más antigua del período de retención, así como una cadena ininterrumpida de copias de seguridad diferenciales y del registro de transacciones desde esa copia de seguridad completa hasta la siguiente. 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, y para obtener más información sobre cómo supervisar los costos de almacenamiento, consulte Costos de almacenamiento de copia de seguridad de Hiperescala.

Nota

Para proporcionar PITR, las copias de seguridad adicionales se almacenan hasta una semana más que el período de retención configurado. El almacenamiento de copia de seguridad se cobra a la misma tarifa para todas las copias de seguridad.

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 se comprimen para reducir los costos y la compresión del almacenamiento de copia de seguridad. La relación promedio de compresión de copia de seguridad es de entre 3 y 4 veces, pero 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.

Azure SQL Database y Azure SQL Managed Instance calculan el almacenamiento de copia de seguridad total usado como un valor acumulativo. Cada hora, este valor se envía a la canalización de facturación de Azure, que 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. A pesar de que eliminar y volver a crear una base de datos puede ahorrar costos de almacenamiento y proceso, puede aumentar los costos de almacenamiento de copias de seguridad, ya 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 este diagrama se muestra cómo supervisar el consumo de almacenamiento de copia de seguridad para una única base de datos. Esta característica no está disponible actualmente para las instancias administradas.

Monitor database backup consumption in the Azure portal

Encontrará instrucciones sobre cómo supervisar el consumo de Hiperescala en 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 dependerá 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 posible 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, o bien reduzca el número de índices no agrupados.
  • 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 y Azure SQL Managed Instance proporciona retención de copias de seguridad a corto y largo plazo. La retención de copias de seguridad a corto plazo permite la restauración a un momento dado (PITR) dentro del período de retención de la base de datos, mientras que la retención a largo plazo proporciona copias de seguridad para varios requisitos de cumplimiento.

Retención a corto plazo

En el caso de todas las bases de datos nuevas, restauradas y copiadas, Azure SQL Database y Azure SQL Managed Instance conservan copias de seguridad suficientes para permitir PITR de forma predeterminada en los últimos siete días. Se toman 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. Además, en las instancias de Azure SQL Database, las copias de seguridad diferenciales se pueden configurar en una frecuencia de 12 horas o de 24 horas.

Nota

Una frecuencia de copia de seguridad diferencial de 24 horas puede aumentar el tiempo necesario para restaurar la base de datos.

A excepción de las bases de datos de nivel Básico, puede cambiar el período de retención de la copia de seguridad por cada base de datos activa en el intervalo de 1 a 35 días. Como se describe en Consumo de almacenamiento de copia de seguridad, las copias de seguridad almacenadas para habilitar PITR pueden ser anteriores al período de retención. Solo para Azure SQL Managed Instance, es posible establecer la tasa de retención de copia de seguridad de recuperación a un momento dado una vez que se haya eliminado una base de datos en el intervalo de 0 a 35 días.

Nota

La retención de copia de seguridad a corto plazo de entre 1 y 35 días para las bases de datos de Hiperescala está ahora en versión preliminar. Para más información, consulte Administración de retención de copias de seguridad de Hiperescala.

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 o una instancia administrada, también se eliminan todas las bases de datos que contenga y no se pueden recuperar. No se puede restaurar un servidor o una instancia administrada que se haya eliminado. Pero si ha configurado la retención a largo plazo (LTR) para una base de datos o una instancia administrada, las copias de seguridad de retención a largo plazo no se eliminan y se pueden usar para restaurar bases de datos en otro servidor o instancia administrada de la misma suscripción, a un momento dado en el que se haya realizado una copia de seguridad de retención a largo plazo.

La retención de copias de seguridad para fines de PITR durante el período de los últimos 1 a 35 días se denomina a veces retención de copias de seguridad a corto plazo. 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.

Retención a largo plazo

En el caso de SQL Database y SQL Managed Instance, 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. 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.

Importante

La actualización de la redundancia del almacenamiento de copia de seguridad de una instancia de Azure SQL Database existente solo se aplica a las copias de seguridad futuras que se realicen de la base de datos. Las copias de seguridad de LTR de la base de datos existentes seguirán residiendo en el blob de almacenamiento existente; las nuevas copias de seguridad se almacenarán en el tipo de blob de almacenamiento solicitado.

Para más información sobre LTR, vea Retención de copias de seguridad a largo plazo.

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 también de su región. El almacenamiento de copia de seguridad se cobra por GB consumidos al mes. Para ver los precios, consulte la página de Precios de Azure SQL Database y la página de Precios de Azure SQL Managed Instance.

Para más información sobre los modelos de compra, consulte Elección entre los modelos de compra de núcleo virtual y DTU.

Nota

La factura de Azure solo mostrará 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. En caso de que haya usado el total de 5,8 TB de espacio de almacenamiento de copia de seguridad, la factura de Azure solo mostrará 1,8 TB, ya que solo se cobra el exceso de almacenamiento de copia de seguridad.

Modelo de DTU

En el modelo de DTU, no hay ningún cargo adicional por el almacenamiento de copia de seguridad para bases de datos y grupos elásticos. El precio del almacenamiento de copia de seguridad forma parte del de la base de datos o del grupo.

Modelo de núcleos virtuales

En el caso de las bases de datos únicas en SQL Database, 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. Para grupos elásticos e instancias administradas, se proporciona una cantidad de almacenamiento de copia de seguridad igual al 100 % del almacenamiento de datos máximo para el grupo o del tamaño de almacenamiento de instancia máximo, respectivamente, sin costo adicional.

En el caso de las bases de datos únicas, esta 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 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

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 de copia de seguridad facturable total, si existe, se cobrará en GB/mes según la tarifa de la redundancia de almacenamiento de copia de seguridad utilizada. 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 tendrán mayores cargos de copia de seguridad.

Las fórmulas que se usan para calcular los costos de almacenamiento de copia de seguridad de las bases de datos de Hiperescala se pueden encontrar en Costos de almacenamiento de copia de seguridad de Hiperescala.

Azure SQL Database y 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, que lo suma 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. Una vez que se hayan eliminado todas las copias de seguridad, se detiene la facturación.

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 notificará 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 sumará este consumo y reflejará un uso de 744 GB durante todo el mes. El costo se basará en la tarifa de cantidad/GB/mes de la región.

Veamos ahora un ejemplo más complejo. 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/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á, lo que provocará que el consumo de almacenamiento de copia de seguridad por hora varíe en consecuencia. Además, cada copia de seguridad diferencial contiene todos los cambios realizados en la base de datos desde la última copia de seguridad completa, por lo que el tamaño total de todas las copias de seguridad diferenciales aumenta gradualmente durante el transcurso de una semana y, después, se reduce de manera abrupta cuando expira un conjunto más antiguo de copias de seguridad completas, diferenciales y del registro. Por ejemplo, si se ha ejecutado un actividad de escritura intensiva como la recompilación de índices justo después de finalizar una copia de seguridad completa, las modificaciones realizadas por la recompilación del índice se incluirán en las copias de seguridad del registro de transacciones realizadas durante la recompilación, en la siguiente copia de seguridad diferencial y en todas las copias de seguridad diferenciales que se realicen hasta la siguiente copia de seguridad completa. Para el segundo 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.

Redundancia del almacenamiento de copia de seguridad

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

  • precio con redundancia local = x
  • precio con redundancia de zona = 1,25x
  • precio con redundancia geográfica = 2x

Para más información sobre los precios de almacenamiento de copia de seguridad, visite la página de Precios de Azure SQL Database y la página de Precios de Azure SQL Managed Instance.

Importante

La redundancia de almacenamiento de copia de seguridad para Hiperescala solo se puede establecer durante la creación de la base de datos. Esta configuración no se puede modificar una vez aprovisionado el recurso. El proceso de copia de la base de datos se puede usar para actualizar la configuración de redundancia del almacenamiento de copia de seguridad de una base de datos de Hiperescala existente. Obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.

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 Administración de costos y, después, seleccione Análisis de costos. Seleccione la suscripción deseada como á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 en el caso de una sola base de datos o un grupo de bases de datos elásticas, o bien seleccione sql managed instance en el caso de una instancia administrada.
  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, o bien seleccione managed instance pitr backup storage (almacenamiento de copia de seguridad PITR de instancia administrada) en el caso de una instancia administrada. Los medidores solo se mostrarán si hay consumo.
  5. Para supervisar los costos de copia de seguridad de LTR, en la lista desplegable, seleccione ltr backup storage (almacenamiento de copia de seguridad de LTR) en el caso de una sola base de datos o un grupo de bases de datos elásticas, o bien seleccione sql managed instance - ltr backup storage (SQL Managed Instance - almacenamiento de copia de seguridad de LTR) en el caso de una instancia administrada. Los medidores solo se mostrarán si hay consumo.

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

Backup storage cost analysis

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. Por ejemplo, si no hay ningún consumo del almacenamiento de copia de seguridad PITR o de LTR, no se mostrarán estos medidores.

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

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. (Esta prueba no está disponible actualmente en Instancia administrada de Azure SQL Database. Debe programar DBCC CHECKDB en las bases de datos de Instancia administrada de SQL Database, programadas en torno a la carga de trabajo).

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 este artículo 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.

Cambio de la directiva de retención a corto plazo

Puede cambiar el período de retención predeterminado de copia de seguridad PITR y la frecuencia de copia de seguridad diferencial usando Azure Portal, PowerShell o la API de REST. En los siguientes ejemplos se muestra cómo cambiar la retención PITR a 28 días y las copias de seguridad diferenciales a un intervalo de 24 horas.

Advertencia

Si reduce el período de retención actual, perderá la capacidad de restaurar a puntos en el tiempo más antiguos que el nuevo período de retención. Se eliminan las copias de seguridad que ya no son necesarias para proporcionar PITR dentro del nuevo período de retención. Si aumenta el período de retención actual, no obtendrá de forma inmediata la capacidad de restaurar a puntos en el tiempo más antiguos dentro del nuevo período de retención. Obtiene esa capacidad a lo largo del tiempo, ya que el sistema empieza a conservar las copias de seguridad durante más tiempo.

Nota

Estas API afectan únicamente al período de retención PITR. Si ha configurado LTR para la base de datos, no se verá afectada. Para más información sobre cómo cambiar los períodos de retención LTR, vea Retención de copias de seguridad a largo plazo.

Cambiar la directiva de retención a corto plazo mediante Azure Portal

Para cambiar el período de retención de copia de seguridad PITR o la frecuencia copia de seguridad diferencial para bases de datos activas mediante Azure Portal, vaya al servidor o a la instancia administrada con las bases de datos cuyo período de retención quiera cambiar. Seleccione Copias de seguridad en el panel izquierdo y, luego, elija la pestaña Directivas de retención. Seleccione las bases de datos en las que quiere cambiar la retención de copia de seguridad de la recuperación a un momento dado. Luego, seleccione Configurar retención en la barra de acciones.

Cambio de la directiva de retención a corto plazo mediante la CLI de Azure

Prepare el entorno para la CLI de Azure.

Cambie la retención de copia de seguridad de PITR y la frecuencia de copia de seguridad diferencial de las bases de datos de Azure SQL Database activas mediante el siguiente ejemplo.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

Cambie la directiva de retención a corto plazo mediante PowerShell

Nota

En este artículo se usa el módulo Az de PowerShell, que es el módulo de PowerShell que se recomienda para interactuar con Azure. Para empezar a trabajar con el módulo Az de PowerShell, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Importante

El módulo AzureRM de PowerShell todavía es compatible con SQL Database y la Instancia administrada de SQL, pero todo el desarrollo futuro se realizará para el módulo Az.Sql. Para más información, vea AzureRM.Sql. Los argumentos de los comandos del módulo Az son básicamente idénticos a los de los módulos AzureRm.

A fin de cambiar la retención de copia de seguridad de PITR y la frecuencia de copia de seguridad diferencial para las bases de datos de Azure SQL Database activas, use el siguiente ejemplo de PowerShell.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28
# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

Cambio de la directiva de retención a corto plazo mediante la API de REST

La siguiente solicitud actualiza el período de retención a 28 días y también establece la frecuencia de copia de seguridad diferencial en 24 horas.

Solicitud de ejemplo

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2021-02-01-preview

Cuerpo de la solicitud

{ 
    "properties":{
        "retentionDays":28,
        "diffBackupIntervalInHours":24
  }
}

Respuesta de ejemplo:

{ 
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28,
    "diffBackupIntervalInHours":24
  }
}

Para más información, consulte API REST de retención de Backup.

Copias de seguridad de Hiperescala y redundancia de almacenamiento

Las bases de datos de Hiperescala en Azure SQL Database 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. El registro generado se almacena en almacenamiento de Azure a largo plazo durante el período de retención de copia de seguridad. La arquitectura de Hiperescala no usa copias de seguridad completas de bases de datos ni copias de seguridad de registros, por lo que no se aplican la frecuencia de copia de seguridad, los costos de almacenamiento, la programación, el almacenamiento y la redundancia y las funciones de almacenamiento descritas en las secciones anteriores de este artículo.

Rendimiento de copias de seguridad y restauración en Hiperescala

La separación del almacenamiento y los procesos permite a Hiperescala insertar la operación de copia de seguridad y restauración en la capa de almacenamiento para reducir la carga de procesamiento en replica de proceso principal. Como resultado, las copias de seguridad de base de datos no afectan al rendimiento del nodo de ejecución principal.

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. Una base de datos se puede restaurar a cualquier punto en el tiempo dentro de su período de retención de copia de seguridad. La recuperación a un momento dado (PITR) se logra revirtiendo las instantáneas de los archivos y, por tanto, no depende de la operación de datos. La restauración de una base de datos de Hiperescala dentro de la misma región de Azure es una operación de tiempo constante, e incluso las bases de datos de varios terabytes se pueden restaurar en minutos en lugar de horas o días. La creación de bases de datos nuevas mediante la restauración de una copia de seguridad existente o la copia de a base de datos también aprovecha esta característica: la creación de copias de base de datos para fines de desarrollo o pruebas, incluso de bases de datos de varios terabytes, es factible en cuestión de minutos dentro de la misma región cuando se usa el mismo tipo de almacenamiento.

Retención de copias de seguridad de Hiperescala

La retención de copia de seguridad a corto plazo predeterminada (STR) para las bases de datos de Hiperescala es de 7 días; las directivas de retención a largo plazo (LTR) no se admiten actualmente.

Nota

La retención de copia de seguridad a corto plazo de hasta 35 días para las bases de datos de Hiperescala está ahora en versión preliminar.

Programación de copias de seguridad de Hiperescala

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. El registro de transacciones generado se conserva tal y como está durante el período de retención configurado. En el momento de la restauración, se aplican los registros de transacciones pertinentes a la instantánea de almacenamiento restaurada, lo que da lugar a una base de datos transaccionalmente coherente sin pérdida de datos a partir del momento especificado dentro del período de retención.

Costos de almacenamiento de copia de seguridad de Hiperescala

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 por GB consumidos al mes. Para ver 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. Sin embargo, si se trata de una eliminación permanente y ya no se necesitan copias de seguridad, para optimizar los costos, puede reducir la retención antes de eliminar la base de datos.

Supervisar el consumo de copia de seguridad de Hiperescala

En Hiperescala, el tamaño de almacenamiento de copia de seguridad de datos (tamaño de copia de seguridad de instantáneas), el tamaño de almacenamiento de datos (tamaño de la base de datos) y el tamaño de almacenamiento de copia de seguridad de registros (tamaño de copia de seguridad del registro de transacciones) se notifican mediante métricas de Azure Monitor.

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.

Screenshot of the Azure portal showing the Hyperscale Backup storage metrics

  1. En la lista desplegable Métrica, seleccione las métricas Copia de seguridad 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 posible 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).

La redundancia de almacenamiento de Hiperescala se aplica tanto al almacenamiento de datos como al almacenamiento de copias de seguridad

Hiperescala admite redundancia de almacenamiento configurable. Al crear una base de datos de Hiperescala, puede elegir el tipo de almacenamiento preferido estándar de Azure: almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia local (LRS). La opción de redundancia de almacenamiento seleccionada se usa durante la vigencia de la base de datos tanto para la redundancia de almacenamiento de datos como para la redundancia de almacenamiento de copias de seguridad.

Considere cuidadosamente la redundancia de almacenamiento al crear una base de datos de Hiperescala

La redundancia de almacenamiento de copia de seguridad para bases de datos de Hiperescala solo se puede establecer durante la creación de la base de datos. Esta configuración no se puede modificar una vez aprovisionado el recurso. La restauración geográfica solo está disponible cuando se ha elegido el almacenamiento con redundancia geográfica (RA-GRS) para la redundancia del almacenamiento de copia de seguridad. El proceso de copia de la base de datos se puede usar para actualizar la configuración de redundancia del almacenamiento de una base de datos de Hiperescala existente. Copiar una base de datos en un tipo de almacenamiento diferente será una operación de tamaño de datos. Busque código de ejemplo en Configuración de la redundancia del almacenamiento de copia de seguridad.

Importante

El almacenamiento con redundancia de zona solo está disponible actualmente en determinadas regiones.

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

Si necesita restaurar una base de datos Hiperescala de Azure SQL Database en una región distinta a donde se hospeda actualmente —como parte de una operación de recuperación ante desastres, una exploración en profundidad, una reubicación o cualquier otro motivo—, el método principal es realizar una restauración geográfica de la base de datos. Esto implica exactamente los mismos pasos que seguiría para restaurar cualquier otra base de datos de 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

Debido a que el origen y el destino están en regiones separadas, la base de datos no puede compartir el almacenamiento de instantáneas con la base de datos de origen como hace en las restauraciones no geográficas, que se completan rápidamente independientemente del tamaño de la base de datos. En el caso de una restauración geográfica de una base de datos Hiperescala, será 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 esto, la duración de una restauración geográfica será proporcional al tamaño de la base de datos que se está restaurando. Si el destino se encuentra en la región emparejada, la transferencia de datos se realizará dentro de una región, lo que será mucho más rápido que una transferencia entre regiones, pero aun así será una operación de tamaño de datos.

Si lo prefiere, también puede copiar la base de datos en otra región. Obtenga información sobre la copia de base de datos para Hiperescala.

Configuración de la redundancia del almacenamiento de copia de seguridad

La redundancia del almacenamiento de copia de seguridad para bases de datos en Azure SQL Database se puede configurar en el momento de crear la base de datos, o se puede actualizar para una base de datos existente; los cambios realizados en una base de datos existente solo se aplican a las copias de seguridad futuras. El valor predeterminado es el almacenamiento con redundancia geográfica. Para conocer las diferencias de precio entre el almacenamiento de copia de seguridad con redundancia local, con redundancia de zona y con redundancia geográfica, visite la página de precios de Azure SQL Managed Instance. La redundancia de almacenamiento para bases de datos de Hiperescala es única: obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.

En el caso de Azure SQL Managed Instance, la redundancia de almacenamiento de copia de seguridad se establece en el nivel de instancia y se aplica a todas las bases de datos administradas pertenecientes. Se puede configurar en el momento de la creación de una instancia o actualizar para las instancias existentes; el cambio de redundancia de almacenamiento de copia de seguridad desencadenaría entonces una nueva copia de seguridad completa por base de datos y el cambio se aplicará a todas las copias de seguridad futuras. El tipo de redundancia de almacenamiento predeterminado es la redundancia geográfica (RA-GRS).

Configuración de la redundancia del almacenamiento de copia de seguridad mediante Azure Portal

En Azure Portal, puede configurar la redundancia del almacenamiento de copia de seguridad en el panel Crear base de datos SQL. La opción está disponible en la sección Redundancia del almacenamiento de copias de seguridad.

Open Create SQL Database pane

Configuración de la redundancia del almacenamiento de copia de seguridad mediante la CLI de Azure

Para configurar la redundancia del almacenamiento de copia de seguridad al crear una nueva base de datos, puede especificar el parámetro --backup-storage-redundancy con el comando az sql db create. Los valores posibles son Geo, Zone y Local. De forma predeterminada, todas las bases de Azure SQL Database usan almacenamiento con redundancia geográfica para las copias de seguridad. La restauración geográfica se deshabilita si se crea o se actualiza una base de datos con almacenamiento de copia de seguridad con redundancia local o de zona.

En este ejemplo se crea una base de datos en el nivel de servicio De uso general con redundancia de copia de seguridad local:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

Considere detenidamente la opción de configuración para --backup-storage-redundancy al crear una base de datos de Hiperescala. La redundancia de almacenamiento solo se puede especificar durante el proceso de creación de la base de datos para bases de datos de Hiperescala. La opción de redundancia de almacenamiento seleccionada se usará durante la vigencia de la base de datos tanto para la redundancia de almacenamiento de datos como para la redundancia de almacenamiento de copia de seguridad. Obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.

Las bases de datos de Hiperescala existentes pueden migrarse a diferentes redundancias de almacenamiento mediante copia de base de datos o restauración a un momento dado: el código de ejemplo para copiar una base de datos de Hiperescala se muestra a continuación en esta sección.

En este ejemplo se crea una base de datos en el nivel de servicio Hiperescala con redundancia de zona:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier Hyperscale \
    --backup-storage-redundancy Zone

Para más información, vea az sql db create y az sql db update.

A excepción de las bases de datos de nivel Hiperescala y Básico, puede actualizar la configuración de redundancia de almacenamiento de copia de seguridad de una base de datos existente con el parámetro --backup-storage-redundancy y el comando az sql db update. Los cambios pueden tardar hasta 48 horas en aplicarse en la base de datos. Al cambiar del almacenamiento de copia de seguridad con redundancia geográfica al almacenamiento con redundancia local o de zona se deshabilita la restauración geográfica.

Este código de ejemplo cambia la redundancia de almacenamiento de copia de seguridad a Local.

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

No se puede actualizar la redundancia de almacenamiento de copia de seguridad de una base de datos de Hiperescala directamente. Sin embargo, puede cambiarla mediante el comando de copia de base de datos con el parámetro --backup-storage-redundancy. En este ejemplo se copia una base de datos de Hiperescala en una nueva base de datos mediante hardware Gen5 y dos núcleos virtuales. La nueva base de datos tiene la redundancia de copia de seguridad establecida en Zone.

az sql db copy \
    --resource-group myresourcegroup \ 
    --server myserver 
    --name myHSdb 
    --dest-resource-group mydestresourcegroup 
    --dest-server destdb 
    --dest-name myHSdb 
    --service-objective HS_Gen5_2 
    --read-replicas 0 
    --backup-storage-redundancy Zone

Para detalles sobre la sintaxis, consulte az sql db copy. Para información general sobre la copia de base de datos, visite Creación de una copia transaccionalmente coherente de una base de datos de Azure SQL Database.

Configuración de la redundancia del almacenamiento de copia de seguridad mediante PowerShell

Para configurar la redundancia del almacenamiento de copia de seguridad al crear una nueva base de datos, puede especificar el parámetro -BackupStorageRedundancy con el cmdlet New-AzSqlDatabase. Los valores posibles son Geo, Zone y Local. De forma predeterminada, todas las bases de Azure SQL Database usan almacenamiento con redundancia geográfica para las copias de seguridad. La restauración geográfica se deshabilita si se crea una base de datos con almacenamiento de copia de seguridad con redundancia local o de zona.

En este ejemplo se crea una base de datos en el nivel de servicio De uso general con redundancia de copia de seguridad local:

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Local

Considere detenidamente la opción de configuración para --backup-storage-redundancy al crear una base de datos de Hiperescala. La redundancia de almacenamiento solo se puede especificar durante el proceso de creación de la base de datos para bases de datos de Hiperescala. La opción de redundancia de almacenamiento seleccionada se usará durante la vigencia de la base de datos tanto para la redundancia de almacenamiento de datos como para la redundancia de almacenamiento de copia de seguridad. Obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.

Las bases de datos existentes pueden migrarse a diferentes redundancias de almacenamiento mediante copia de base de datos o restauración a un momento dado: el código de ejemplo para copiar una base de datos de Hiperescala se muestra a continuación en esta sección.

En este ejemplo se crea una base de datos en el nivel de servicio Hiperescala con redundancia de zona:

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "Hyperscale" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Zone

Para detalles sobre la sintaxis, visite New-AzSqlDatabase.

A excepción de las bases de datos de Hiperescala y de nivel Básico, puede usar el parámetro -BackupStorageRedundancy con el cmdlet Set-AzSqlDatabase para actualizar la configuración de redundancia de almacenamiento de copia de seguridad de una base de datos existente. Los valores posibles son Geo, Zone y Local. Los cambios pueden tardar hasta 48 horas en aplicarse en la base de datos. Al cambiar del almacenamiento de copia de seguridad con redundancia geográfica al almacenamiento con redundancia local o de zona se deshabilita la restauración geográfica.

Este código de ejemplo cambia la redundancia de almacenamiento de copia de seguridad a Local.

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Local

Para obtener más información, consulte Set-AzSqlDatabase.

No se puede actualizar la redundancia de almacenamiento de copia de seguridad de una base de datos de Hiperescala existente. Sin embargo, puede usar el comando de copia de base de datos para crear una copia de la base de datos y usar el parámetro -BackupStorageRedundancy para actualizar la redundancia de almacenamiento de copia de seguridad. En este ejemplo se copia una base de datos de Hiperescala en una nueva base de datos mediante hardware Gen5 y dos núcleos virtuales. La nueva base de datos tiene la redundancia de copia de seguridad establecida en Zone.

# Change the backup storage redundancy for Database01 to zone-redundant. 
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone

Para detalles sobre la sintaxis, visite New-AzSqlDatabaseCopy.

Para información general sobre la copia de base de datos, visite Creación de una copia transaccionalmente coherente de una base de datos de Azure SQL Database.

Nota

Para usar el parámetro -BackupStorageRedundancy con operaciones de restauración de base de datos, copia de base de datos o creación de un elemento secundario, use Azure PowerShell versión Az.Sql 2.11.0.

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

Se han agregado las siguientes directivas integradas nuevas, que se pueden asignar en el nivel de suscripción o de grupo de recursos para bloquear la creación de nuevas bases de datos o instancias con almacenamiento de copia de seguridad con redundancia geográfica.

SQL Database debe evitar el uso de la redundancia de copia de seguridad con almacenamiento con redundancia geográfica

Las instancias administradas de SQL deben evitar el uso de redundancia de copia de seguridad con almacenamiento con redundancia geográfica

Puede encontrar una lista completa de las definiciones de directiva integradas para SQL Database y SQL Managed Instance aquí.

Si quiere aplicar los requisitos de residencia de datos en el nivel de la organización, puede asignar estas directivas a una suscripción. Después de que estas directivas se asignan a una suscripción, los usuarios de esa suscripción no podrán crear una base de datos ni una instancia administrada con almacenamiento de copia de seguridad con redundancia geográfica a través de Azure Portal o Azure PowerShell.

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.

Obtenga información sobre cómo asignar directivas mediante Azure Portal o Azure PowerShell.

Pasos siguientes