Qué garantizan de verdad los modos vzdump de Proxmox

Proxmox ofrece tres modos de copia de seguridad en un mismo desplegable, lo que los hace parecer tres velocidades de la misma cosa. No lo son. Difieren en lo que le ocurre al huésped en marcha y, por tanto, en aquello de lo que el archivo es realmente una copia.

La versión corta, y después la larga:

La palabra que sostiene toda esa tabla es crash-consistent. Significa que el archivo es lo que habría sido el disco si alguien hubiera tirado del cable de la corriente en ese instante. Un sistema de archivos con registro por diario se recupera de eso. Una base de datos con una transacción en vuelo puede que no, y una aplicación que reparte su estado entre dos ficheros no sabrá que uno de ellos es más antiguo que el otro.

snapshot no significa que el huésped quede en reposo

snapshot es el modo por defecto y el único que no interrumpe nada. Proxmox toma una instantánea a nivel de almacenamiento y lee de ahí la copia, así que el huésped sigue escribiendo en el volumen vivo todo el tiempo.

Hay una manera de mejorar ese archivo: el agente huésped de QEMU puede congelar el sistema de archivos dentro del huésped durante el instante en que se toma la instantánea, lo que vacía las escrituras pendientes y deja un archivo que el propio huésped considera limpio. Si el agente huésped está instalado, en marcha y responde, eso es lo que ocurre.

La trampa está en ese «si». Nada en el resultado de la API dice si la congelación llegó a producirse. La tarea vzdump devuelve un identificador de tarea y, al terminar, un estado. Que qemu-guest-agent respondiera a la petición de congelación es una línea del registro de la tarea, no un campo que se pueda volver a leer.

Este es un punto de decisión para cualquiera que automatice por encima, y merece la pena tomarlo con deliberación. Cuando construimos el camino de copia de seguridad de nuestra integración con Proxmox acabamos registrando la consistencia como lo que ocurrió, nunca como lo que se pidió: una copia en modo stop se registra como consistente, y tanto snapshot como suspend se registran como crash-consistent, sin más. En nuestro esquema existe un valor para «el huésped quedó en reposo» y el agente no lo emite nunca, porque emitirlo significaría afirmar que conocemos una congelación que la API no permite verificar.

Un archivo descrito como algo peor de lo que es no cuesta nada. Un archivo descrito como mejor de lo que es cuesta la única restauración que importa.

suspend pausa el huésped, y no es un término medio

suspend se lee mejor de lo que se comporta. Se da por hecho que es «snapshot, pero más seguro», un compromiso entre ninguna parada y una parada completa. Lo que hace en realidad es pausar el huésped mientras se leen los datos.

Ofrece la misma garantía crash-consistent que snapshot, porque pausar una máquina no es lo mismo que dejar que vacíe sus escrituras y se asiente. Se obtiene una interrupción y ninguna promesa más fuerte. Su caso es estrecho: un almacenamiento que no sabe hacer instantáneas en absoluto, donde el modo snapshot no tiene nada de lo que partir.

stop es la única garantía honesta

stop apaga el huésped, lo copia y lo vuelve a arrancar. Es la interrupción más larga y el único modo en el que el archivo es, sin ambigüedad, la copia de un sistema de archivos en el que nadie estaba escribiendo.

Para un servidor de base de datos que alguien restaurará bajo presión a las tres de la madrugada, ese no es un precio alto. Para una flota de servidores web es un precio que nadie pagará cada noche. Las dos son respuestas correctas a preguntas distintas, y por eso el modo pertenece a la política y no a un único ajuste global.

Aquí importa un detalle de implementación. Como stop y suspend interrumpen los dos una máquina en marcha, un valor de modo ausente o no reconocido nunca debe caer en uno de ellos. En nuestro esquema de comandos el modo viaja como la palabra literal de Proxmox (snapshot, suspend, stop) y no como un vocabulario propio, y un valor sin definir se resuelve a snapshot. Una tabla de traducción entre nuestras palabras y las suyas pondría una mala traducción exactamente donde una mala traducción apaga la máquina de un cliente.

Los parámetros que deciden si el trabajo llega a ejecutarse

Antes de la consistencia hay una pregunta más aburrida: ¿llegará vzdump a arrancar siquiera? Cuatro cosas de la petición lo deciden, y tres de ellas fallan de maneras difíciles de leer.

El almacenamiento de destino tiene que aceptar copias de seguridad. El almacenamiento de Proxmox tiene una lista content, y solo un almacenamiento cuya lista incluya backup puede recibir un vzdump. Esto no es un consejo. Si el trabajo se manda a un almacenamiento que solo guarda imágenes de disco, Proxmox lo rechaza con un mensaje del tipo storage 'x' does not support vzdump backups. Exacto, y sin sentido alguno para el cliente que pulsó el botón. Conviene comprobarlo antes de enviar, para que el rechazo pueda decir «este almacenamiento no acepta copias de seguridad» en su lugar.

Un caso emparentado: un almacenamiento que aparece en la lista de recursos del clúster con estado unknown está configurado pero no responde. Un recurso NFS caído tiene exactamente el mismo aspecto que un destino válido, justo hasta el momento en que el trabajo falla.

