Copia de seguridad de XenServer con Bacula. Cómo hacer una copia de seguridad del hipervisor de Citrix?

Citrix Hypervisor (antes llamado XenServer) es una plataforma de gestión de la virtualización muy completa con una gran variedad de capacidades y tipos de infraestructura compatibles. Citrix Hypervisor es el resultado de un cambio de marca de su producto antes conocido como XenServer.

Información general

Bacula Enterprise proporciona una integración nativa con Citrix Hypervisor a través de un plugin específico (o «Module»; los términos son intercambiables en este contexto). Este nivel de integración permite a los usuarios de Bacula Systems realizar diversas operaciones de copia de seguridad y recuperación de XenServer en diferentes niveles con Citrix Hypervisor, sin importar el tamaño o la complejidad del centro de datos en cuestión. También existe un potencial especialmente grande en cuanto a la flexibilidad y la personalización de la solución, incluyendo ubicaciones de despliegue, tipos de datos, métodos de recuperación, etc.

La copia de seguridad y recuperación de XenServer Citrix Hypervisor de Bacula Enterprise ofrece una variedad de características diferentes, entre ellas

• Respaldos completos, incrementales y diferenciales a nivel de imagen de XenServer;
• Capacidades de copia de seguridad en línea con una tecnología de instantáneas para las VM invitadas;
• Capacidades de restauración de imágenes de VM completas;
• Soporte para los formatos y tipos de copia de seguridad más antiguos;
• La capacidad de realizar instantáneas basadas en VSS de las VM invitadas;
• Una opción para cambiar el directorio de destino para un archivo VM, y mucho más.

Respaldo y recuperación de XenServer sin software de terceros

Antes de repasar las capacidades de Bacula con el XenServer también es importante mencionar que hay una forma de hacer operaciones de copia de seguridad y restauración de Xen con el propio Xen. Sin embargo, existen algunas limitaciones: las copias de seguridad del servidor pueden ocupar mucho espacio de almacenamiento, es posible que tenga que reiniciar con el CD de instalación original para realizar un proceso de restauración completo y no debe crear copias de seguridad del dominio de control de XenServer (dominio 0).

El proceso de copia de seguridad es el siguiente:

1. Seleccione el servidor designado en el panel Resources, haga clic en el menú Server y proceda a la línea Back Up Server….
2. Localice y especifique la carpeta que desea utilizar como ubicación de almacenamiento del archivo de copia de seguridad, introduzca el nombre del archivo y haga clic en Save. El proceso de copia de seguridad comenzará. También puede utilizar la pestaña Logs para ver el proceso de la copia de seguridad.

Y eso es todo, todo el proceso de copia de seguridad son sólo dos pasos. El proceso de restauración también es relativamente sencillo:

1. Primero tendrá que localizar ese mismo menú Server y hacer clic en la línea Restore From Backup….
2. En el siguiente menú localice el archivo de copia de seguridad que desea restaurar.
3. Utilice el CD de instalación de XenServer para reiniciar el servidor y completar todo el proceso de restauración.

Instalación del cliente Bacula en cada VM invitada

Cuando se trata de operaciones reales de copia de seguridad y restauración de VM de XenServer con Bacula, hay varios enfoques diferentes, y es algo más sofisticado que el método original. En primer lugar, vamos a trabajar la forma en que Bacula y Citrix pueden operar con las VMs invitadas y qué estrategias de copia de seguridad de XenServer funcionan para ellas.

Esta estrategia en particular funciona instalando un Daemon de Archivo Empresarial de Bacula en cada VM invitada, tratada como si fueran clientes físicos normales. Tendrá que aprovechar manualmente las capacidades de programación, priorización y realización de trabajos en paralelo de Bacula para optimizar el uso de I/O del Citrix Hypervisor y evitar diversos contratiempos y cuellos de botella.

Realizar una instalación de un Daemon de Archivos de Bacula Enterprise en una VM concreta le permite gestionarla como si fuera un servidor físico, permitiendo una serie de características útiles de Bacula Enterprise, entre las que se incluyen:

• Compresión a nivel de archivo;
• Verificación de trabajos;
• Precisión de las copias de seguridad;
• Restauración de archivos individuales;
• Exclusión de archivos o directorios específicos;
• Verificación de la suma de comprobación para buscar spyware o virus.

Utilización del módulo Citrix Hypervisor para crear copias de seguridad a nivel de imagen

La estrategia a nivel de imagen permite que el módulo Citrix Hypervisor de Bacula utilice el nivel de disco en bruto para crear copias de seguridad. Tampoco es necesario instalar un Daemon de Bacula en cada VM para que esta técnica funcione. El módulo Xen aprovecha la API de XenServer para localizar y guardar el contenido de cada una de sus máquinas virtuales utilizando la tecnología de instantáneas y los métodos vm-export/vm-import.

Este método suele ahorrar importantes recursos, ya que no es necesario que Bacula «recorra» todos y cada uno de los sistemas de archivos de las VM, lo que permite aliviar la carga de trabajo de una infraestructura de hipervisor Citrix en general. Por otro lado, dado que este tipo de copia de seguridad de VM de XenServer guarda literalmente todo lo que hay en una VM concreta, esto también incluye archivos inútiles que no se necesitan realmente en la copia de seguridad, como los archivos temporales o los archivos de intercambio. Sin embargo, también es una ventaja, ya que los archivos de configuración de la VM también se guardan mediante este método, lo que permite una restauración de la VM mucho más fácil.

