Continuidad empresarial en Azure SQL Database

2025-06-06

Se aplica a:Azure SQL Database Base de datos SQL en Fabric

La continuidad empresarial en Azure SQL Database hace referencia a los mecanismos, directivas y procedimientos que permiten a tu empresa seguir funcionando frente a la interrupción gracias a la alta disponibilidad y la recuperación ante desastres.

Para obtener recomendaciones prescriptivas para maximizar la disponibilidad y lograr una mayor continuidad empresarial, consulte:

En la mayoría de los casos, SQL Database controla los eventos de interrupción que puedan ocurrir en el entorno en la nube y permite que se sigan ejecutando las aplicaciones y los procesos empresariales. Sin embargo, hay algunos eventos disruptivos en los que la mitigación puede tardar algún tiempo, como los siguientes:

El usuario elimina o actualiza accidentalmente una fila de una tabla.
Un atacante malintencionado consigue eliminar datos o quitar una base de datos.
El evento de desastre natural catastrófico quita un centro de datos o una zona de disponibilidad o región.
Un centro de datos poco frecuente, una zona de disponibilidad o una interrupción en toda la región causado por un cambio de configuración, un error de software o un error de hardware.

Alta disponibilidad

Azure SQL Database incluye una promesa básica de resistencia y confiabilidad que lo protege frente a errores de software o hardware. Las copias de seguridad de bases de datos proporcionan una manera de proteger los datos de daños o eliminaciones accidentales. Al ser una plataforma como servicio (PaaS), el servicio Azure SQL Database proporciona disponibilidad como una característica fuera de la plataforma con un Acuerdo de Nivel de Servicio de disponibilidad líder del sector del 99,99 %.

Para lograr una alta disponibilidad en el entorno de nube de Azure, habilite la redundancia de zona. Con la redundancia de zona, la base de datos o el grupo elástico usa zonas de disponibilidad de Azure para garantizar la resistencia a errores zonales.

Muchas regiones de Azure proporcionan zonas de disponibilidad, que están separadas por grupos de centros de datos dentro de una región que tienen una infraestructura de red, refrigeración y alimentación independientes.
Las zonas de disponibilidad están diseñadas para proporcionar servicios regionales, capacidad y alta disponibilidad en las zonas restantes si una zona experimenta una interrupción.

Al habilitar la redundancia de zona, la base de datos o el grupo elástico es resistente a errores de hardware y software zonales y la recuperación es transparente para las aplicaciones. Cuando la alta disponibilidad está habilitada, el servicio Azure SQL Database puede proporcionar un SLA de mayor disponibilidad del 99,995 %.

Recuperación ante desastres

Para lograr una mayor disponibilidad y redundancia entre regiones, puedes habilitar las funcionalidades de recuperación ante desastres para recuperar rápidamente la base de datos de un error regional catastrófico. Las opciones de recuperación ante desastres para Azure SQL Database son las siguientes:

La replicación geográfica activa te permite crear una base de datos secundaria sincronizada de forma continua y legible en cualquier región para una base de datos principal.
Los grupos de conmutación por error, además de proporcionar sincronización continua entre una base de datos principal y secundaria, también permiten administrar la replicación y la conmutación por error de algunas bases de datos de un servidor lógico en un servidor lógico secundario de otra región. Los grupos de conmutación por error proporcionan puntos de conexión de agente de escucha de solo lectura y de solo lectura que permanecen sin cambios, por lo que la actualización de cadenas de conexión de aplicaciones después de la conmutación por error no es necesaria.
La restauración geográfica te permite recuperarte de una interrupción regional mediante la restauración a partir de copias de seguridad con replicación geográfica, cuando no puedes acceder a la base de datos en la región primaria mediante la creación de una nueva base de datos en cualquier servidor existente de cualquier región de Azure.

En la tabla siguiente se comparan la replicación geográfica activa y los grupos de conmutación por error, dos opciones de recuperación ante desastres para Azure SQL Database:

	Replicación geográfica activa	Grupos de conmutación por error
Sincronización continua de datos entre la base de datos principal y la secundaria	Sí	Sí
Conmutación por error de varias bases de datos simultáneamente	No	Sí
La cadena de conexión permanece sin cambios después de la conmutación por error	No	Sí
Admisión del escalado de lectura	Sí	Sí
Varias réplicas	Sí	No
Posibilidad de estar en la misma región que la principal	Sí	No

RTO y RPO

A medida que desarrolles el plan de continuidad empresarial, tendrás que saber el tiempo máximo aceptable para que la aplicación se recupere por completo tras un evento de interrupción. Dos formas comunes de cuantificar los requisitos empresariales en torno a la recuperación ante desastres son:

Objetivo de tiempo de recuperación (RTO): el tiempo necesario para que una aplicación se recupere completamente después de un evento disruptivo no planeado.
Objetivo de punto de recuperación (RPO): la cantidad de tiempo de pérdida de datos que se puede tolerar desde un evento disruptivo no planeado.

En la tabla siguiente se comparan el RPO y el RTO de cada opción de continuidad empresarial:

