Your Proxmox backup skips disks and the job still turns green

There is one word in your backup manual that decides whether you have the backup you think you have, and it is not "error". It is skipped. The disk is not copied, nobody warns you, and the job finishes successfully.

The considerations and limitations page for the Veeam plug-in for Proxmox VE was updated on 15 September 2026 and applies to build 13.1.1.18. We read it end to end and counted: the phrase "does not support" appears 18 times, "cannot" another ten, "not supported" four more. The method is simple and we state it so anyone can repeat it: count over the text of that page, excluding navigation and footer. With the caveat it falls to us to add, because the raw number flatters the case: of those ten "cannot", three are conditionals of the "if you cannot use the default storage" kind, and one sits inside a sentence already counted as "does not support". Six new limitations, then, not ten.

A number like that does not say much on its own either. Every backup product has a similar list, and the list for a new hypervisor is always longer than the one for the hypervisor that has been on the market for twenty years. What does say something is what is on the list, and that page holds three quite different categories: what is not backed up, what does not come back on restore, and what does not even make it into the supported platforms table.

Two kinds of "not supported"

The first kind stops you. If a machine keeps its disks on BTRFS or on custom storage, it is not backed up; the manual says so and adds that all other Proxmox VE storage types are supported. VM templates are not backed up either. Nor are LXC containers. That is visible: the machine is missing from the job, somebody asks, and it gets fixed, or someone decides not to fix it.

The second kind does not stop you. Two lines in the manual, almost back to back, use the same construction. On iSCSI disks attached to a VM: "such disks are skipped from backup processing". On directly attached (passthrough) disks: "these disks will be skipped from processing". The machine goes into the job. The job completes. One of its disks is not in it.

Our opinion, and we flag it as opinion: the second kind is the dangerous one, precisely because it generates no work. A failure produces an email, a ticket and someone looking at it. A green job produces nothing. And notice which machines tend to carry a passthrough disk or a directly attached iSCSI LUN: the database server someone handed the whole NVMe to so it would perform, the file server with the SAN volume attached directly. They are, almost by definition, machines somebody built in a special way because they mattered.

LXC containers are left out

The line is a single sentence: the plug-in does not support backup of LXC containers. In a paragraph of manual text it looks like a detail. On a Proxmox platform it weighs, because half the platform leans on LXC: that is why the create menu has two buttons and not one.

People arriving from vSphere do not hit this on day one, because over there everything was a virtual machine. They hit it in month three, when someone works out that internal DNS, the proxy, the monitoring collector and the team wiki all fit in a container for a fraction of the memory. The migration went fine, the platform is cheaper to run, and without anyone deciding it in a meeting a second category of workload has appeared that the nightly backup job does not look at.

There are three ways out, and each has a price worth knowing. The first is already installed: Proxmox VE backs up containers out of the box with vzdump, no licence and no agent. We say it even though it does not help our argument, because it is the truth: the gap belongs to the plug-in and not to the platform. The price is that this backup lives outside your central console, with its own retention and its own dashboard. The second is to put an agent inside the container and treat it as one more Linux machine; it works, but what you get there is a file-level backup, and that is where the small print sits: the manual rules out instant recovery from file-level backups created by the agents (Linux, Windows, Unix, Mac) and by Kasten. From volume-level agent backups it does work; from file-level ones it does not, and it is worth knowing which of the two you are talking about before you sign a recovery time. The third is Proxmox Backup Server, which according to its own documentation backs up virtual machines, containers and physical hosts. We manage backups with several of these tools at once, and the question to answer in writing is which one covers what.

What does not come back when the machine comes back

The restore side has its own list, and one line there reads fast and costs dear: high availability settings are not restored. Translated into what actually happens: you restore the server, it boots, it serves, everyone breathes out. And that machine has quietly stopped being part of the HA group, because nothing on screen says so. The day the node it lives on dies, it does not come up elsewhere. It is the same pattern we described in RTO and RPO with no fluff: the number you promise is set by what still has to be rebuilt by hand after the restore.

Two more from the same list, in order of surprise. You cannot restore a machine to Proxmox VE straight from tape: the backup has to be returned to a supported repository first. And the one that caught our attention most, because it is specific to Proxmox VE 9: from that version some storage types support snapshots as volume chains, and since that functionality requires QEMU 10 or later, machines running an earlier QEMU version cannot be restored to storage with that option enabled. The vendor publishes a knowledge base article with a way around it, so this is not a wall; it is an extra procedure someone has to know about on the day of the incident. And the origin of all of it is a storage checkbox, ticked this year for good reasons.

And one that has to be stated in its place so as not to overstate it: instant recovery to Proxmox VE is published with experimental support status. The vendor says so on its own page, with a footnote linking to its definition. It works, and they will take your ticket. What an experimental status will not carry is a recovery time clause signed with a customer, and that distinction has to be drawn by whoever sells the service.

A whole architecture left outside

The supported platforms table says Proxmox Virtual Environment 8.2 to 9.2, installed from the official ISO image, on an x86-64 machine. And it adds one sentence: machines with the ARM CPU architecture are not supported. Separately, and this applies to backups taken with other plug-ins, instant recovery does not work from backups of ARM VMs either.

