Comparteix via

Copia de seguridad de los grupos de disponibilidad Always On de SQL Server

Azure Backup ofrece soporte integral para la copia de seguridad de los Grupos de disponibilidad Always On de SQL Server, siempre y cuando todos los nodos estén en la misma región y suscripción que la bóveda de Recovery Services. Sin embargo, si los nodos de conjuntos de disponibilidad (AG) están repartidos entre regiones, suscripciones y entornos locales y Azure, hay algunas consideraciones a tener en cuenta.

Para ver los escenarios de copia de seguridad y restauración que se admiten en la actualidad, consulte la matriz de compatibilidad. Para preguntas comunes, consulte las preguntas más frecuentes.

Nota:

Azure Backup no admite la copia de seguridad de bases de datos de grupos de disponibilidad básica.

La preferencia de copia de seguridad utilizada por Azure Backup para SQL AG solo admite copias de seguridad completas y diferenciales desde la réplica principal. Por lo tanto, estos trabajos de copia de seguridad siempre se ejecutan en el nodo principal independientemente de la preferencia de copia de seguridad. En el caso de las copias de seguridad completas y de registros de transacciones tipo copy-only, se tiene en cuenta la preferencia de copia de seguridad del grupo de disponibilidad (AG) al determinar el nodo en el que se realizará la copia de seguridad.

Preferencia de copia de seguridad AG Las copias de seguridad completas y diferenciales se realizan en Las copias de seguridad de solo copia y de registros se toman de
Principal Réplica principal Réplica principal
Solo secundaria Réplica principal Cualquiera de las réplicas secundarias
Preferir opción secundaria Réplica principal Se prefieren réplicas secundarias, pero las copias de seguridad también se pueden ejecutar en la réplica principal.
Ninguno/cualquiera Réplica principal Cualquier réplica

La extensión de copia de seguridad de carga de trabajo se instala en el nodo al registrarla con el servicio Azure Backup. Cuando se configura una base de datos de grupo de disponibilidad (AG) para la copia de seguridad, los horarios de respaldo se propagan a todos los nodos registrados del grupo de disponibilidad. Las programaciones se activan en todos los nodos del grupo de disponibilidad y las extensiones de copia de seguridad de la carga de trabajo de estos nodos se sincronizan mutuamente entre sí para decidir qué nodo sea capaz de realizar la copia de seguridad. La selección del nodo depende del tipo de copia de seguridad y de la preferencia de copia de seguridad, como se explica en la sección 1.

El nodo seleccionado continúa con el trabajo de copia de seguridad, mientras que el trabajo desencadenado en los otros nodos se retira, es decir, omite el trabajo.

Nota:

Azure Backup no tiene en cuenta las prioridades de copia de seguridad ni las réplicas al decidir entre las réplicas secundarias.

Registrar nodos de AG en el almacén de Recovery Services

Un almacén de Recovery Services admite la copia de seguridad de bases de datos solo de VM de la misma región y suscripción que la del almacén.

  • Registre el nodo principal en la bóveda (de lo contrario, no se pueden realizar copias de seguridad completas).
  • Registra al menos un nodo secundario en la bóveda (de lo contrario, no se pueden realizar copias de seguridad completas solo de registro o de copia) si la preferencia de copia de seguridad es solo secundaria.

Si no se cumplen las condiciones anteriores, la configuración de copias de seguridad para las bases de datos de grupos de disponibilidad falla con el código de error FabricSvcBackupPreferenceCheckFailedUserError.

Consideremos la siguiente implementación de AG (Grupo de Disponibilidad) como referencia.

Diagrama para la implementación de AG como referencia.

