El diseño más simple se muestra en la siguiente figura.

Este es el enfoque más común. Desde el punto de vista del DBA, puede parecer inusual colocar todas las copias de los redo logs y archive logs en el mismo volumen. Sin embargo, la separación no ofrece mucha protección adicional cuando los archivos y las LUN aún se encuentran en el mismo conjunto de unidades subyacente.

En ocasiones, es necesario separar los redo logs debido a problemas de protección de datos o a la necesidad de distribuir E/S de redo log entre las controladoras. Si es así, la distribución de tres volúmenes que se muestra en la siguiente figura se utilizará para la replicación sin dejar de tener que realizar recuperaciones incompletas o depender de los archivos de control de backup.

Esto permite la segmentación de los redo logs y los archivos de control en conjuntos independientes de discos y controladores en el origen. Sin embargo, los archive logs y un juego de archivos de control y redo logs se pueden replicar en un estado sincronizado con los archive logs.

En este modelo, el volumen Redo Log B no se replica.

Para realizar la recuperación ante desastres mediante backups activos, utilice el siguiente procedimiento básico:

La recuperación desde backups optimizados para snapshots es prácticamente idéntica al procedimiento de recuperación de backup en caliente con los siguientes cambios:

Estas diferencias simplifican el procedimiento de recuperación general, ya que no hay ningún requisito para asegurarse de que se creó correctamente una copia Snapshot en el origen mientras la base de datos estaba en modo de backup dinámico. El procedimiento de recuperación ante desastres se basa en las marcas de tiempo de los snapshots del sitio de recuperación ante desastres. El estado de la base de datos cuando se crearon las instantáneas no es importante.

Este es un ejemplo de estrategia de recuperación ante desastres basada en la replicación de snapshots de backup en caliente. También sirve como ejemplo de estrategia de backup local sencilla y escalable.

La base de datos de ejemplo se encuentra en una arquitectura de dos volúmenes básica. /oradata contiene archivos de datos y. /oralogs se utiliza para la combinación de redo logs, archive logs y archivos de control.

Se requieren dos programaciones, una para los backups de archivos de datos nocturnos y otra para los backups de archivos de registro. Estos se llaman medianoche y 15minutes, respectivamente.

Estas programaciones se utilizan dentro de las políticas de snapshot NTAP-datafile-backups y.. NTAP-log-backups, como se muestra a continuación:

Por último, estas políticas de snapshots se aplican a los volúmenes.

Esto define la programación de backup de los volúmenes. Las instantáneas de archivos de datos se crean a medianoche y se conservan durante 60 días. El volumen de registro contiene 72 copias de Snapshot creadas a intervalos de 15 minutos, lo que suma 18 horas de cobertura.

A continuación, asegúrese de que la base de datos esté en modo de backup dinámico cuando se cree una snapshot de archivo de datos. Esto se hace con un pequeño script que acepta algunos argumentos básicos que inician y paran el modo de copia de seguridad en el SID especificado.

En este paso se garantiza que la base de datos esté en modo backup dinámico durante una ventana de cuatro minutos que rodea la instantánea de medianoche.

La replicación en el sitio de recuperación de desastres se configura de la siguiente manera:

El destino del volumen de registro se actualiza cada 15 minutos. Esto proporciona un objetivo de punto de recuperación de aproximadamente 15 minutos. El intervalo de actualización preciso varía un poco dependiendo del volumen total de datos que se deben transferir durante la actualización.

El destino del volumen del archivo de datos se actualiza cada seis horas. Esto no afecta al objetivo de punto de recuperación ni al objetivo de tiempo de recuperación. Si se requiere recuperación ante desastres, uno de los primeros pasos es restaurar el volumen del archivo de datos en una instantánea de backup en caliente. La finalidad del intervalo de actualización más frecuente es suavizar la tasa de transferencia de este volumen. Si la actualización está programada para una vez al día, todos los cambios acumulados durante el día deben transferirse a la vez. Con actualizaciones más frecuentes, los cambios se replican más gradualmente a lo largo del día.

Si se produce un desastre, el primer paso es interrumpir los reflejos de ambos volúmenes:

Ahora las réplicas son de lectura y escritura. El siguiente paso es verificar la marca de tiempo del volumen de registro.

La copia más reciente del volumen de registro es el 14th de marzo a las 13:30:00.

A continuación, identifique la snapshot de backup activo creada inmediatamente antes del estado del volumen de registro. Esto es necesario porque el proceso de reproducción de log requiere que todos los archive logs se creen durante el modo de copia de seguridad activa. Por lo tanto, la réplica del volumen de registro debe ser más antigua que las imágenes de backup activo o no contener los registros requeridos.

