Tu copia de Proxmox se salta discos y el trabajo sale en verde

Hay una palabra en el manual de tu copia de seguridad que decide si tienes la copia que crees tener, y no es «error». Es skipped: saltado. El disco no se copia, nadie te avisa y el trabajo termina correctamente.

La página de consideraciones y limitaciones del complemento de Veeam para Proxmox VE se actualizó el 15 de septiembre de 2026 y corresponde a la compilación 13.1.1.18. La leímos entera y contamos: la frase «does not support» aparece 18 veces, «cannot» otras diez, «not supported» cuatro más. El método es simple y lo decimos para que se pueda repetir: contar sobre el texto de esa página, sin la navegación ni el pie. Y con el matiz que nos toca poner a nosotros, porque el número solo engaña: de esos diez «cannot», tres son condicionales del tipo «si no puedes usar el almacenamiento por defecto» y uno va dentro de una frase que ya contaba como «does not support». Seis limitaciones nuevas, entonces, no diez.

Un número así tampoco dice gran cosa por sí solo. Todos los productos de copia tienen una lista parecida, y la de un hipervisor nuevo siempre es más larga que la del hipervisor que lleva veinte años en el mercado. Lo que sí dice algo es qué hay en la lista, y en esa página hay tres categorías bien distintas: lo que no se copia, lo que no vuelve al restaurar, y lo que ni siquiera entra en la tabla de plataformas soportadas.

Dos clases de «no soportado»

La primera clase te para. Si una máquina guarda sus discos en almacenamiento BTRFS o en un almacenamiento de tipo personalizado, no se copia; el manual lo dice y añade que el resto de tipos de almacenamiento de Proxmox VE sí están soportados. Las plantillas de máquina tampoco se copian. Los contenedores LXC tampoco. Eso se ve: falta la máquina en el trabajo, alguien pregunta, y se arregla o se decide no arreglarlo.

La segunda clase no te para. Dos líneas del manual, casi seguidas, usan la misma construcción. Sobre los discos iSCSI conectados a una máquina: «such disks are skipped from backup processing». Sobre los discos conectados directamente en modo passthrough: «these disks will be skipped from processing». La máquina entra en el trabajo. El trabajo acaba bien. Uno de sus discos no está dentro.

Nuestra opinión, y la marcamos como opinión: la segunda clase es la peligrosa, precisamente porque no genera trabajo. Un fallo produce un correo, una incidencia y alguien mirándolo. Un trabajo en verde no produce nada. Y fíjate en qué máquinas suelen llevar un disco passthrough o una LUN iSCSI conectada directamente: el servidor de base de datos al que alguien le pasó el NVMe entero para que rindiera, el servidor de ficheros con el volumen de la cabina colgado directamente. Son, casi por definición, máquinas que alguien montó de forma especial porque importaban.

Los contenedores LXC se quedan fuera

La línea es de una sola frase: el complemento no soporta la copia de contenedores LXC. En un párrafo de manual parece un detalle. En una plataforma Proxmox pesa, porque media plataforma se apoya en LXC: por eso el menú de crear tiene dos botones y no uno.

Quien llega desde vSphere no se encuentra con esto el primer día, porque allí todo era una máquina virtual. Se lo encuentra al tercer mes, cuando alguien descubre que el DNS interno, el proxy, el recolector de la monitorización y la wiki del equipo caben en un contenedor por una fracción de la memoria. La migración fue bien, la plataforma es más barata de operar, y sin que nadie lo decidiera en una reunión ha aparecido una segunda categoría de carga de trabajo que el trabajo de copia nocturno no mira.

Salidas hay tres, y conviene conocer el precio de cada una. La primera ya la tienes puesta: Proxmox VE copia contenedores de fábrica con vzdump, sin licencia y sin agente. Lo decimos aunque no le convenga a nuestro argumento, porque es la verdad: el hueco es del complemento y no de la plataforma. El precio es que esa copia vive fuera de tu consola central, con otra retención y otro cuadro de mandos. La segunda es meter un agente dentro del contenedor y tratarlo como una máquina Linux más; funciona, pero lo que obtienes ahí es una copia a nivel de fichero, y ahí está la letra pequeña: el manual excluye la recuperación instantánea desde las copias a nivel de fichero de los agentes (Linux, Windows, Unix, Mac) y de Kasten. Desde copias de agente de nivel de volumen sí se puede; desde las de fichero, no, y conviene saber de cuál de las dos estás hablando antes de firmar un tiempo de recuperación. La tercera es Proxmox Backup Server, que según su propia documentación copia máquinas virtuales, contenedores y equipos físicos. Nosotros gestionamos copias con varias de estas herramientas a la vez, y la pregunta que hay que contestar por escrito es cuál cubre cada cosa.

