Una pregunta frecuente acerca del uso de las copias Snapshot como estrategia de protección de datos es el hecho de que los datos «reales» y los datos de copias Snapshot se encuentran en las mismas unidades. La pérdida de esas unidades provocaría la pérdida de los datos primarios y el backup.

Este es un problema válido. Los snapshots locales se usan para necesidades de backup y recuperación diarias y, en ese sentido, la snapshot es un backup. Cerca del 99 % de todos los escenarios de recuperación en entornos NetApp utilizan copias Snapshot para satisfacer incluso los requisitos de objetivo de tiempo de recuperación más agresivos.

Sin embargo, las copias Snapshot locales nunca deberían ser la única estrategia de backup, por lo que NetApp ofrece tecnología como la replicación de SnapMirror y SnapVault para replicar de forma rápida y eficiente copias Snapshot en un conjunto de unidades independiente. En una solución correctamente diseñada con copias Snapshot y replicación Snapshot, el uso de la cinta puede minimizarse tal vez a un archivo trimestral o eliminarse totalmente.

Existen muchas opciones para usar las copias Snapshot de ONTAP para proteger los datos, y las copias Snapshot son la base de muchas otras funciones de ONTAP, como replicación, recuperación ante desastres y clonación. Una descripción completa de la tecnología de instantáneas está fuera del alcance de este documento, pero en las siguientes secciones se proporciona una descripción general.

Existen dos métodos principales para crear una copia Snapshot de un conjunto de datos:

Un backup coherente con los fallos de un conjunto de datos hace referencia a la captura de toda la estructura del conjunto de datos en un único punto de tiempo. Si el conjunto de datos se almacena en un único volumen, el proceso es sencillo; se puede crear una copia Snapshot en cualquier momento. Si un conjunto de datos abarca volúmenes, es necesario crear una snapshot de grupo de coherencia (CG). Existen varias opciones para crear snapshots de CG, como el software NetApp SnapCenter, funciones nativas del grupo de coherencia ONTAP y scripts que se mantienen por el usuario.

Los backups coherentes con los fallos se utilizan principalmente cuando la recuperación punto del backup es suficiente. Cuando se necesita una recuperación más granular, por lo general se necesitan backups coherentes con las aplicaciones.

A menudo, la palabra «consistente» en «coherente con las aplicaciones» resulta una denominación errónea. Por ejemplo, colocar una base de datos de Oracle en modo de backup se denomina backup coherente con las aplicaciones, pero los datos no se hacen coherentes ni se ponen en modo inactivo de ninguna forma. Los datos siguen cambiando durante el backup. Por el contrario, la mayoría de los backups de MySQL y Microsoft SQL Server realmente ralentizan los datos antes de ejecutar el backup. VMware puede o no hacer que ciertos archivos sean consistentes.

El término «grupo de coherencia» hace referencia a la capacidad de una cabina de almacenamiento para gestionar varios recursos de almacenamiento como una sola imagen. Por ejemplo, una base de datos puede consistir en 10 LUN. La cabina debe ser capaz de realizar backup, restaurar y replicar esos 10 LUN de forma coherente. La restauración no es posible si las imágenes de las LUN no eran consistentes en el punto de backup. Para replicar estos 10 LUN es necesario que todas las réplicas estén perfectamente sincronizadas entre sí.

ONTAP siempre ha sido capaz de capturar imágenes locales y replicadas de datos coherentes. Aunque los distintos volúmenes de un sistema ONTAP AFF/FAS no suelen describirse formalmente como un grupo de coherencia, eso es lo que son. Una instantánea de ese volumen es una imagen de grupo de coherencia, la restauración de esa instantánea es una restauración de grupo de coherencia, y tanto SnapMirror como SnapVault ofrecen replicación de grupo de coherencia.

Los sistemas AFF también incluyen un tipo más amplio de grupo de consistencia. Se pueden definir múltiples volúmenes como un CG dentro de ONTAP. Las snapshots, los clones y la replicación se pueden configurar a nivel de CG. Esto simplifica las estrategias de protección de datos porque permite establecer políticas en conjuntos de datos, no solo en volúmenes o LUNs individuales. Los CGs también existen en sistemas ASA. Múltiples LUNs o espacios de nombres pueden unirse como un CG y ese CG puede luego protegerse con snapshots, replicarse, restaurarse o clonarse.

Las instantáneas de grupo de consistencia (CG) son una extensión de la tecnología básica de ONTAP Snapshot. Una operación de instantánea estándar crea una imagen consistente de todos los datos dentro de un único volumen AFF/FAS o LUN/namespace ASA, pero a veces es necesario crear un conjunto consistente de instantáneas a través de múltiples recursos de almacenamiento e incluso a través de múltiples sistemas de almacenamiento. El resultado es un conjunto de instantáneas que se pueden utilizar del mismo modo que una instantánea de un solo volumen individual. Se pueden utilizar para la recuperación de datos local, replicarse con fines de recuperación ante desastres o clonarse como una única unidad coherente.

