NetApp Backup and Recovery admite grupos de Oracle Data Guard
NetApp Backup and Recovery añadió grupos de protección para bases primaria y standby que usan Oracle Data Guard. La integración amplía la cobertura de backup, pero no reemplaza el transporte de redo ni el cambio de roles de Oracle.

NetApp añadió el 19 de octubre soporte para Oracle Data Guard en Backup and Recovery: ahora se pueden usar grupos de protección para incluir bases de datos primaria y standby de una configuración Data Guard. La mejora importa a equipos que ya administran disponibilidad de Oracle y quieren incorporar ambas bases a las operaciones de protección de NetApp. La nota no anuncia un cambio de licencia, una disponibilidad general ni un mecanismo nuevo de failover, así que no conviene completar esos huecos por intuición.
Alta disponibilidad y backup hacen trabajos distintos
Data Guard mantiene una o más copias standby de la base de producción mediante el transporte y la aplicación de redo. Si la primaria deja de estar disponible, Oracle permite cambiar el rol de una standby a primaria; también se pueden descargar ciertas operaciones de backup y reporting a sistemas standby. Es una función de disponibilidad y protección de datos dentro de Oracle, no una copia histórica independiente por sí sola.
Los grupos de protección de NetApp son una manera de reunir recursos de Oracle que se quieren proteger conjuntamente. La novedad es el soporte de miembros con roles primary y standby Data Guard. Eso permite que las operaciones de Backup and Recovery reconozcan ambos lados de una configuración de alta disponibilidad en el modelo de agrupación; no implica que NetApp coordine automáticamente el switchover, replique redo o decida qué base debe atender a las aplicaciones.
-InfraCrew dice: Tener dos bases sincronizadas mejora el plan de continuidad; también duplica las preguntas si el inventario solo conoce la primaria.-
La distinción ayuda a evitar una confusión frecuente: una standby disponible no equivale a un backup recuperable. Data Guard mantiene la copia aplicando cambios y puede cambiar roles; las copias de backup cubren otros escenarios, como corrupción lógica, borrado accidental o recuperación a un punto anterior, según las políticas y retenciones configuradas. Oracle recomienda usar Data Guard junto con backup y restauración tradicionales para una protección más completa.
Qué cambia para las operaciones de protección
Hasta esta mejora, una organización podía tener una arquitectura Data Guard y operar las copias de seguridad desde herramientas separadas o incorporar manualmente sus bases al flujo de backup. NetApp declara que Backup and Recovery ya puede proteger la primaria y la standby mediante protection groups. La ventaja es un ámbito operativo más coherente para equipos que deben comprobar el estado de ambos miembros, sus políticas y las ejecuciones asociadas dentro de la plataforma de protección.
La documentación de Oracle explica que Data Guard envía redo desde la base primaria a una o más standby y aplica esos registros para mantenerlas consistentes. La novedad de NetApp no sustituye ese transporte ni cambia las reglas de role transition. La ruta de recuperación sigue teniendo dos partes: Data Guard atiende la continuidad entre roles; la plataforma de backup debe conservar copias y permitir la restauración que la política haya definido.
-InfraCrew dice: El “grupo” simplifica la administración si refleja la topología real; si mete primaria y standby sin contexto, solo automatiza el desorden.-
NetApp no detalla en la nota de lanzamiento qué ocurre con una tarea si cambia el rol de una base, cómo se selecciona el miembro de un grupo para cada operación ni qué límites de versión de Oracle aplican a esta incorporación concreta. Tampoco afirma que el grupo sustituya la configuración, monitorización o pruebas de Data Guard. Esos puntos deben validarse en la documentación operativa del servicio antes de cambiar una política de producción, especialmente si las bases están separadas geográficamente o mantienen ventanas diferentes.
Cómo incorporar la novedad sin confundir los roles
Empieza por confirmar qué bases pertenecen a cada configuración Data Guard, cuál es la primaria actual y qué standby están sincronizadas y soportadas. Después, revisa si la versión y el modo de despliegue de Backup and Recovery admiten la protección de esos workloads y añade primaria y standby al grupo que corresponda. La pertenencia debe seguir la topología lógica, no el nombre del host ni el rol que tenía cuando se creó el inventario.
Prueba una ejecución con una política conocida y registra qué base se protegió, en qué destino y con qué resultado de consistencia. Comprueba también la restauración en un entorno adecuado: una tarea completada demuestra que se generó una copia, no que la organización pueda recuperarse dentro de su objetivo. Si hay un switchover, confirma cómo aparecen los nuevos roles en la consola antes de asumir que el grupo y sus calendarios se adaptaron solos.
-InfraCrew dice: Una pantalla verde certifica la tarea que ejecutó; la recuperación sigue esperando su propio ensayo.-
El anuncio del 19 de octubre es pequeño en la interfaz y relevante en el inventario: añade soporte para proteger ambas bases de una pareja Data Guard usando grupos. El cambio está en la cobertura de Backup and Recovery, mientras que Data Guard conserva la responsabilidad sobre redo, roles y transición de disponibilidad. Mantener esa separación clara ayuda a documentar qué falla en una interrupción y qué copia debe servir para recuperar datos.
Diccionario de la Crew
redo — Registro de cambios que Oracle transporta y aplica para mantener bases standby al día.
standby — Base de datos secundaria que Data Guard mantiene como copia de una primaria.
switchover / failover — Cambio de rol planificado / cambio de rol ante la indisponibilidad de la primaria.