La compresión tiene un valor que no es la palabra que se espera.

Proxmox escribe «sin compresión» como 0, no como none. Enviar none es el tipo de error que produce un rechazo silencioso en lugar de uno claro, y es la razón por la que nuestra batería de pruebas afirma la cadena exacta que sale del agente en vez de limitarse a afirmar que la llamada tuvo éxito.

La notificación por correo viene ruidosa por defecto, y dirigida a la persona equivocada. Sin un mailnotification=failure explícito, Proxmox escribe a root@pam después de cada copia. En una máquina gestionada desde una plataforma, eso es correo al proveedor sobre algo que hizo el cliente.

Merece la pena conocer dos campos opcionales. notes-template adjunta una nota al archivo, y Proxmox expande dentro de ella sus propios marcadores, como {{guestname}}. protected=1 marca un archivo como protegido, y entonces Proxmox se niega a purgarlo. Ese es el mecanismo que se busca para la copia que alguien toma antes de un cambio arriesgado, y exactamente el valor por defecto equivocado para un trabajo nocturno.

La retención no es un parámetro de vzdump

No hay ajuste de retención en la petición de copia. La purga se configura en el almacenamiento, dentro de Proxmox, y es el dueño del almacenamiento quien decide cuánto viven las copias.

Eso tiene una consecuencia de diseño para quien construya encima: un panel que ofrece un campo «conservar 7 copias» o bien entra en la configuración del almacenamiento, o bien borra archivos por su cuenta. No elegimos ninguna de las dos, y lo decimos, en lugar de insinuar lo contrario con un campo que no hace nada.

Que expire la espera no es lo mismo que fallar

Un vzdump de una máquina grande puede sobrevivir a cualquier tiempo de espera razonable. Cuando eso pasa, lo importante que hay que entender es que no se canceló nada: el trabajo sigue corriendo en el hipervisor, y terminará o fallará según su propio calendario.

Así que una espera agotada es una afirmación sobre la conexión, no sobre la copia. La ejecución sigue abierta, el identificador de tarea sigue siendo válido, y lo honesto por parte de una interfaz es decir «sigue en curso» y reconciliar más tarde. La alternativa, marcarla como fallida y dejar que alguien inicie una segunda, pone dos trabajos vzdump sobre el mismo almacenamiento para la misma máquina.

Mientras corre, el progreso real está disponible: vzdump escribe líneas como 12% (1.2 GiB of 10.0 GiB) en el registro de su tarea. Una barra de progreso alimentada por eso es honesta. Una barra de progreso alimentada por una estimación es una conjetura con un signo de porcentaje al lado.

Restaurar es otra pregunta, y unique es lo que hay que acertar

La cuestión del modo termina cuando el archivo existe. La restauración tiene su propia trampa, y es de red.

Restaurar un archivo en una máquina nueva sin pedir identificadores nuevos hace que la máquina nueva herede las direcciones MAC de la original. Si la original sigue en marcha, ahora hay dos máquinas con la misma MAC en el mismo puente, y el síntoma no es «la restauración falló» sino «la red de la máquina de producción se ha puesto rara». La bandera unique en la llamada de restauración es lo que evita eso, y en una plataforma que restaura junto a una original en marcha no es una opción sino una condición previa.

Conviene saber dos cosas más antes de la primera restauración:

• storage significa aquí otra cosa. En la copia es el sitio al que va el archivo, y necesita backup en su lista de contenidos. En la restauración es el sitio donde aterrizan los discos restaurados, y necesita images. Mismo nombre de campo, requisito distinto.
• Solo vuelven los discos. Una máquina restaurada es una máquina con los discos y el hardware del archivo. Las asignaciones de direcciones, las reglas de cortafuegos y cualquier automatización enganchada a la original viven en los sistemas propios, no en el fichero vzdump, y no viajan con él.

Lo que aquí no está medido

Todo lo anterior sobre la forma de las llamadas sale del esquema de la API de Proxmox y de construir contra él; la semántica de los modos es de Proxmox y está descrita en su documentación.

Lo que deliberadamente no afirmamos es cuánto cuesta cada modo en tiempo. No tenemos una duración de pausa medida para suspend ni un tiempo de parada medido para stop: eso depende del huésped, del almacenamiento y de la cantidad de memoria sucia, y una cifra medida en una máquina se acabaría citando como general. Esas tienen que salir del hardware propio.

Dos huecos más que conviene nombrar. Todo esto trata de huéspedes QEMU; las copias de contenedores tienen sus propias reglas alrededor de los puntos de montaje y los montajes de enlace, y no las hemos medido. Y en nada de esto hay un camino incremental: un vzdump a un almacenamiento normal escribe un archivo completo cada vez. La copia incremental es aquello para lo que existe Proxmox Backup Server, y ese es otro programa con otro conjunto de promesas.

Esto salió de construir el camino de copia de seguridad de Proxmox para Provibr, un panel de gestión de servidores para proveedores de alojamiento, donde una copia descrita como mejor de lo que es sería el peor error posible. Las notas de configuración del lado del hipervisor están en la documentación de Proxmox, y la página de la integración con Proxmox cubre lo que el agente puede hacer.