La teva còpia de Proxmox se salta discos i la tasca surt en verd

Hi ha una paraula al manual de la teva còpia de seguretat que decideix si tens la còpia que et penses tenir, i no és «error». És skipped: saltat. El disc no es copia, ningú no t'avisa i la tasca acaba correctament.

La pàgina de consideracions i limitacions del complement de Veeam per a Proxmox VE es va actualitzar el 15 de setembre de 2026 i correspon a la compilació 13.1.1.18. L'hem llegida sencera i hem comptat: la frase «does not support» hi surt 18 vegades, «cannot» deu més, «not supported» quatre més. El mètode és simple i el diem perquè es pugui repetir: comptar sobre el text d'aquesta pàgina, sense la navegació ni el peu. I amb el matís que ens toca posar a nosaltres, perquè el número tot sol enganya: d'aquests deu «cannot», tres són condicionals del tipus «si no pots fer servir l'emmagatzematge per defecte» i un va dins d'una frase que ja comptava com a «does not support». Sis limitacions noves, doncs, no deu.

Un número així tampoc no diu gran cosa tot sol. Tots els productes de còpia tenen una llista semblant, i la d'un hipervisor nou sempre és més llarga que la del que fa vint anys que és al mercat. El que sí que diu alguna cosa és què hi ha a la llista, i en aquella pàgina hi ha tres categories ben diferents: el que no es copia, el que no torna en restaurar, i el que ni tan sols entra a la taula de plataformes suportades.

Dues classes de «no suportat»

La primera classe t'atura. Si una màquina desa els seus discos en emmagatzematge BTRFS o en un emmagatzematge de tipus personalitzat, no es copia; el manual ho diu i afegeix que la resta de tipus d'emmagatzematge de Proxmox VE sí que estan suportats. Les plantilles de màquina tampoc no es copien. Els contenidors LXC tampoc. Això es veu: falta la màquina a la tasca, algú pregunta, i s'arregla o es decideix no arreglar-ho.

La segona classe no t'atura. Dues línies del manual, gairebé seguides, fan servir la mateixa construcció. Sobre els discos iSCSI connectats a una màquina: «such disks are skipped from backup processing». Sobre els discos connectats directament en mode passthrough: «these disks will be skipped from processing». La màquina entra a la tasca. La tasca acaba bé. Un dels seus discos no hi és.

La nostra opinió, i la marquem com a opinió: la segona classe és la perillosa, precisament perquè no genera feina. Una errada produeix un correu, una incidència i algú mirant-s'ho. Una tasca en verd no produeix res. I fixa't en quines màquines solen portar un disc passthrough o una LUN iSCSI connectada directament: el servidor de base de dades al qual algú va passar l'NVMe sencer perquè rendís, el servidor de fitxers amb el volum de la cabina penjat directament. Són, gairebé per definició, màquines que algú va muntar d'una manera especial perquè importaven.

Els contenidors LXC queden fora

La línia és d'una sola frase: el complement no suporta la còpia de contenidors LXC. En un paràgraf de manual sembla un detall. En una plataforma Proxmox pesa, perquè mitja plataforma es recolza en LXC: per això el menú de crear té dos botons i no un.

Qui arriba des de vSphere no es troba això el primer dia, perquè allà tot era una màquina virtual. S'ho troba al tercer mes, quan algú descobreix que el DNS intern, el proxy, el recol·lector de la monitorització i la wiki de l'equip caben en un contenidor per una fracció de la memòria. La migració va anar bé, la plataforma és més barata d'operar, i sense que ningú ho decidís en una reunió ha aparegut una segona categoria de càrrega de treball que la tasca de còpia nocturna no mira.

Sortides n'hi ha tres, i convé conèixer el preu de cadascuna. La primera ja la tens posada: Proxmox VE copia contenidors de sèrie amb vzdump, sense llicència i sense agent. Ho diem encara que no convingui al nostre argument, perquè és la veritat: el forat és del complement i no de la plataforma. El preu és que aquesta còpia viu fora de la teva consola central, amb una altra retenció i un altre quadre de comandament. La segona és ficar un agent dins del contenidor i tractar-lo com una màquina Linux més; funciona, però el que obtens allà és una còpia a nivell de fitxer, i aquí hi ha la lletra petita: el manual exclou la recuperació instantània des de les còpies a nivell de fitxer dels agents (Linux, Windows, Unix, Mac) i de Kasten. Des de còpies d'agent de nivell de volum sí que es pot; des de les de fitxer, no, i convé saber de quina de les dues parles abans de signar un temps de recuperació. La tercera és Proxmox Backup Server, que segons la seva documentació copia màquines virtuals, contenidors i equips físics. Nosaltres gestionem còpies amb diverses d'aquestes eines alhora, i la pregunta que cal contestar per escrit és quina cobreix cada cosa.