Las instantáneas CG se escalan extremadamente bien. El mayor uso conocido de una instantánea CG es para un entorno de bases de datos de aproximadamente 1PB de tamaño que abarca 12 controladores. Las instantáneas CG creadas en este sistema se han utilizado para backup, recuperación y clonación.

La mayoría de las veces, cuando un conjunto de datos abarca volúmenes AFF o LUNs/espacios de nombres ASA, y se debe preservar el orden de escritura, simplemente se puede definir un grupo de coherencia ONTAP y el grupo de volúmenes, LUNs o espacios de nombres se puede gestionar de forma nativa para crear snapshots. Si se utiliza software de gestión, debe detectar la necesidad de snapshots de un grupo de coherencia y llamar a las API necesarias.

En estos casos, no es necesario comprender los detalles técnicos de las instantáneas CG. Sin embargo, hay situaciones en las que los complicados requisitos de protección de datos requieren un control detallado del proceso de protección y replicación de datos. Algunas opciones son los flujos de trabajo automatizados o el uso de secuencias de comandos personalizadas para llamar a las API de instantáneas CG. Para comprender cuál es la mejor opción y la función de las instantáneas CG, es necesaria una explicación más detallada de la tecnología.

La creación de un conjunto de instantáneas de grupo de coherencia es un proceso de dos pasos:

El cercado de escritura se establece en serie. Esto significa que, a medida que el proceso de cercado se configura en varios objetivos de almacenamiento, la E/S de escritura se congela en el primer objeto de la secuencia y sigue congelada en los objetivos que aparecen después en la lista. Esto podría parecer al principio que viola el requisito de que se preserve el orden de escritura, pero eso solo aplica a la E/S que se emite de forma asíncrona en el host y que no depende de ninguna otra escritura.

Por ejemplo, una base de datos puede emitir muchas actualizaciones de archivos de datos asíncronos y permitir que el sistema operativo vuelva a ordenar la I/O y completarlas de acuerdo con su propia configuración del programador. El orden de este tipo de I/O no se puede garantizar porque la aplicación y el sistema operativo ya han liberado el requisito de conservar el orden de escritura.

Como contraejemplo, la mayor parte de la actividad de registro de la base de datos es sincrónica. La base de datos no procede con más escrituras de registro hasta que la E/S es reconocida, y el orden de esas escrituras debe ser preservado. Si una E/S de registro llega a un LUN vallado, no es reconocida y la aplicación bloquea las escrituras posteriores. Del mismo modo, la E/S de metadatos del sistema de archivos suele ser sincrónica. Por ejemplo, una operación de borrado de un archivo no debe perderse. Si un sistema operativo con un sistema de archivos xfs borrara un archivo y la E/S que actualizara los metadatos del sistema de archivos xfs para eliminar la referencia a ese archivo aterrizara en un LUN cercado, entonces la actividad del sistema de archivos se detendría. Esto garantiza la integridad del sistema de archivos durante las operaciones CG.

Una vez configurado el cercado de escritura en los destinos, están listos para la creación de instantáneas. No es necesario que las instantáneas se creen exactamente al mismo tiempo porque el estado de los destinos está congelado desde un punto de vista de escritura dependiente. Para evitar un fallo en la aplicación que crea las instantáneas CG, el cercado de escritura inicial incluye un tiempo de espera configurable en el que ONTAP libera automáticamente el cercado y reanuda el procesamiento de escritura después de un número definido de segundos. Si todas las instantáneas se crean antes de que transcurra el tiempo de espera, el conjunto resultante de instantáneas es un grupo de coherencia válido.

Existen dos enfoques principales para los backups basados en Snapshot:

Un backup coherente con los fallos de una base de datos se refiere a la captura de toda la estructura de la base de datos, incluidos los archivos de datos, los registros de recuperación y los archivos de control, en un único momento. Si la base de datos se almacena en un único volumen, LUN o espacio de nombres, el proceso es sencillo; se puede crear una snapshot en cualquier momento. Si una base de datos abarca volúmenes AFF o LUN/espacios de nombres ASA, se debe crear una snapshot de grupo de coherencia (CG). Existen varias opciones para crear snapshots de CG, incluido el NetApp SnapCenter software, las funciones nativas de grupo de coherencia de ONTAP y las secuencias de comandos mantenidas por el usuario.

Las copias de seguridad instantáneas coherentes con los fallos se utilizan principalmente cuando la recuperación en el punto de backup es suficiente. Los registros de archivo se pueden aplicar en algunas circunstancias, pero cuando se requiere una recuperación más granular en un momento específico, es preferible un backup en línea.