La instancia de Snapshot creada más recientemente es midnight.2017-03-14_0000. Esta es la imagen de backup en caliente más reciente de los archivos de datos y se restaura de la siguiente manera:

En esta etapa, la base de datos está ahora lista para ser recuperada. Si se trataba de un entorno SAN, el siguiente paso incluiría activar grupos de volúmenes y montar sistemas de archivos, un proceso fácilmente automatizado. Como este ejemplo utiliza NFS, los sistemas de archivos ya están montados y se han convertido en de lectura y escritura sin necesidad de montar o activar más el momento en el que se rompieron los reflejos.

La base de datos se puede recuperar ahora al punto deseado en el tiempo o se puede recuperar completamente con respecto a la copia de los redo logs que se han replicado. En este ejemplo se ilustra el valor del archive log combinado, el archivo de control y el volumen redo log. El proceso de recuperación es significativamente más sencillo, ya que no hay necesidad de depender de los archivos de control de copia de seguridad ni de restablecer los archivos de registro.

El procedimiento de recuperación ante desastres mediante backups optimizados para Snapshot es prácticamente idéntico al procedimiento de recuperación ante desastres del backup activo. Al igual que con el procedimiento de copias Snapshot de backup en caliente, también es esencialmente una extensión de una arquitectura de backup local en la que los backups se replican para su uso en la recuperación ante desastres. En el siguiente ejemplo, se muestra el procedimiento detallado de configuración y recuperación. Este ejemplo también destaca las diferencias clave entre los backups activos y los backups optimizados para Snapshot.

La base de datos de ejemplo se encuentra en una arquitectura de dos volúmenes básica. /oradata contiene archivos de datos y. /oralogs se utiliza para la combinación de redo logs, archive logs y archivos de control.

Se requieren dos programaciones: Una para los backups de archivos de datos nocturnos y otra para los backups de archivos de registro. Estos se llaman medianoche y 15minutes, respectivamente.

Estas programaciones se utilizan dentro de las políticas de snapshot NTAP-datafile-backups y.. NTAP-log-backups, como se muestra a continuación:

Por último, estas políticas de snapshots se aplican a los volúmenes.

De este modo se controla la programación de backup definitiva de los volúmenes. Las copias Snapshot se crean a medianoche y se conservan durante 60 días. El volumen de registro contiene 72 copias de Snapshot creadas a intervalos de 15 minutos, lo que suma 18 horas de cobertura.

La replicación en el sitio de recuperación de desastres se configura de la siguiente manera:

El destino del volumen de registro se actualiza cada 15 minutos. Esto proporciona un objetivo de punto de recuperación de aproximadamente 15 minutos, y el intervalo preciso de actualización varía ligeramente, en función del volumen total de datos que se deben transferir durante la actualización.

El destino del volumen de archivos de datos se actualiza cada 6 horas. Esto no afecta al objetivo de punto de recuperación ni al objetivo de tiempo de recuperación. Si se requiere recuperación ante desastres, primero debe restaurar el volumen del archivo de datos en una instantánea de backup activo. La finalidad del intervalo de actualización más frecuente es suavizar la tasa de transferencia de este volumen. Si la actualización se programó una vez al día, todos los cambios acumulados durante el día deben transferirse a la vez. Con actualizaciones más frecuentes, los cambios se replican más gradualmente a lo largo del día.

Si se produce un desastre, el primer paso es interrumpir los reflejos en todos los volúmenes:

Ahora las réplicas son de lectura y escritura. El siguiente paso es verificar la marca de tiempo del volumen de registro.

La copia más reciente del volumen de registro es el 14th de marzo a las 13:30. A continuación, identifique la snapshot de archivo de datos creada inmediatamente antes del estado del volumen de registro. Esto es necesario porque el proceso de reproducción de log necesita todos los archive logs desde justo antes de la instantánea hasta el punto de recuperación deseado.

La instancia de Snapshot creada más recientemente es midnight.2017-03-14_0000. Restaurar esta instantánea.

La base de datos está ahora lista para ser recuperada. Si se trataba de un entorno SAN, activaría los grupos de volúmenes y montaría sistemas de archivos, un proceso fácilmente automatizado. Sin embargo, este ejemplo utiliza NFS, por lo que los sistemas de archivos ya están montados y se han convertido en de lectura y escritura sin necesidad de montaje o activación en el momento en que se rompieron los reflejos.

La base de datos se puede recuperar ahora al punto deseado en el tiempo o se puede recuperar completamente con respecto a la copia de los redo logs que se han replicado. En este ejemplo se ilustra el valor del archive log combinado, el archivo de control y el volumen redo log. El proceso de recuperación es significativamente más sencillo, ya que no hay necesidad de confiar en los archivos de control de copia de seguridad ni restablecer los archivos de registro.