El que no torna quan torna la màquina

La part de restauració té la seva pròpia llista, i hi ha una línia que es llegeix ràpid i costa cara: no es restauren els ajustos d'alta disponibilitat de la màquina. Traduït al que passa: restaures el servidor, arrenca, dona servei, tothom respira. I aquella màquina ha deixat d'estar al grup d'alta disponibilitat sense que ningú ho noti, perquè res a la pantalla no ho diu. El dia que es mor el node on viu, no s'aixeca en un altre. És el mateix patró que vam explicar a RTO i RPO sense fum: el número que promets el marca el que queda per reconstruir a mà després de restaurar.

Dues més de la mateixa llista, per ordre de sorpresa. No es pot restaurar una màquina a Proxmox VE directament des de cinta: cal tornar la còpia a un repositori suportat i restaurar des d'allà. I la que més ens va cridar l'atenció, perquè és específica de Proxmox VE 9: des d'aquella versió hi ha tipus d'emmagatzematge que admeten instantànies com a cadena de volums, i com que aquesta funcionalitat requereix QEMU 10 o posterior, les màquines amb una versió anterior de QEMU no es poden restaurar a un emmagatzematge que tingui activada aquesta opció. El fabricant publica un article de base de coneixement amb la via per esquivar-ho, així que no és cap mur; és un procediment extra que algú ha de conèixer el dia de l'incident. I l'origen de tot és una casella de l'emmagatzematge, marcada enguany per bons motius.

I una que cal dir al seu lloc per no exagerar: la recuperació instantània cap a Proxmox VE està publicada amb estat de suport experimental. Ho diu el fabricant a la seva pròpia pàgina, amb nota al peu i enllaç a la seva definició. Funciona i t'atenen el tiquet. El que no aguanta un estat experimental és una clàusula de temps de recuperació signada amb un client, i aquesta distinció l'ha de fer qui ven el servei.

Una arquitectura sencera que queda fora

La taula de plataformes suportades diu Proxmox Virtual Environment 8.2 a 9.2, instal·lat amb la imatge ISO oficial, sobre màquina x86-64. I hi afegeix una frase: les màquines amb arquitectura de CPU ARM no estan suportades. A banda d'això, i ja per a còpies fetes amb altres complements, la recuperació instantània tampoc no funciona des de còpies de màquines ARM.

Això no seria notícia si Proxmox no hagués anunciat el 5 d'agost de 2026 el suport oficial per a Arm64. Quan va sortir vam escriure que ARM no amplia el teu clúster, t'obliga a portar-ne dos. Avui cal afegir una ratlla a aquell càlcul, i la marquem com a raonament nostre i no com a dada de ningú: si la teva eina de còpia no suporta el node, aquell segon clúster necessita una resposta de backup pròpia. Quina sigui és una pregunta oberta —l'anunci del 5 d'agost parla de Proxmox VE, no de Proxmox Backup Server—, i es contesta abans de comprar el ferro.

La llista és l'especificació de la teva plataforma

Aquí hi ha el que de debò volíem explicar. Repassa les línies de dalt i mira quan es decideix cadascuna: quin tipus d'emmagatzematge muntes, si aquella càrrega va en contenidor o en màquina virtual, si li passes el disc directament o el serveixes per l'hipervisor, si compres nodes ARM, si actives la casella d'instantànies com a cadena de volums. Totes són decisions de la primera setmana. Totes es descobreixen el dia de la restauració.

D'aquí surt la regla que apliquem i que resumeix el post: en una migració a Proxmox, el manual de limitacions del backup es llegeix abans de triar l'emmagatzematge, no després. És el mateix raonament que fem servir quan algú vol reutilitzar la seva cabina i descobreix que la instantània no viatja amb l'hipervisor: la peça que decideixes no tocar també decideix coses per tu.

Les línies avorrides, que també mosseguen

Els nodes d'un clúster s'afegeixen a la infraestructura de còpia un per un: no es pot afegir el clúster sencer com una sola entitat. És a dir que el node que vas comprar al març i vas afegir al clúster una tarda no és a la còpia fins que algú també l'hi afegeixi, i aquesta absència no genera cap error, perquè el que no hi és no falla. Després n'hi ha més: els canvis poden trigar fins a quinze minuts a veure's reflectits, no se suporta IPv6, el nombre d'operacions simultànies per emmagatzematge està limitat a quatre —es canvia obrint un tiquet al fabricant, no una casella— i el compte amb què el sistema de còpia entra al servidor Proxmox no pot tenir doble factor. Sobre aquesta última no farem sang: un compte de servei ha de portar la seva pròpia restricció d'origen i el seu propi control. Però convé que es decideixi expressament i no aparegui la tarda de la posada en marxa.

Com ho comprovem nosaltres