Lo que no vuelve cuando vuelve la máquina

La parte de restauración tiene su propia lista, y ahí hay una línea que se lee rápido y cuesta cara: no se restauran los ajustes de alta disponibilidad de la máquina. Traducido a lo que pasa: restauras el servidor, arranca, da servicio, todo el mundo respira. Y esa máquina ha dejado de estar en el grupo de alta disponibilidad sin que nadie lo note, porque nada en la pantalla lo dice. El día que se muere el nodo donde vive, no se levanta en otro. Es el mismo patrón que contamos en RTO y RPO sin humo: el número que prometes lo marca lo que queda por reconstruir a mano después de restaurar.

Dos más de la misma lista, por orden de sorpresa. No se puede restaurar una máquina a Proxmox VE directamente desde cinta: hay que devolver la copia a un repositorio soportado y restaurar desde ahí. Y la que más nos llamó la atención, porque es específica de Proxmox VE 9: desde esa versión hay tipos de almacenamiento que admiten instantáneas como cadena de volúmenes, y como esa funcionalidad requiere QEMU 10 o posterior, las máquinas con una versión anterior de QEMU no se pueden restaurar a un almacenamiento que tenga activada esa opción. El fabricante publica un artículo de base de conocimiento con la vía para sortearlo, así que no es un muro; es un procedimiento extra que alguien tiene que conocer el día del incidente. Y el origen de todo es una casilla del almacenamiento, marcada este año por buenos motivos.

Y una que hay que decir en su sitio para no exagerar: la recuperación instantánea hacia Proxmox VE está publicada con estado de soporte experimental. Lo dice el fabricante en su propia página, con nota al pie y enlace a su definición. Funciona y te atienden el ticket. Lo que no aguanta un estado experimental es una cláusula de tiempo de recuperación firmada con un cliente, y esa distinción la tiene que hacer quien vende el servicio.

Una arquitectura entera que se queda fuera

La tabla de plataformas soportadas dice Proxmox Virtual Environment 8.2 a 9.2, instalado con la imagen ISO oficial, sobre máquina x86-64. Y añade una frase: las máquinas con arquitectura de CPU ARM no están soportadas. Aparte de eso, y ya para copias hechas con otros complementos, la recuperación instantánea tampoco funciona desde copias de máquinas ARM.

Esto no sería noticia si Proxmox no hubiera anunciado el 5 de agosto de 2026 el soporte oficial para Arm64. Cuando salió escribimos que ARM no amplía tu clúster, te obliga a llevar dos. Hoy hay que añadir un renglón a aquella cuenta, y lo marcamos como razonamiento nuestro y no como dato de nadie: si tu herramienta de copia no soporta el nodo, ese segundo clúster necesita una respuesta de backup propia. Cuál sea es una pregunta abierta —el anuncio del 5 de agosto habla de Proxmox VE, no de Proxmox Backup Server—, y se contesta antes de comprar el hierro.

La lista es la especificación de tu plataforma

Aquí está lo que de verdad queríamos contar. Repasa las líneas de arriba y mira cuándo se decide cada una: qué tipo de almacenamiento montas, si esa carga va en contenedor o en máquina virtual, si le pasas el disco directamente o lo sirves por el hipervisor, si compras nodos ARM, si activas la casilla de instantáneas como cadena de volúmenes. Todas son decisiones de la primera semana. Todas se descubren el día de la restauración.

De ahí sale la regla que aplicamos y que resume el post: en una migración a Proxmox, el manual de limitaciones del backup se lee antes de elegir el almacenamiento, no después. Es el mismo razonamiento que usamos cuando alguien quiere reutilizar su cabina y descubre que la instantánea no viaja con el hipervisor: la pieza que decides no tocar también decide cosas por ti.

Las líneas aburridas, que también muerden

Los nodos de un clúster se añaden a la infraestructura de copia uno por uno: no se puede añadir el clúster entero como una sola entidad. Es decir que el nodo que compraste en marzo y añadiste al clúster una tarde no está en la copia hasta que alguien lo añada también ahí, y esa ausencia no genera ningún error, porque lo que no está no falla. Después hay más: los cambios pueden tardar hasta quince minutos en verse reflejados, no se soporta IPv6, el número de operaciones simultáneas por almacenamiento está limitado a cuatro —se cambia abriendo un ticket al fabricante, no una casilla— y la cuenta con la que el sistema de copia entra al servidor Proxmox no puede tener doble factor. Sobre esta última no vamos a hacer sangre: una cuenta de servicio debe llevar su propia restricción de origen y su propio control. Pero conviene que se decida a propósito y no aparezca la tarde de la puesta en marcha.

Cómo lo comprobamos nosotros

Cuatro cosas, en este orden. Ninguna consiste en mirar el color del trabajo.

