Seleccionar un método de recuperación ante desastres

Copia de seguridad y restauración de volúmenes en bloque

El objetivo principal de las copias de seguridad es dar soporte a la continuidad del negocio, la recuperación de fallos y el archivado a largo plazo.

Los siguientes son casos de uso comunes para las copias de seguridad de volumen en bloque:

Creación de varias copias del mismo volumen. Las copias de seguridad son útiles cuando necesita instancias con muchos volúmenes que deben contener los mismos datos.
Realizar una instantánea que puede restaurar a un nuevo volumen más tarde.
Garantizar que dispone de una copia fiable de los datos en caso de que algo vaya mal con el volumen principal.

Al definir el plan y los objetivos de copia de seguridad, tenga en cuenta los siguientes factores:

Frecuencia: cada cuánto tiempo hace copia de seguridad de los datos.
Hora de recuperación: cuánto tiempo puede esperar para que la copia de seguridad sea restaurada y accesible para las aplicaciones que la usan. El tiempo de creación de una copia de seguridad depende de varios factores, como el tamaño de los datos de los que se está realizando la copia de seguridad y la cantidad de datos que han cambiado desde la última copia de seguridad.
Número de copias de seguridad almacenadas: cuántas copias de seguridad debe tener disponibles y el programa de eliminación para las copias de seguridad que ya no necesite.

Al crear copias de seguridad y restaurar a partir de ellas, tenga en cuenta las siguientes mejores prácticas:

Antes de crear una copia de seguridad, asegúrese de que los datos son coherentes: sincronice el sistema de archivos, desmonte el sistema de archivos si es posible y guarde los datos de la aplicación. Solo se copia de seguridad de los datos del disco. Al crear una copia de seguridad, después de cambiar el estado de la copia de seguridad de REQUEST_RECEIVED a CREATING, puede reanudar la escritura de los datos en el volumen. Mientras haya una copia de seguridad en curso, no se puede suprimir el volumen del que se está realizando una copia de seguridad.
Si desea asociar un volumen restaurado a una instancia informática que tenga el volumen original asociado, tenga en cuenta que algunos sistemas operativos no soportan la restauración de volúmenes idénticos. Para superar esta restricción, cambie los ID de partición antes de restaurar el volumen. Los pasos para cambiar el ID de partición de un sistema operativo dependen del sistema operativo. Consulte la documentación del sistema operativo de su instancia informática.
No suprima el volumen original hasta que haya verificado que la copia de seguridad se ha creado correctamente.

Si la aplicación utiliza varios volúmenes que abarcan más de una instancia informática, utilice copias de seguridad de grupos de volúmenes. Los grupos de volúmenes simplifican el proceso de creación de copias de seguridad y clones para aplicaciones que utilizan varios volúmenes en varias instancias. Puede restaurar un grupo completo de volúmenes desde una copia de seguridad de grupo de volúmenes, como se muestra en el siguiente diagrama.

A continuación, se muestra la descripción de volume-backup-restore.png

Descripción de la ilustración volume-backup-restore.png

Crear una luz piloto

El término luz de piloto se refiere a una pequeña llama en un calentador tradicional alimentado por gas que siempre está encendido y se puede utilizar para reiniciar rápidamente el calentador cuando lo disparan sensores de temperatura en la casa. En el contexto de la recuperación ante desastres, una luz piloto consta de los componentes esenciales de la aplicación, desplegados en el sitio de recuperación ante desastres y que contienen la última configuración de la aplicación y los datos críticos. Estos componentes básicos de luz piloto se pueden utilizar para restaurar un entorno de tamaño de producción en caso de desastre.

Los siguientes son los componentes críticos de la luz piloto en el sitio de DR:

