Backup de VM frente a backup de base de datos en NetBackup

El backup de VM y el de bases de datos en NetBackup resuelven problemas de recuperación diferentes, por lo que la elección debe partir de aquello que necesitas restaurar. Una imagen de VM resulta útil cuando el servidor completo debe volver a levantarse. La protección de base de datos con reconocimiento de aplicaciones entra en juego cuando la base de datos debe recuperarse de forma consistente, granular o hasta un punto de transacción concreto.

La consulta reciente de un administrador planteaba el asunto como una disyuntiva excluyente: hacer backup de una VM que contiene una base de datos o respaldar únicamente la base de datos, y en qué casos hace falta instalar un cliente de NetBackup dentro de la VM. Un segundo caso aportó una perspectiva práctica idéntica. Se realizaban copias completas de máquinas virtuales con SUSE Linux, pero al equipo se le pidió proteger los servicios asociados a GitHub y Nexus por separado para garantizar la consistencia.

En ambos escenarios, la estrategia acertada consiste en diseñar capas de recuperación en vez de elegir un único objeto de backup esperando que cubra cualquier eventualidad.

¿Qué protege bien un backup de VM?

Un backup de VM protege la máquina virtual como objeto de infraestructura. Eso incluye por lo general sus discos virtuales y el estado que NetBackup puede capturar a través del flujo de backup de VMware, lo que ofrece a los operadores un método práctico para recuperar una máquina rota o borrada sin reconstruir el sistema operativo desde cero.

Eso ayuda enormemente ante fallos del hipervisor, borrado accidental de VMs, corrupción del sistema operativo o durante una recuperación amplia de infraestructura. La máquina reaparece con su software instalado, su configuración y la disposición de sus discos en el punto de recuperación seleccionado.

Por descontado, el disco de la VM alberga los archivos de la base de datos. Lo que necesitas saber es si esos archivos reflejan un estado que la aplicación pueda recuperar limpiamente bajo el RPO y el RTO exigidos.

Una imagen con consistencia de caída (crash-consistent) se asemeja a lo que la máquina encontraría tras un corte brusco de corriente. Ciertas bases de datos pueden recuperarse de esa situación mediante sus propios diarios o transaction logs. Otras tal vez requieran una congelación coordinada con la aplicación (quiescing), gestión de logs o una secuencia nativa de backup para cumplir el objetivo de recuperación que el negocio espera.

Por eso, un trabajo de VM en verde no se traduce de forma automática en que la base de datos esté debidamente protegida.

¿Cuándo resulta necesaria la protección con reconocimiento de aplicaciones?

Necesitas protección con reconocimiento de la aplicación cuando el requisito de recuperación se expresa en términos de base de datos. Entre los ejemplos habituales figuran restaurar una base de datos sin levantar la VM completa, recuperar hasta un momento específico en el tiempo, gestionar los transaction logs adecuadamente, restaurar hacia otro host de base de datos o demostrar que el backup se tomó a partir de un estado consistente de la aplicación.

NetBackup puede combinar varios de estos objetivos con la protección de imágenes de VMware en aplicaciones compatibles. Veritas documenta la protección de SQL Server en la que una directiva de VMware junto con el proveedor VSS de Veritas pueden crear un backup completo consistente de la base de datos dentro de una VM. Ese mismo backup de VMware admite la recuperación de volúmenes, archivos y bases de datos, y en configuraciones homologadas puede controlar el truncado de logs.

Eso corrige el falso debate entre backup de VM o de base de datos. En determinadas cargas de trabajo, NetBackup permite dotar al backup de la VM de reconocimiento de la aplicación. En otras, una directiva específica de aplicación o un plugin dedicado encajan mejor.

No conviene extrapolar el flujo de SQL Server a cualquier base de datos. MongoDB, Oracle, PostgreSQL, SQL Server y las diversas plataformas de aplicaciones tienen requisitos distintos de integración y restauración, de modo que conviene consultar la guía de NetBackup específica para la carga de trabajo y la versión instalada.

¿Conviene respaldar tanto la VM como la base de datos?