Quatre coses, en aquest ordre. Cap consisteix a mirar el color de la tasca.

• L'inventari de discos contra l'informe de la tasca. La configuració de cada màquina la dona el mateix hipervisor amb qm config <vmid>; allà es veuen els discos i de quin emmagatzematge penja cadascun. El que hi apareix i no apareix en el que la tasca diu haver processat és, literalment, la llista del que s'ha saltat. És mitja hora de feina i es fa un cop per trimestre.
• Els contenidors, en un inventari a part. Amb la seva pròpia eina, la seva pròpia retenció i el seu propi responsable amb nom i cognoms. Barrejar-los a la mateixa llista que les màquines virtuals és la manera més fiable de fer que un dia ningú no sàpiga qui copiava el contenidor del DNS.
• Restauració cronometrada. Amb la màquina original apagada, en un altre lloc, amb un rellotge al davant i el número apuntat on el vegi qui signa el pla. No val la pantalla de «restore completed»: val el minut en què l'aplicació torna a atendre. Si no l'has mesurat mai, no el tens.
• Després de restaurar, la llista del que no torna. La màquina torna a ser al grup d'alta disponibilitat? Hi ha el disc que anava en passthrough? Hi ha les regles del tallafoc que penjaven d'aquell identificador?

El que no estem dient

No estem dient que aquest producte de còpia estigui mal fet. La pàgina que hem estat llegint porta data d'actualització i número de compilació, i això és justament el que ens ha permès fer el que hem fet: comptar. L'incòmode ve després: aquesta pàgina canvia. La que hem llegit és del 15 de setembre i correspon a la 13.1.1.18; la que s'apliqui al teu projecte serà una altra. Un inventari de limitacions de fa sis mesos val el que val un backup de fa sis mesos.

Tampoc no és un argument contra migrar, i migrar continua valent la pena en molts casos. Ja hem escrit quan NO migrar de VMware a Proxmox, i allà també parlem d'aquest producte de còpia i d'un problema conegut de les seves tasques de replicació; això ja ho vam explicar i no ho repetim aquí. El que hi afegeix aquest post és una altra cosa: la matriu de suport de la teva còpia és part del disseny de la plataforma i entra a la primera fase del projecte. I si l'exercici et sona, és perquè ja vam recórrer una llista semblant en una altra plataforma quan vam mirar els xats de Teams.

A everyWAN gestionem recuperació davant desastres i còpies amb Proxmox Backup Server i amb Veeam, i fem migracions de VMware a Proxmox. No som revenedors de cap dels dos fabricants, així que quan diem on és la vora de cobertura no ens ho paga ningú.

Fonts (consultades el 24-set-2026): totes les limitacions citades —contenidors LXC, plantilles, emmagatzematge BTRFS i personalitzat, discos iSCSI i passthrough «skipped from processing», nodes de clúster afegits per separat, sincronització de fins a 15 minuts, IPv6, comptes amb doble factor, límit de 4 operacions concurrents per emmagatzematge, absència de restauració d'ajustos d'alta disponibilitat, restauració des de cinta i la incompatibilitat entre QEMU anterior a la 10 i l'emmagatzematge amb instantànies com a cadena de volums— provenen de la pàgina Considerations and Limitations de la guia d'usuari de Veeam Backup & Replication 13, actualitzada el 15-09-2026 per a la compilació 13.1.1.18. L'estat de suport experimental de la recuperació instantània cap a Proxmox VE, l'exclusió de les còpies a nivell de fitxer dels agents i de les màquines ARM, i la llista de càrregues de treball que sí que admet, són a Instant Recovery of Workloads to Proxmox VE. Les versions suportades (8.2–9.2, ISO oficial, x86-64, «Machines with the ARM CPU architecture are not supported») són a Platform Support. Que Proxmox Backup Server copia màquines virtuals, contenidors i equips físics és de la seva documentació oficial. L'anunci del suport oficial Arm64 del 05-08-2026 és a les notes de premsa de Proxmox. El que aquest post NO afirma: els recomptes de 18 «does not support», 10 «cannot» i 4 «not supported» són nostres, fets sobre el text d'aquella única pàgina en la data indicada, i canviaran amb cada actualització del manual; no són una mesura de la qualitat del producte ni una comparació amb cap altre, i per això matisem a dalt quants d'aquests «cannot» són de debò limitacions noves. No hem provat al laboratori cap d'aquestes limitacions per a aquest post: citem el que publica cada fabricant. No afirmem que cap altre producte de còpia cobreixi el que aquest no cobreix, ni a l'inrevés. No sabem, i no ho diem, quina eina de còpia suporta avui nodes Proxmox en ARM. I la regla de llegir el manual del backup abans de triar l'emmagatzematge és criteri nostre, no una recomanació de cap fabricant.