Capa de Base de Datos
El servicio Oracle Cloud Infrastructure Database permite aprovisionar toda la base de datos en el sitio de recuperación ante desastres (dominio de disponibilidad, región o ambos) sin activar recursos de tamaño de producción. Cuando la recuperación ante desastres está activada, puede activar más recursos, con una única llamada de API de REST al servicio sin reiniciar el servidor de base de datos.
Capa de Aplicaciones
Solo puede desplegar un servidor de aplicaciones en su sitio de DR (dominio de disponibilidad, región o ambos) que contenga toda la configuración más reciente. Puede utilizar la función de imágenes personalizadas de Oracle Cloud Infrastructure para realizar copias de seguridad del sistema operativo y las aplicaciones periódicamente y, a continuación, utilizar estas imágenes para aprovisionar nuevos servidores cuando se active el sitio de recuperación ante desastres.

Por ejemplo, si un sitio de producción contiene ocho servidores de aplicaciones, despliega solo un servidor de aplicaciones en el sitio de DR y lo mantiene sincronizado con el sitio principal mediante rsync u otra herramienta. Puede crear una imagen personalizada desde este servidor diariamente en el sitio de DR que se puede utilizar para aprovisionar los siete servidores restantes cuando la DR está activada.
Nivel de red
Utilice las siguientes funciones y servicios de Oracle Cloud Infrastructure a la luz del piloto en el sitio de recuperación ante desastres
- Direcciones IP (privadas y públicas)
- Servicio DNS
- Servicio de equilibrio de carga

Uso de una En Espera Activa

Una base de datos en espera activa (frente a la base de datos en espera montada) es una base de datos en espera que está abierta y de solo lectura al recuperar la base de datos. La base de datos en espera activa requiere la función y la licencia de Active Data Guard.

Con Active Data Guard, la base de datos física en espera se puede aprovechar para las lecturas y los informes, lo que reduce la carga de trabajo potencial en la base de datos primaria. Active Data Guard proporciona una protección de datos completa con reparación automática de bloqueos de corrupciones de datos físicos y comprueba otros tipos de corrupciones de datos, como escrituras perdidas y corrupciones de bloques lógicos. Con el modo de espera montado, también aprovechará muchas de las ventajas de protección de datos, excepto para la reparación automática de bloques de corrupciones de bloques físicos. El tiempo de recuperación (RTO) y la pérdida de datos (RPO) suelen ser muy bajos cuando se realiza un failover a cualquier base de datos en espera, independientemente de si está abierta en modo de solo lectura o no.

Al seleccionar un método de DR, considere si desea recursos simétricos o asimétricos:

Recursos simétricos: esta es la arquitectura recomendada para que la base de datos en espera sea simétrica al sistema principal a fin de garantizar que el rendimiento de la aplicación y la base de datos sea similar o idéntico en el momento de la transición de roles. Esto también garantiza que la base de datos en espera tenga suficientes recursos para mantener el ritmo de la carga de trabajo de producción, de modo que la pérdida de datos sea mínima en el momento de un desastre. Si se despliega como una base de datos activa en espera o con la opción Active Data Guard, la base de datos en espera se abre en modo de solo lectura al proporcionar protección de DR. Esto permite descargar informes y consultas.
Recursos asimétricos: esta arquitectura es una configuración de reducción vertical del entorno en espera. Con Active Data Guard, la base de datos en espera puede seguir siendo de solo lectura y ofrecer las mismas ventajas para descargar el trabajo en espera. Sin embargo, después del failover, es posible que el rendimiento no sea el mismo a menos que escale el sistema para que coincida con el principal.

Los sistemas en espera asimétricos o más pequeños cuestan menos, pero pueden tener menos recursos informáticos, CPU y memoria para reducir los costos. La transferencia es posterior a una transición de rol o a un evento de failover; debe escalar verticalmente (ampliar) para que coincida con el sistema principal anterior, o aceptar un rendimiento inferior o una funcionalidad reducida.

Uso de una espera en frío

El término en espera en frío se utiliza para describir un escenario de DR en el que se despliega una réplica redundante del entorno principal en un sitio de DR. El entorno en espera en frío sólo se activa si falla el sistema principal. Este enfoque proporciona continuidad a la producción con un tiempo de activación bien definido para el switchover.

Oracle Cloud Infrastructure soporta el despliegue automatizado (programático) de un entorno en espera inactivo que reduce al mínimo el costo de mantener dicho entorno. Se le facturará solo por los recursos activos y cualquier almacenamiento persistente que consuma en el sitio de DR.