Introducción a la continuidad empresarial con Azure SQL Database
Se aplica a: 
Azure SQL Database Base de datos SQL en Fabric
En este artículo se proporciona información general sobre las funcionalidades de continuidad empresarial y recuperación ante desastres de Azure SQL Database, que describen las opciones y recomendaciones para recuperarse de eventos perjudiciales que podrían provocar la pérdida de datos o hacer que la instancia y la aplicación no estén disponibles. Aprende qué hacer en caso de que un error del usuario o la aplicación afecte a la integridad de los datos, se produzca una interrupción en una zona de disponibilidad o región de Azure o tu aplicación requiera mantenimiento.
Información general
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.
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 componente de hardware.
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 %.
Alta disponibilidad
Para lograr una alta disponibilidad en el entorno de nube de Azure, habilita la redundancia de zona para que la base de datos o el grupo elástico use zonas de disponibilidad y se garantice que la base de datos o el grupo elástico sean resistentes 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 |
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 local y de software, SQL Database incluye una arquitectura de disponibilidad que garantiza una recuperación automática de estos errores con un Acuerdo de Nivel de Servicio de disponibilidad del 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 poco común del centro de datos o la zona de disponibilidad, posiblemente causada por un evento de desastre natural, cambios en la configuración, errores de software o errores de componentes 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 %. |
| Interrupción regional poco frecuente que afecta a todas las zonas de disponibilidad y los centros de datos que la 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. |
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. El tiempo necesario para que una aplicación se recupere totalmente se conoce como objetivo de tiempo de recuperación (RTO, por sus siglas en inglés). También debes conocer el período máximo de actualizaciones de datos recientes (intervalo de tiempo) que la aplicación puede tolerar perder al recuperarse de un evento de interrupción no planeado. La posible pérdida de datos se conoce como objetivo de punto de recuperación (RPO).
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 migración tras error con la directiva de migración tras 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 | Normalmente, minutos o horas |
Listas de comprobación de continuidad empresarial
Para obtener recomendaciones prescriptivas para maximizar la disponibilidad y lograr una mayor continuidad empresarial, consulta:
- Lista de comprobación de disponibilidad
- Lista de comprobación de alta disponibilidad
- Lista de comprobación de recuperación de desastres
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) te permite crear una base de datos en el mismo servidor que represente el estado de los datos antes del evento de daño. Para la mayoría de las bases de datos, las operaciones de restauración tardan menos de 12 horas. La recuperación de una base de datos muy grande o muy activa puede tardar más tiempo. Para más información, consulta tiempo de recuperación de la base de datos.
Si el período de retención de la restauración a un momento dado máximo admitido no es suficiente para tu aplicación, puedes ampliarlo mediante la configuración de una directiva de retención a largo plazo (LTR) para las bases de datos. Para obtener más información, vea Retención de copias de seguridad 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. En el artículo Administración de actualizaciones graduales de aplicaciones se explica cómo utilizar la replicación geográfica activa para poder actualizar gradualmente su aplicación en la nube con el objetivo de minimizar el tiempo de inactividad durante este proceso. Además, se describe una ruta de recuperación para cuando se empiece a detectar errores.
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.
Pasos siguientes
Si deseas obtener información sobre las consideraciones de diseño de aplicaciones, consulta Diseño de una aplicación para la recuperación ante desastres en la nube y Estrategias de recuperación ante desastres para los grupos elásticos.
Revise la Guía de recuperación ante desastres de Azure SQL Database y la Lista de comprobación de alta disponibilidad y recuperación ante desastres de Azure SQL Database.