This would not be news if Proxmox had not announced official Arm64 support on 5 August 2026. When it came out we wrote that ARM does not extend your cluster, it makes you run two. Today one line has to be added to that calculation, and we flag it as our own reasoning rather than anyone's published fact: if your backup tool does not support the node, that second cluster needs a backup answer of its own. Which one is an open question — the 5 August announcement is about Proxmox VE, not Proxmox Backup Server — and it gets answered before you buy the hardware.

The list is your platform spec

Here is what we really wanted to get at. Go back over the lines above and look at when each one gets decided: what storage type you build, whether that workload runs in a container or a VM, whether you hand it the disk directly or serve it through the hypervisor, whether you buy ARM nodes, whether you tick the snapshots-as-volume-chain box. All of them are week-one decisions. All of them are discovered on restore day.

From that comes the rule we apply, and it sums up this post: in a migration to Proxmox, the backup limitations manual gets read before you choose your storage, not after. It is the same reasoning we use when someone wants to reuse their existing SAN and finds out the snapshot does not travel with the hypervisor: the piece you decide not to touch also decides things for you.

The dull lines, which also bite

Cluster nodes are added to the backup infrastructure one by one: you cannot add the cluster as a single entity. Which means the node you bought in March and added to the cluster one afternoon is not in the backup until someone adds it there too, and that absence produces no error at all, because what is not there does not fail. Then there is more: changes can take up to fifteen minutes to show up, IPv6 is not supported, the number of concurrent operations per storage is capped at four — changed by opening a vendor ticket, not by ticking a box — and the account the backup system uses to reach the Proxmox server cannot have multi-factor authentication. We are not going to make a meal of that last one: a service account should carry its own source restriction and its own controls. But it ought to be decided on purpose rather than turn up on the afternoon of the rollout.

How we check it

Four things, in this order. None of them is looking at the colour of the job.

• The disk inventory against the job report. Each machine's configuration comes from the hypervisor itself with qm config <vmid>; that shows the disks and which storage each one sits on. Whatever appears there and does not appear in what the job reports as processed is, literally, the list of what was skipped. It is half an hour of work, once a quarter.
• Containers, in a separate inventory. With their own tool, their own retention and their own named owner. Mixing them into the same list as the virtual machines is the most reliable way to end up with nobody knowing who was backing up the DNS container.
• A timed restore. With the original machine switched off, somewhere else, with a clock running and the number written down where whoever signs the plan can see it. The "restore completed" screen does not count: what counts is the minute the application starts answering again. If you have never measured it, you do not have it.
• After the restore, the list of what does not come back. Is the machine in the HA group again? Is the passthrough disk there? Are the firewall rules that hung off that identifier there?

What we are not saying

We are not saying this backup product is badly made. The page we have been reading carries an update date and a build number, and that is exactly what let us do what we did: count. The uncomfortable part comes next: that page moves. The one we read is dated 15 September and applies to build 13.1.1.18; the one that applies to your project will be a different one. A six-month-old inventory of limitations is worth what a six-month-old backup is worth.

Nor is this an argument against migrating, and migrating is still worth it in plenty of cases. We have already written about when NOT to migrate from VMware to Proxmox, and there we also covered this backup product and a known issue with its replication jobs; we told that story then and we are not repeating it here. What this post adds is something else: your backup's support matrix is part of the platform design and belongs in phase one of the project. And if the exercise feels familiar, it is because we walked a similar list on another platform when we looked at the Teams chats.

At everyWAN we manage disaster recovery and backups with both Proxmox Backup Server and Veeam, and we run VMware to Proxmox migrations. We are not resellers of either vendor, so when we say where the coverage boundary sits, nobody is paying us to say it.

Sources (consulted on 24 Sep 2026): every limitation cited — LXC containers, templates, BTRFS and custom storage, iSCSI and passthrough disks "skipped from processing", cluster nodes added separately, synchronisation of up to 15 minutes, IPv6, multi-factor accounts, the limit of 4 concurrent operations per storage, high availability settings not restored, restore from tape, and the incompatibility between QEMU earlier than 10 and storage with snapshots as volume chains — comes from the Considerations and Limitations page of the Veeam Backup & Replication 13 user guide, updated on 15-09-2026 for build 13.1.1.18. The experimental support status of instant recovery to Proxmox VE, the exclusion of file-level agent backups and of ARM machines, and the list of workloads it does accept, are in Instant Recovery of Workloads to Proxmox VE. The supported versions (8.2–9.2, official ISO, x86-64, "Machines with the ARM CPU architecture are not supported") are in Platform Support. That Proxmox Backup Server backs up virtual machines, containers and physical hosts comes from its official documentation. The official Arm64 support announcement of 05-08-2026 is in the Proxmox press releases. What this post does NOT claim: the counts of 18 "does not support", 10 "cannot" and 4 "not supported" are ours, taken over the text of that single page on the stated date, and they will change with every update to the manual; they are not a measure of the product's quality nor a comparison with any other, which is why we qualify above how many of those "cannot" are genuinely new limitations. We did not lab-test any of these limitations for this post: we cite what each vendor publishes. We do not claim that any other backup product covers what this one does not, or the other way round. We do not know, and do not state, which backup tool supports Proxmox nodes on ARM today. And the rule about reading the backup manual before choosing your storage is our own judgement, not a recommendation from any vendor.