Proceso de copia de seguridad

Hay cuatro pasos principales en el proceso básico de creación de una copia de seguridad de una sola máquina virtual utilizando el módulo de copia de seguridad de XenServer VM:

• Eliminación de versiones antiguas;
• Creación de una nueva instantánea de la VM y la etapa de preparación de la copia de seguridad;
• Ejecución del comando de exportación de la VM y guardado de los datos en un almacenamiento de Bacula;
• Eliminación de la instantánea tan pronto como se haya realizado la copia de seguridad.

Tanto los estados de la VM huésped en ejecución como los detenidos son adecuados para realizar un proceso de copia de seguridad. Las únicas instantáneas que serían consideradas antiguas por el sistema son las que se ajustan a la plantilla específica – BaculaSnapshot_<UUID>_JobID_<NR>. Éstas se eliminan automáticamente en las primeras etapas del proceso de copia de seguridad de Xen, por lo que se recomienda evitar la creación de instantáneas manuales que se ajusten a esta plantilla de nomenclatura. La consola de estado del módulo Citrix Hypervisor le ofrecerá la información sobre las máquinas virtuales invitadas de las que se está haciendo una copia de seguridad, las etapas de cada copia de seguridad de XenServer, las actividades de las instantáneas, qué copias de seguridad se han eliminado, etc. Puede ver un ejemplo de esta información a continuación:

Cada VM invitada que participa en el proceso supone un archivo de copia de seguridad de XenServer más, cuyo nombre es el siguiente:

También hay una serie de parámetros que se utilizan para definir partes y variaciones específicas del proceso de copia de seguridad de Xen.

• vm=<name-label> representa el nombre de una VM invitada de la que se hará una copia de seguridad. Se realizará una copia de seguridad de todas las coincidencias con el nombre entre paréntesis. El parámetro en sí es opcional y no es necesario para que todo el proceso funcione.
• uuid=<uuid> especifica un UUID de la VM huésped específica. UUID es el identificador universalmente único – un número de 128 bits que identifica la información en varios sistemas. El parámetro en sí es opcional y no es necesario para que todo el proceso funcione.
• include=<name-label-regex> es una lista de nombres de máquinas virtuales invitadas para hacer una copia de seguridad, expresada mediante una sintaxis regular. Se realizará una copia de seguridad de todas las VM invitadas con nombres coincidentes. El parámetro en sí es opcional y no es necesario para que todo el proceso funcione.
• exclude=<name-label-regex> es una lista de nombres de máquinas virtuales invitadas a excluir del proceso de copia de seguridad, expresada mediante sintaxis regular. Todas las coincidencias se excluirán por completo del proceso de copia de seguridad. No afecta a los parámetros vm= o uuid=. El parámetro en sí es opcional y no es necesario para que el proceso completo funcione.
• quiesce=<0|1> se trata de máquinas virtuales invitadas específicas que desea que se creen utilizando el método de quiescencia. Este método sólo es soportado por el sistema operativo Windows con las herramientas para huéspedes instaladas. Todo el trabajo de copia de seguridad se aborta si la instantánea de la VM huésped no puede crearse mediante el método quiesce.

Cabe destacar que, dado que todos los parámetros de especificación en sí mismos son opcionales, el sistema procederá a realizar la copia de seguridad de todas las máquinas virtuales invitadas disponibles si no se encuentra ninguna entrada vm=, uuid=, exclude o include de antemano. También hay un parámetro específico llamado abort_on_error, que ordena que se detenga todo el trabajo si se encuentra un error en el proceso de configuración, como la falta de parámetros vm=, o cualquier otro parámetro en primer lugar.

Proceso de restauración

El proceso de restauración como operación independiente persigue dos objetivos principales:

• Restauración a un directorio local desde un archivo XVA;
• Restauración a un hipervisor XenServer como VM huésped nueva u original.

Hay varios métodos que se pueden utilizar para el proceso de restauración. Por ejemplo, este es un método de one restore to the XenServer. Requiere la configuración de un parámetro de restauración «where=/» en Bacula. En ese caso, el archivo de la VM invitada en cuestión se restauraría como una nueva VM invitada a través de Citrix Hypervisor, o se restauraría como la forma original de esta VM si se establece previamente la opción de preservación. Si no se establece una ruta correcta para el proceso de restauración, la VM invitada se creará en el directorio por defecto de Citrix Hypervisor.

También existe el método restore to local directory, que utiliza el parámetro de restauración «where=/some/path». Esta ruta debe representar una ubicación específica en el servidor donde está instalado el módulo, e incluso si no existe – sería creada por el propio plugin.

El proceso básico de restauración es relativamente fácil por sí mismo, requiere que se ejecute un comando específico, con el parámetro «where» añadido de una forma u otra:

En cuanto a los parámetros de restauración que se utilizan para incluir o excluir máquinas virtuales específicas, son similares a los utilizados en el proceso de copia de seguridad. También hay algunos añadidos:

• server: <address> se utiliza para especificar la dirección de la API de XenServer para realizar la operación, y en el caso de que este parámetro sea incorrecto o esté ausente – se utilizará en su lugar el predeterminado;
• port: <number> es especificar el puerto de la API de XenServer que se va a utilizar, debe estar en el rango entre 1 y 65536; el parámetro inválido hace que se aborte el trabajo y la omisión de este parámetro hace que el proceso utilice el puerto por defecto.