En función del ejemplo dado de implementación de grupo de disponibilidad, a continuación se indican varias consideraciones:

  • Dado que el nodo principal está en la región 1 y la suscripción 1, la bóveda de Recovery Services (bóveda 1) debe estar en la región 1 y en la suscripción 1 para proteger este conjunto de alta disponibilidad.
  • VM3 no se puede registrar en Vault 1, ya que se encuentra en una suscripción diferente.
  • VM4 no se puede registrar en Vault 1, ya que se encuentra en una región diferente.
  • Si la preferencia de copia de seguridad es solo secundaria, la VM1 (principal) y la VM2 (secundaria) deben registrarse en el almacén 1 (ya que las copias de seguridad completas requieren el nodo principal y los registros requieren un nodo secundario). Para otras preferencias de copia de seguridad, la VM1 (principal) debe registrarse en el almacén 1, y la VM2 es opcional (porque todas las copias de seguridad se pueden ejecutar en el nodo principal).
  • La VM3 podría registrarse en el almacén 2 de la suscripción 2. Las bases de datos del AG se mostrarían entonces para la protección en el almacén 2, pero debido a la ausencia del nodo principal en el almacén 2, se produciría un error al configurar las copias de seguridad.
  • Del mismo modo, la VM4 podría registrarse en el almacén 4 de la región 2, pero la configuración de las copias de seguridad produciría un error, ya que el nodo principal no está registrado en el almacén 4.

Control de la conmutación por error

Después de que el grupo de disponibilidad haya realizado la conmutación por error a uno de los nodos secundarios:

  • Las copias de seguridad completas y diferenciales continuarán desde el nuevo nodo principal si está registrado en la bóveda.
  • Las copias de seguridad de registros y completas de solo copia continuarán desde el nodo principal o secundario en función de la preferencia de copia de seguridad.

Nota:

Las interrupciones de la cadena de registros no se producen en la conmutación por error si esta no coincide con una copia de seguridad.

Según la implementación de AG de ejemplo anterior, las siguientes son las distintas posibilidades de conmutación por error:

  • Conmutación por error a la VM2
    • Las copias de seguridad completas y diferenciales se realizarán desde la VM2.
    • Las copias de seguridad de registros o completas de solo copia se realizarán desde la VM1 o la VM2 en función de la preferencia de copia de seguridad.
  • Conmutación por error a la VM3 (otra suscripción)
    • Dado que las copias de seguridad no están configuradas en Vault 2, no se realizará ninguna copia de seguridad.
    • Si la preferencia de copia de seguridad no es solo secundaria, las copias de seguridad se pueden configurar ahora en la bóveda 2, ya que el nodo principal ha sido registrado en esta bóveda. No obstante, esto puede provocar conflictos o errores de copia de seguridad. Puede obtener más información al respecto en Configuración de copias de seguridad para un AG de varias regiones.
  • Conmutación por error a la VM4 (otra región)
    • Dado que las copias de seguridad no están configuradas en Vault 4, no se realizará ninguna copia de seguridad.
    • Si la preferencia de copia de seguridad no es exclusivamente secundaria, las copias de seguridad pueden configurarse ahora en la Bóveda 4, ya que el nodo principal está registrado en esta bóveda. No obstante, esto puede provocar conflictos o errores de copia de seguridad. Puede obtener más información al respecto en Configuración de copias de seguridad para un grupo de disponibilidad de varias regiones.

Configuración de copias de seguridad para un grupo de disponibilidad multirregional