Para un servidor de bases de datos crítico, proteger ambos niveles de recuperación suele ser el planteamiento más pragmático, aunque eso no siempre obligue a ejecutar dos copias completas totalmente aisladas. La meta consiste en preservar la recuperación de la máquina y la de la aplicación sin generar duplicidades innecesarias.

Si un flujo admitido de VMware con reconocimiento de aplicaciones proporciona la recuperación completa de la máquina y opciones consistentes de restauración de la base de datos, puede cubrir ambas capas de forma eficiente. Si no logra satisfacer el RPO de la base de datos, los requisitos de recuperación de logs o el soporte del proveedor, añade el método de protección propio de la base de datos.

Piensa en los escenarios de desastre. Si la VM entera se borra, ¿a qué velocidad puedes reconstruirla? Si una base de datos se corrompe, ¿puedes restaurar únicamente esa base de datos? Si se introducen datos erróneos a las 14:05, ¿puedes recuperar el estado existente a las 14:04? Si la VM original no arranca, ¿puede restaurarse la base de datos en otra ubicación? Una arquitectura de backup incapaz de responder a esas preguntas sigue girando alrededor de la herramienta en lugar de las necesidades del negocio.

La comparativa de backup en Proxmox de Mr.PlanB aborda otra plataforma de virtualización, pero la misma noción de niveles de recuperación se aplica aquí. La protección a nivel de hipervisor resulta sobresaliente para restablecer máquinas, pero las aplicaciones pueden requerir sus propias reglas de consistencia y restauración.

¿Cuándo hace falta instalar el cliente de NetBackup en la VM?

La necesidad del cliente depende del método de protección de NetBackup y de la carga de trabajo. El backup a nivel de imagen de VMware puede proteger las máquinas virtuales a través de la infraestructura de virtualización sin tratar a cada sistema invitado como un cliente tradicional de sistema de archivos, mientras que los plugins de aplicaciones y los flujos de base de datos pueden requerir software, credenciales o un host de backup específico dentro o cerca del entorno de la aplicación.

Por consiguiente, afirmar que hay que instalar el cliente en cada VM con base de datos resulta excesivo, del mismo modo que asumir que el backup de VMware nunca requiere componentes en el invitado se vuelve erróneo en cuanto la consistencia de aplicaciones entra en juego.

En SQL Server, Veritas documenta el comportamiento con reconocimiento de aplicaciones en VMware mediante la integración con VSS. En MongoDB, NetBackup recurre a su plugin para MongoDB y a una arquitectura de host de backup con requisitos propios de credenciales y hosts permitidos. Otras cargas de trabajo tienen directrices distintas.

Mapea los componentes según el tipo exacto de directiva. ¿Qué máquina se comunica con vCenter? ¿Qué host ejecuta el plugin de la aplicación? ¿Qué sistema requiere el software cliente de NetBackup? ¿Qué identidad accede a la base de datos? ¿Qué componente trunca o conserva los logs? ¿Qué host lleva a cabo la restauración? Ese esquema responde a la cuestión de la instalación con mucha mayor solidez que el mero hecho de que la aplicación resida dentro de una máquina virtual.

¿Qué significa "backup consistente" en aplicaciones Linux como Nexus?

La consistencia debe definirse en función de la propia aplicación, porque una snapshot completa de una VM con SUSE Linux no garantiza que cada componente del aplicativo sea recuperable de forma conjunta. Un servicio como Nexus puede depender de archivos de la aplicación, metadatos, configuraciones y una base de datos o almacén de datos integrado cuyas reglas de consistencia cobran vital importancia durante el backup.

El caso analizado de SUSE ya contaba con copias de la VM completa. El nuevo requisito pedía respaldar los servicios vinculados a GitHub y Nexus por separado para asegurar la consistencia. Antes de crear otra directiva, averigua qué solicita cada proveedor para ofrecer un backup con soporte oficial. Eso puede implicar pausar escrituras, recurrir a una exportación propia del aplicativo, coordinar una snapshot de la base de datos, proteger el almacenamiento de blobs o capturar credenciales y configuraciones junto con los datos.