El procedimiento básico para un backup en línea basado en Snapshot es el siguiente:

Este procedimiento produce un juego de instantáneas que contienen archivos de datos en modo de backup y los archive logs críticos generados durante el modo de backup. Estos son los dos requisitos para recuperar una base de datos. Los archivos, como los archivos de control, también deben protegerse por conveniencia, pero el único requisito absoluto es la protección de los archivos de datos y los registros de archivos.

Aunque los diferentes clientes pueden tener estrategias muy diferentes, casi todas estas estrategias se basan en última instancia en los mismos principios descritos a continuación.

Cuando se diseñan distribuciones de almacenamiento para bases de datos Oracle, la primera decisión es si se va a utilizar la tecnología basada en volúmenes NetApp SnapRestore (VBSR), que es la tecnología subyacente utilizada para restaurar volúmenes AFF y LUN/namespaces ASA.

VBSR permite que los datos sean revertidos casi instantáneamente a un punto anterior en el tiempo. Debido a que todos los datos son revertidos, VBSR puede no ser apropiado para todos los casos de uso. Por ejemplo, si una base de datos entera, incluyendo datafiles, redo logs y archive logs, está almacenada en un solo volumen AFF y este volumen es restaurado con VBSR, entonces los datos se pierden porque el archive log y los datos de redo más recientes son descartados. Lo mismo se aplica a los datos de ASA. Si toda la base de datos estaba almacenada en un único grupo de consistencia ASA, y ese CG fue restaurado a un estado anterior, algunos de los datos posteriores de archive log y redo se perderán.

VBSR no es necesario para la restauración. Muchas bases de datos pueden restaurarse utilizando la restauración basada en archivos de archivo único SnapRestore (SFSR) o simplemente clonando archivos de la snapshot de nuevo en el sistema de archivos activo.

VBSR es preferible cuando una base de datos es muy grande o cuando debe ser recuperada tan rápido como sea posible, y el uso de VBSR requiere aislamiento de los datafiles. En un entorno de NFS, los datafiles de una base de datos dada deben ser almacenados en volúmenes dedicados que no estén contaminados por ningún otro tipo de archivo. En un entorno SAN, los datafiles deben almacenarse en LUNs o namespaces dedicados. Si se utiliza un gestor de volúmenes (incluyendo Oracle Automatic Storage Management [ASM]), el diskgroup también debe estar dedicado a los datafiles.

Aislar los archivos de datos de esta manera permite revertirlos a un estado anterior sin dañar otros sistemas de archivos.

Para cada volumen con datos de Oracle en un entorno SAN AFF, la percent-snapshot-space debe establecerse en cero porque reservar espacio para una reserva de snapshot en un entorno LUN no es útil. Si la reserva fraccionaria se establece en 100, una snapshot de un volumen con LUN requiere suficiente espacio libre en el volumen, excluyendo la reserva de snapshot, para absorber el 100% de la rotación de todos los datos. Si la reserva fraccionaria se establece en un valor inferior, entonces se requiere una cantidad correspondientemente menor de espacio libre, pero siempre excluye la reserva de snapshot. Esto significa que el espacio de reserva de snapshot en un entorno LUN se desperdicia.

En un entorno NFS, hay dos opciones:

Con la primera opción, percent-snapshot-space se establece en un valor distinto de cero, normalmente alrededor del 20%. Este espacio se oculta al usuario. Sin embargo, este valor no crea un límite de utilización. Si una base de datos con una reserva del 20% experimenta una rotación del 30%, el espacio de la instantánea puede crecer más allá de los límites de la reserva del 20% y ocupar espacio sin reservar.

La principal ventaja de establecer una reserva en un valor como 20% es verificar que algo de espacio esté siempre disponible para las instantáneas. Por ejemplo, un volumen de 1TB GB con una reserva del 20% solo permitiría que un administrador de bases de datos (DBA) almacene 800GB TB de datos. Esta configuración garantiza al menos 200GB MB de espacio para el consumo de snapshots.

Cuando percent-snapshot-space se establece en cero, todo el espacio del volumen está disponible para el usuario final, lo que proporciona una mejor visibilidad. Un administrador de bases de datos debe comprender que, si ve un volumen de 1TB GB que aprovecha las copias Snapshot, este espacio de 1TB TB se compartirá entre los datos activos y la rotación de copias Snapshot.

No hay una preferencia clara entre la opción uno y la opción dos entre los usuarios finales.

El ID de documento de Oracle 604683,1 explica los requisitos para la compatibilidad con Snapshot de terceros y las múltiples opciones disponibles para las operaciones de backup y restauración.

El proveedor externo debe garantizar que las copias Snapshot de la empresa cumplen con los requisitos siguientes:

Los productos de gestión de Oracle de ONTAP y NetApp cumplen estos requisitos.