El almacén de Recovery Services no admite copias de seguridad entre suscripciones ni entre regiones. En esta sección se resume cómo habilitar las copias de seguridad de grupos de administración que abarcan suscripciones o regiones de Azure y se explican las consideraciones asociadas.

  • Evalúe si realmente necesita habilitar las copias de seguridad de todos los nodos. Si una región o suscripción tiene la mayoría de los nodos del grupo de disponibilidad y la conmutación por error a otros nodos se produce muy rara vez, la configuración de la copia de seguridad en esa primera región puede ser suficiente. Si las conmutaciones por error a otra región o suscripción se producen con frecuencia y durante un período prolongado, es posible que también desee configurar las copias de seguridad de forma proactiva en la otra región.

  • Cada almacén donde se habilite la copia de seguridad tendrá su propio conjunto de cadenas de puntos de recuperación. Las restauraciones desde estos puntos de recuperación solo se pueden realizar en las máquinas virtuales registradas en ese almacén.

  • Las copias de seguridad completas o diferenciales solo se realizarán correctamente en la bóveda que tiene el nodo principal. Estas copias de seguridad seguirán fallando en otras bóvedas.

  • Las copias de seguridad de registros seguirán funcionando en el almacén anterior hasta que se ejecute una copia de seguridad de registros en el nuevo almacén (es decir, en el almacén donde está presente el nuevo nodo principal) y se interrumpe la cadena de registros del almacén antiguo.

    Nota:

    Hay un límite máximo de 15 días más allá del cual las copias de seguridad de registros comenzarán a generar errores.

  • Copias de seguridad completas de solo copia funcionarán en todas las bóvedas.

  • La protección en cada bóveda se trata como un origen de datos distinto y se factura por separado.

Para evitar conflictos de copia de seguridad de registros de transacciones entre las dos bóvedas, se recomienda establecer la preferencia de copia de seguridad a Principal. Así, la bóveda que tiene el nodo principal también realizará las copias de seguridad de logs.

En función de la implementación del grupo de disponibilidad de ejemplo anterior, estos son los pasos para habilitar la copia de seguridad de todos los nodos. La suposición es que la preferencia de copia de seguridad se cumple en todos los pasos.

Paso 1: Habilitación de copias de seguridad en la región 1, suscripción 1 (almacén 1)

Dado que el nodo principal está dentro de la región y la suscripción correspondientes, los pasos habituales para habilitar las copias de seguridad funcionarán.

Paso 2: Habilitación de copias de seguridad en la región 1, suscripción 2 (almacén 2)

  1. Realice una conmutación por error del grupo de disponibilidad a la VM3 para que el nodo principal esté presente en el almacén 2.
  2. Configurar copias de seguridad de las bases de datos AG en la Bóveda 2.
  3. En este punto:
    1. Las copias de seguridad completas o diferenciales fallarán en Vault 1, ya que ninguno de los nodos registrados puede encargarse de esta copia de seguridad.
    2. Las copias de seguridad de registros se realizarán correctamente en el almacén 1 hasta que se ejecute una copia de seguridad de registros en el almacén 2 y se interrumpa la cadena de registros del almacén 1.
  4. Conmutación por recuperación del grupo de disponibilidad a la VM1.

Paso 3: Habilitación de copias de seguridad en la región 2, suscripción 1 (almacén 4)

Igual que en el paso 2.

Realizar una copia de seguridad de un Grupo de Disponibilidad que abarca en Azure y en el entorno local

Azure Backup para SQL Server no se puede ejecutar en el entorno local. Si el nodo principal está en Azure y los nodos de Azure cumplen con la preferencia de copia de seguridad, puede seguir las directrices mencionadas anteriormente para el grupo de disponibilidad de varias regiones con el fin de habilitar las copias de seguridad de las réplicas en Azure. Si se produce una conmutación por error al nodo local, se comenzarán a producir errores en las copias de seguridad completas y diferenciales en Azure. Las copias de seguridad de registros pueden continuar hasta que se produzca una interrupción en la cadena de registros o pasen 15 días.

Limitación de trabajos de copia de seguridad en una base de datos de grupo de disponibilidad (AG)

Actualmente, los límites de regulación de copia de seguridad se aplican al nivel de máquina individual. El límite predeterminado es 20: si se desencadenan más de 20 copias de seguridad simultáneamente, se ejecutarán las primeras 20 y las demás se pondrán en cola. Una vez completados los trabajos en ejecución, los trabajos en cola comenzarán a ejecutarse.

Puede cambiar este valor por uno menor si las copias de seguridad simultáneas provocan sobrecarga de memoria, E/S o CPU en el nodo. Dado que la limitación se produce a nivel de nodo, tener nodos AG no equilibrados puede provocar problemas de sincronización de copia de seguridad. Para entenderlo, considere la posibilidad de usar un grupo de disponibilidad de 2 nodos, por ejemplo.