El debate de referencia no aportó información suficiente para recetar una directiva única de NetBackup para GitHub o Nexus. La decisión sensata radica en seguir el procedimiento de backup avalado por la aplicación y adaptar NetBackup alrededor de esa exigencia. Una prueba completa de restauración debe reconstruir el servicio en lugar de conformarse con recuperar sus archivos.

¿Cómo deben decidir el RPO y el RTO el diseño de backup?

El RPO determina cuánta pérdida de datos resulta tolerable, mientras que el RTO establece cuánto tiempo puede demorarse la recuperación. Estas dos cifras evidencian a menudo por qué una sola capa de protección suele quedarse corta.

Un backup nocturno de la VM puede ser admisible para un servidor de utilidades, pero resultará inaceptable para una base de datos transaccional concurrida que solo puede permitirse perder minutos de actividad. El backup de los logs de la base de datos aporta un RPO mucho más ajustado, pero reconstruir la pila entera del sistema operativo y de la aplicación exclusivamente a partir de archivos de base de datos puede tardar demasiado tras la destrucción de una VM.

Combina las capas de acuerdo con esos objetivos. Una imagen periódica de VM brinda una recuperación rápida de la máquina, una protección más frecuente de la base de datos o de sus transaction logs facilita un punto de recuperación de datos más estricto, y el runbook de restauración aclara cuándo utilizar cada recurso.

La guía de Proxmox Backup Server resulta provechosa para reflexionar sobre la retención y restauración a nivel de imagen en otro ecosistema. La lección se mantiene en cualquier plataforma: frecuencia, retención y granularidad de recuperación deben adaptarse a la carga de trabajo, al margen de los calendarios predeterminados que proponga el software de backup.

¿Cómo debe ponerse a prueba el diseño?

Verifica al menos tres tipos de recuperación: restauración completa de la VM, restauración exclusiva de la base de datos y recuperación tras un fallo de consistencia de la aplicación. La primera demuestra la recuperación de la infraestructura, la segunda confirma la recuperación granular de la aplicación y la tercera acredita que el equipo identifica cuándo un backup técnicamente completado no ofrece garantías para el uso previsto en la base de datos.

En bases de datos sensibles a las transacciones, incluye la recuperación a un momento específico si el diseño la promete. Mide el tiempo efectivo de restauración. Comprueba el arranque del servicio, las revisiones de integridad, el acceso de usuarios y las integraciones subordinadas tras la recuperación.

Valida asimismo el destino de la restauración. Un backup de base de datos capaz de restaurarse únicamente en la VM original puede perder utilidad durante una incidencia mayor en comparación con uno que pueda volcarse en un host alternativo. Un backup de VM que se restaura con rapidez pero depende de un almacenamiento compartido inaccesible fallará ante un escenario real de desastre.

Deja documentado qué backup tiene prioridad según el tipo de avería, para que el equipo no deba debatir si restaura la VM o la base de datos por primera vez en mitad de una caída del servicio.

¿Qué elegiría yo para una VM con base de datos?

Protegería la VM para la recuperación a nivel de máquina y me aseguraría de que la base de datos disponga de una vía de recuperación con reconocimiento de aplicaciones que cumpla su RPO. Si la integración admitida de VMware en NetBackup cubre ambas necesidades para esa versión concreta de base de datos, utilizaría esa integración en vez de duplicar datos sin motivo.

Si la carga de trabajo requiere recuperación de transaction logs, restauración exclusiva de la base de datos, consistencia propia del aplicativo o un calendario más exigente que el proporcionado por la directiva de la VM, añadiría la directiva especializada o el plugin de base de datos. Instalaría componentes en el sistema invitado solo donde el flujo documentado lo exija.

Dejaría de plantear la cuestión como "VM o base de datos" para preguntar qué operaciones de recuperación deben funcionar y qué métodos de protección de NetBackup certifican esas operaciones. Cuando eso queda plasmado por escrito, la ubicación de clientes, los calendarios y los tipos de directiva resultan mucho más sencillos de justificar.