• El inventario de discos contra el informe del trabajo. La configuración de cada máquina la da el propio hipervisor con qm config <vmid>; ahí se ven los discos y de qué almacenamiento cuelga cada uno. Lo que aparece ahí y no aparece en lo que el trabajo dice haber procesado es, literalmente, la lista de lo saltado. Es media hora de trabajo y se hace una vez al trimestre.
• Los contenedores, en un inventario aparte. Con su propia herramienta, su propia retención y su propio responsable con nombre y apellidos. Mezclarlos en la misma lista que las máquinas virtuales es la forma más fiable de que un día nadie sepa quién copiaba el contenedor del DNS.
• Restauración cronometrada. Con la máquina original apagada, en otro sitio, con un reloj delante y el número apuntado donde lo vea quien firma el plan. No vale la pantalla de «restore completed»: vale el minuto en que la aplicación vuelve a atender. Si nunca lo has medido, no lo tienes.
• Después de restaurar, la lista de lo que no vuelve. ¿Está la máquina otra vez en el grupo de alta disponibilidad? ¿Está el disco que iba en passthrough? ¿Están las reglas del cortafuegos que colgaban de ese identificador?

Lo que no estamos diciendo

No estamos diciendo que este producto de copia esté mal hecho. La página que hemos estado leyendo lleva fecha de actualización y número de compilación, y eso es justo lo que nos ha permitido hacer lo que hemos hecho: contar. Lo incómodo viene después: esa página cambia. La que hemos leído es del 15 de septiembre y corresponde a la 13.1.1.18; la que aplique a tu proyecto será otra. Un inventario de limitaciones de hace seis meses vale lo que vale un backup de hace seis meses.

Tampoco es un argumento contra migrar, y migrar sigue mereciendo la pena en muchos casos. Ya hemos escrito cuándo NO migrar de VMware a Proxmox, y ahí también hablamos de este producto de copia y de un problema conocido de sus trabajos de replicación; eso ya lo contamos y no lo repetimos aquí. Lo que añade este post es otra cosa: la matriz de soporte de tu copia es parte del diseño de la plataforma y entra en la primera fase del proyecto. Y si el ejercicio te suena, es porque ya recorrimos una lista parecida en otra plataforma cuando miramos los chats de Teams.

En everyWAN gestionamos recuperación ante desastres y copias con Proxmox Backup Server y con Veeam, y llevamos migraciones de VMware a Proxmox. No somos revendedores de ninguno de los dos fabricantes, así que cuando decimos dónde está el borde de cobertura no nos paga nadie por decirlo.

Fuentes (consultadas el 24-sep-2026): todas las limitaciones citadas —contenedores LXC, plantillas, almacenamiento BTRFS y personalizado, discos iSCSI y passthrough «skipped from processing», nodos de clúster añadidos por separado, sincronización de hasta 15 minutos, IPv6, cuentas con doble factor, límite de 4 operaciones concurrentes por almacenamiento, ausencia de restauración de ajustes de alta disponibilidad, restauración desde cinta y la incompatibilidad entre QEMU anterior a la 10 y el almacenamiento con instantáneas como cadena de volúmenes— proceden de la página Considerations and Limitations de la guía de usuario de Veeam Backup & Replication 13, actualizada el 15-09-2026 para la compilación 13.1.1.18. El estado de soporte experimental de la recuperación instantánea hacia Proxmox VE, la exclusión de las copias a nivel de fichero de los agentes y de las máquinas ARM, y la lista de cargas de trabajo que sí admite, están en Instant Recovery of Workloads to Proxmox VE. Las versiones soportadas (8.2–9.2, ISO oficial, x86-64, «Machines with the ARM CPU architecture are not supported») están en Platform Support. Que Proxmox Backup Server copia máquinas virtuales, contenedores y equipos físicos es de su documentación oficial. El anuncio del soporte oficial Arm64 del 05-08-2026 está en las notas de prensa de Proxmox. Lo que este post NO afirma: los recuentos de 18 «does not support», 10 «cannot» y 4 «not supported» son nuestros, hechos sobre el texto de esa única página en la fecha indicada, y cambiarán con cada actualización del manual; no son una medida de la calidad del producto ni una comparación con ningún otro, y por eso matizamos arriba cuántos de esos «cannot» son de verdad limitaciones nuevas. No hemos probado en laboratorio ninguna de estas limitaciones para este post: citamos lo que publica cada fabricante. No afirmamos que ningún otro producto de copia cubra lo que este no cubre, ni al revés. No sabemos, y no lo decimos, qué herramienta de copia soporta hoy nodos Proxmox en ARM. Y la regla de leer el manual del backup antes de elegir el almacenamiento es criterio nuestro, no una recomendación de ningún fabricante.