Opciones de continuidad empresarial	RTO (sin tiempo de inactividad)	RPO (sin pérdida de datos)
Alta disponibilidad (uso de la redundancia de zona)	Normalmente, menos de 30 segundos	0
Recuperación ante desastres (uso de grupos de conmutación por error con la directiva de conmutación por error administrada por el cliente o la replicación geográfica activa)	Normalmente, menos de 60 segundos	Igual o mayor que 0 (depende de los cambios de datos antes del evento disruptivo que no se ha replicado)
Recuperación ante desastres (mediante la restauración geográfica)	Normalmente, minutos o horas, en función de la replicación de Azure Storage	Normalmente, minutos o horas, dependiendo del tamaño de la copia de seguridad de la base de datos

Características que proporcionan continuidad empresarial

Desde la perspectiva de una base de datos, hay cuatro escenarios principales de posibles interrupciones. En la tabla siguiente se enumeran las características de continuidad empresarial de SQL Database que puede usar para mitigar un posible escenario de interrupción empresarial:

Escenario de interrupción empresarial	Característica de continuidad del negocio
Errores de hardware o software locales que afectan al nodo de la base de datos.	Para mitigar los errores de hardware y software locales, Azure SQL Database incluye una arquitectura de disponibilidad, que garantiza la recuperación automática de estos errores con un acuerdo de nivel de servicio de disponibilidad de hasta 99,99%.
Daños o eliminación de datos que suelen deberse a un error de la aplicación o a un error humano. Estos errores son específicos de la aplicación y el servicio de la base de datos no los detecta.	Para proteger su empresa de la pérdida de datos, SQL Database realiza automáticamente copias de seguridad completas semanales de la base de datos, copias de seguridad diferenciales de la base de datos cada 12 o 24 horas y copias de seguridad del registro de transacciones cada 5 o 10 minutos. De forma predeterminada, las copias de seguridad se almacenan en un almacenamiento con redundancia geográfica durante al menos siete días en todos los niveles de servicio. Todos los niveles de servicio, excepto el soporte técnico Basic, admiten el período de retención de copia de seguridad configurable hasta 35 días para la restauración a un momento dado. Puedes restaurar una base de datos eliminada al momento en que se ha eliminado si el servidor no se ha eliminado o si has configurado la retención a largo plazo (LTR).
Interrupción de un centro de datos o zona de disponibilidad poco frecuente, posiblemente causada por un evento de desastre natural, cambio de configuración, error de software o error de hardware.	Para mitigar la interrupción del nivel de zona de disponibilidad o del centro de datos, habilita la redundancia de zona para que la base de datos o el grupo elástico use Azure Availability Zones y proporcione redundancia en varias zonas físicas dentro de una región de Azure. La habilitación de la redundancia de zona garantiza que la base de datos o el grupo elástico sea resistente a errores zonales con un acuerdo de nivel de servicio de alta disponibilidad de hasta el 99,995 %.
Interrupciones regionales poco frecuentes que afectan a todas las zonas de disponibilidad y los centros de datos que lo componen, posiblemente causados por un desastre natural catastrófico.	Para mitigar una interrupción en toda la región, habilita la recuperación ante desastres mediante una de las siguientes opciones: - Opciones de sincronización de datos continuas, como grupos de conmutación por error (recomendado) o replicación geográfica activa que te permiten crear réplicas en una región secundaria para la conmutación por error. - Establece la opción de redundancia de almacenamiento de copia de seguridad en Almacenamiento de copia de seguridad con redundancia geográfica para usar la restauración geográfica.

Preparación para una interrupción en la región

Independientemente de las características de continuidad empresarial que uses, debe preparar la base de datos secundaria en otra región. Si no se prepara correctamente, el proceso de conectar las aplicaciones después de una conmutación por error o una recuperación llevará más tiempo y, probablemente, también haya que solucionar problemas, lo que puede retrasar el RTO. Siga la lista de comprobación para preparar la base de datos secundaria para una interrupción de la región.

Restauración de una base de datos en la misma región de Azure

Puede usar copias de seguridad de la base de datos automáticas para restaurar una base de datos a un momento anterior. De este modo puede recuperarse de los daños en los datos causados por errores humanos. La restauración a un momento dado (PITR) permite crear una nueva base de datos en el mismo servidor que representa el estado de los datos antes del evento dañado. Para los tiempos de recuperación, consulte RTO y RPO.

Si el período máximo de retención de copia de seguridad admitido para la restauración a un momento dado no es suficiente para la aplicación, puede ampliarlo configurando una directiva de retención a largo plazo (LTR). Para más información, consulte retención a largo plazo.

Actualice una aplicación con el mínimo tiempo de inactividad posible.

A veces, debes desconectar una aplicación debido a una tarea de mantenimiento, por ejemplo, para actualizarla. Puede administrar las actualizaciones graduales de las aplicaciones en la nube mediante la replicación geográfica activa de SQL Database. La replicación geográfica también puede proporcionar una ruta de recuperación si algo va mal.

Ahorre en costos con una réplica en espera

Si la réplica secundaria solo se usa para la recuperación ante desastres (DR) y no tiene ninguna carga de trabajo de lectura o escritura, puede ahorrar en los costos de licencias mediante la designación de la base de datos para espera al configurar una nueva relación de replicación geográfica activa.

Para más información, consulte Réplica en espera sin licencia.

Paso siguiente

Lista de comprobación de alta disponibilidad y recuperación ante desastres

Compartir a través de