Por ejemplo, el primer nodo tiene 50 bases de datos autónomas protegidas y ambos nodos tienen 5 bases de datos AG protegidas. De hecho, el nodo 1 tiene programados 55 trabajos de copia de seguridad de base de datos, mientras que el nodo 2 solo tiene 5. Además, todas estas copias de seguridad están configuradas para ejecutarse al mismo tiempo, cada hora. En un momento dado, las 55 copias de seguridad se activarán en el nodo 1 y 35 de estas serán puestas en cola. Algunas de estas serían las copias de seguridad de la base de datos de AG. No obstante, en el nodo 2, las copias de seguridad de bases de datos del AG continuarían sin ponerse en cola.

Dado que los trabajos de base de datos del grupo de disponibilidad se ponen en cola en un nodo y se ejecutan en otro, la sincronización de copias de seguridad (mencionada en la sección 6) no funcionará correctamente. El nodo 2 podría suponer que el nodo 1 está fuera de servicio y, por lo tanto, los trabajos de allí no se están incluyendo en la sincronización. Esto puede provocar interrupciones en la cadena de registros o copias de seguridad adicionales, ya que ambos nodos pueden realizar copias de seguridad de forma independiente.

Puede producirse un problema similar si el número de bases de datos de AG protegidas supera el límite de regulación. En tal caso, la copia de seguridad de, por ejemplo, DB1 se puede poner en cola en el nodo 1, mientras se ejecuta en el nodo 2.

Se recomienda usar las siguientes preferencias de copia de seguridad para evitar estos problemas de sincronización:

  • Para un grupo de disponibilidad de 2 nodos, establezca la Preferencia de copias de seguridad en Primario o Solo secundario. De este modo, solo un nodo podrá realizar copias de seguridad y el otro siempre quedará excluido.
  • En el caso de un grupo de disponibilidad con más de 2 nodos, establezca Preferencia de copia de seguridad en Principal; de este modo, solo el nodo principal puede realizar las copias de seguridad y los demás se retirarán.

Facturación de copias de seguridad de GA

Del mismo modo que con una instancia de SQL independiente, una instancia de AG de la que se ha realizado una copia de seguridad se considera una instancia protegida. Se cobra el tamaño total de front-end de todas las bases de datos protegidas de una instancia. Tenga en cuenta la siguiente implementación:

Diagrama que muestra el cálculo de instancias protegidas de bases de datos.

Las instancias protegidas se calculan de la siguiente manera:

Instancia protegida o instancia de facturación Bases de datos que se consideran para calcular el tamaño de front-end
AG1 DB1, DB2
AG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

Traslado de una base de datos protegida dentro o fuera de un AG

Azure Backup considera instancia SQL o nombre de AG\nombre de base de datos como el identificador único de la base de datos. Cuando la base de datos independiente estaba protegida, su nombre único era StandAloneInstanceName\DBName. Cuando se mueve bajo un AG, el nombre único cambia a AGName\DBName. Las copias de seguridad de la base de datos independiente empezarán a fallar con el código de error: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

La base de datos debe configurarse para la protección desde debajo del AG. Se tratará como un nuevo origen de datos con una cadena de puntos de recuperación independiente. La protección anterior de la base de datos independiente se puede detener con la conservación de datos para evitar que se desencadenen futuras copias de seguridad y generen errores en esta. Del mismo modo, cuando una base de datos de grupo de disponibilidad protegida se excluye del grupo de disponibilidad y se convierte en una base de datos independiente, sus copias de seguridad comienzan a generar errores con el código UserErrorBackupFailedDatabaseMovedOutOfAG.

La base de datos debe configurarse para garantizar la protección dentro de la instancia independiente. Se tratará como un nuevo origen de datos con una cadena de puntos de recuperación independiente. La protección anterior de la base de datos AG se puede detener con la retención de datos para evitar que futuras copias de seguridad se desencadenen y generen errores en ella.

Adición o eliminación de un nodo en un grupo de disponibilidad

Cuando se agrega un nuevo nodo a un grupo de disponibilidad configurado para las copias de seguridad, las extensiones de copia de seguridad de la carga de trabajo que se ejecutan en los nodos de grupo de disponibilidad ya registrados detectan el cambio de topología del grupo de disponibilidad e informan al servicio Azure Backup durante el siguiente trabajo de detección de base de datos programado. Cuando este nuevo nodo se registra para las copias de seguridad en la misma bóveda de servicios de recuperación que los demás nodos existentes, el servicio de Azure Backup desencadena un flujo de trabajo que configura este nuevo nodo con los metadatos necesarios para realizar copias de seguridad de AG.

Después de esto, el nuevo nodo sincroniza la información de programación de copia de seguridad del grupo de disponibilidad del servicio Azure Backup y comienza a participar en el proceso de copia de seguridad sincronizado. Si el nuevo nodo no puede sincronizar las programaciones de copia de seguridad y participar en las copias de seguridad, al desencadenar un nuevo registro en el nodo también se fuerza la reconfiguración del nodo para las copias de seguridad del grupo de disponibilidad. De manera similar a la incorporación de nodos, las extensiones de carga de trabajo detectan el cambio de topología en el AG (grupo de disponibilidad) en este caso e informan al servicio de Azure Backup. El servicio inicia un flujo de trabajo de desconfiguración en el nodo eliminado para borrar las programaciones de copia de seguridad de las bases de datos de AG y eliminar los metadatos relacionados con AG.

Anular el registro de un nodo AG de Azure Backup

Si un nodo forma parte de un grupo de disponibilidad que tiene una o varias bases de datos configuradas para la copia de seguridad, Azure Backup no permite anular el registro de ese nodo. Esto es para evitar futuros errores de copia de seguridad en caso de que no poder satisfacer la preferencia de copia de seguridad sin este nodo. Para desregistrar el nodo, primero debe quitarlo del Grupo de Disponibilidad (AG). Cuando se complete el flujo de trabajo de desconfiguración del nodo, puede anular el registro del nodo al limpiarlo.

Restaurar una base de datos desde Azure Backup a un grupo de disponibilidad de SQL. Los grupos de disponibilidad de SQL no admiten la restauración directa de una base de datos en un grupo de disponibilidad. La base de datos debe restaurarse en una instancia de SQL independiente y, a continuación, unirse a un grupo de disponibilidad (AG).

Escenarios de recreación de grupos de disponibilidad para el servidor de base de datos SQL

La recreación de un grupo de disponibilidad (AG), los AG duplicados y los elementos de copia de seguridad se enumeran como elementos protegibles o elementos protegidos en los siguientes escenarios:

  • Recrear AGs que ya están protegidos hace que aparezcan como AGs duplicados en la página Configurar copia de seguridad y en la lista Elementos protegidos. Si quiere conservar los datos de la copia de seguridad que ya están presentes en el AG más antiguo, detenga la copia de seguridad utilizando la opción Detener la protección y conservar los datos antes de volver a crear y programar las copias de seguridad en los nuevos elementos del AG.

    De manera predeterminada, Azure Backup enumera los elementos duplicados en la Lista de elementos protegidos, y en la página Configurar copia de seguridad o en la Lista de elementos protegidos y muestra estos elementos hasta que usted quiera conservar los datos de la copia de seguridad.

  • Si no quiere los datos de la copia de seguridad del AG más antiguo, detenga la operación de copia de seguridad usando la opción Detener protección y eliminar datos para el elemento más antiguo antes de volver a crear y programar las copias de seguridad en el nuevo AG.

    Precaución

    Detener la protección y eliminar datos es una operación destructiva.

  • Puede volver a crear el AG para evitar fallos en las copias de seguridad, después de realizar uno de los procesos anteriores de detener protección.

Pasos siguientes

Obtenga información sobre cómo:

Contenido relacionado

  • Last updated on