Gavino

Proxmox VE 9.1: Full backup and recovery support for workloads running on the latest Proxmox VE release The latest Proxmox VE release is actually v9.2 released 21st of May https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.2 - well before this June 4th announcement. Getting support is becoming very frustrating. When PVE 9.1 was out, Nakivo only supported PVE 9.0. Then PVE 9.2 comes out and only then do you support PVE 9.1. It seems like I can never get support from Nakivo if you are always behind. This is because with PVE - at least exposed in the web GUI - there is no option to pin to a particular point release. All the critical security patches and point release updates come down at the same time. If I was to just ignore the updates then sure - Nakivo would eventually catch up. But then I am vulnerable. Also I have to upgrade at some stage, and if you are always one point release behind the latest version, when I update (which would be to the latest version - again I cannot choose a point release) I would again be in front of what Nakivo supports, and again your support team would choose not to support me - a paying customer - as has happened recently when I wanted support for an issue yet because I am on PVE 9.2.2 (as I want the latest security fixes) I do not get support running the latest version of Nakivo. Another issue - "NBR_Transporter_v11.2.1_Updater_QNAP.qpkg" package which is the transporter (not director) package for x86_64 QNAP, it says that the digital signature is expired. I just checked the Nakivo download site and saw that the package there as I write this still has the expired certificate. This has happened in the past and Nakivo have eventually rectified it. That fact that it is still happening though does not speak good things about this company.

The 11.2 beta is out now. Release notes https://beta-helpcenter.nakivo.com/User-Guide/Content/Deployment/System-Requirements/Supported-Platforms.htm state "Proxmox VE v8.x - v9.1 (Compatibility Support)"

I have responded to the private message. Since posting this feature request, I have changed my setup. I used to have a deduplication repository on my primary storage, and my backup job would go to that. Then I would have backup copy jobs sending VM backups to a remote QNAP NAS setup for non-deplication, and also immutable backups. In an effort to speed up The Nakivo Proprietary method, and also Flash VM Boot, I have swapped that around. My Primary (local) NAS is now setup for keeping VM backups as separate files and no deduplication, and also immutable backups. I switched the remote QNAP NAS to a deduplication repository, with long term storage of VM recovery points. It would now be dangerous for me to use the Reset CBT feature and do a full backup to the local primary NAS, because with no deduplication and immutable backups, I would be in danger of filing up that repository. But this feature may still be useful and required for people who have their backups setup like how mine once was - backing up to a deduplication repository for their backup jobs (as apposed to backup copy jobs).

PVE 8.4 has limitations around the TPM. On PVE "Directory" storage such as NFS, the TPM is stored as a raw image, rather than qcow2. If you go to snapshot the VM with TPM on 8.4 you cannot, and it states, "The current guest configuration does not support taking new snapshots" due to the TPM. This changed in PVE 9.1. The roadmap https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 states the following: Support for TPM state in qcow2 format. Some VM guest workloads require attaching a virtual Trusted Platform Module (TPM), for example newer Windows guests. The state of a virtual TPM can now be stored in the qcow2 format. This allows taking snapshots of VMs with a TPM state on file-level storages such as NFS or CIFS shares. Storages with "snapshots as volume chains" (technology preview) enabled now support taking offline snapshots of VMs with TPM state. I tested on PVE 9.1.2, with a new test server installation, I can now actually take a snapshot on a VM with TPM device. That's my TPM on PVE 9.1.2 showing that it's in qcow2 format. I hope that the next version of has support for this.

Just to re-iterate my earlier point, even without SDN support, the current implementation is broken as it doesn't allow assigning a VLAN ID. In the first screenshot, where the pull-down says "select a target network", what you can select there are not actually target networks. They are Linux bridges. The coders have equated ESXi Port Groups with Linux bridges, but they are not one and the same. The equivalent construct to an ESXi Port Group is actually the Proxmox SDN VNet. Since Proxmox can use a bridge with an optional VLAN ID, at the very least we need to be able to select the VLAN ID. The code needs to move away from the ESXi code and have: Select Bridge [ (pulldown menu)] (what 'Select Target Network' currently gives) Select VLAN ID [ ... ] (user can type integer from 1-4093, or can be left blank) Then when introducing SDN support, add: [(radio box)] SDN [Zone] [VNet] - A check box which would grey out the above and activate a pull-down of the SDN Zones and corresponding VNets, pulled in via Proxmox API. I think this would be straightforward to code. I also think these details should be stored in the metadata of each VM backed up, so when you restore, it can be pre-populated. Usually you would want to put the VM back onto the same network as what it was backed up with.

Previous post from the official moderator said, "Proxmox VE v9.0 will be supported in NAKIVO version 11.2, ETA Q1/2026, likely January." Assume that will now be for 9.1, as 9.1 only just went GA this week.

Ah I worked it out immediately after posting. I have to go to the little "+" and remove the repo I don't want to back up to there... It's not very intuitive. The tick boxes on the screen above seem to serve no purpose, other than to confuse. Anyway, it's resolved now. Thanks.

In 11.1, if I select only 2 repositories to back up the system configuration to then "Apply", it doesn't save the selection. When I go back in after saving, none are selected, and it backs up to all repositories. This is a bug. Please fix. Thanks.

I too am waiting anxiously for Nakivo support for PVE v9, as there are many features that I am looking forward to, yet a lack of official Nakivo support is holding me back from enjoying those benefits. There was a PVE v9 BETA in July, and the initial release in early August. We are now 3 months on. Surely PVE v9 support is coming soon? Also released early August was Debian 13, and yet Debian 13 is still not listed here in Deployment Requirements. https://helpcenter.nakivo.com/User-Guide/Content/Deployment/System-Requirements/Deployment-Requirements.htm. For Proxmox I get it - the Proxmox Beta cycle didn't last long. For Debian, the story is way different. The Beta cycle of Debian 13 lasted over a year, with a "hard freeze" in 2024. Debian 13 support should really have been in the first patch that came out after Debian 13's official release. It's one of the most popular Linux server operating systems, probably only beaten by Ubuntu Server. So for there to be no Debian 13 support three months after release - that's a real head-scratcher. Nakivo have always delivered in the past. May I ask - what is different this time around? I won't dare speculate, but feel that something has changed.

Not in the current version 11.1.0. I've installed the free PBS on my NAS alongside Nakivo, just for backing up the one LXC container I have. I would imagine that as more and more businesses make the switch from VMware to Proxmox, that more and more Proxmox features and improvements will come, and that this will be added eventually. Especially since one competitor I saw added it recently - back in August I think. I'd love to have it too - although not a show stopper at the moment.

Thank you so much, and I appreciate the support. I know that Proxmox compatibility is very recent in the general scheme of things, and so understand that development is ongoing. I look forward to all the improvements that's coming down the pipe. Unfortunately I was too busy to get involved with the 11.1 beta, but will endeavour to get involved with future beta releases, and provide feedback. Cheers.

I have 7 client VLANs - 3 for wired networks - 3 for wifi networks, and 1 for test. I also have a few different bridges, so that my virtualized firewalls have dedicated interfaces off each Proxmox node. Having the VNet name means that at a glance - we can easily see what each VM is connected to. There's no way we want to add a new physical port every time we add a new VLAN. We use trunk ports. In vSphere this is called Virtual Switch Tagging, or VST. External Switch Tagging (EST). The proxmox vmbr bridges aren't VLAN-aware, and the network switches (not Proxmox) handle all the VLANs. This doesn't scale well, as it requires a physical NIC per VLAN. Virtual Switch Tagging (VST). Very common, and probably the most common way of setting things up. This is where VLANs are trunked into Proxmox and the Proxmox mode handles the VLANs - guest VMs and containers don't know about them. This is what we use for almost all our vNICs, barring one firewall vNIC. Proxmox vmbr bridges are VLAN-aware. Virtual Guest Tagging (VGT) - where tagged frames are passed all the way to the guest VMs / containers. I don't use this, but have in the past. Again, Proxmox vmbr bridges are VLAN-aware. And this is all without SDN on Proxmox - I can only see that Nakivo supports the first type - the very limiting EST. If it did support VLANs on the Linux bridges (with VLAN IDs, and ideally VNet names), then I would not have to add caveats to my disaster recovery flash VM boot jobs. At the moment I have to make sure that they don't start the VM. Because after the job runs, I have to shut down the VM. Then update the NIC with the correct VLAN settings, before I can start it. That costs time and money and risk in our environment as I have to train all the techs to do that workaround. What needs to happen, is for the VLAN info to be properly recorded in the Flash VM boot settings, so we can just fire up the job and the VM can start up and get working, with no tedious meddling with settings which slows down disaster recovery, and increases the risk if someone doesn't know the right bridge and or VLAN ID. With SDN, you don't have to remember any of that - the Bridge and VLAN ID is basically encoded in the VNet name. There's more I could say on the benefits of this, but that will do for now. Thanks.

I was initially puzzled by my pfSense VM's screeshot verification output: All four of my vNICs are gone! I never had that issue doing screenshot verification on VMware vSphere (vCenter / ESXi). So what gives? Well, testing some Flash VM Boot just now, I see that when you choose "Not connect to any virtual network" that the VM actually ends up not even getting a network adaptor on Proxmox. So I'm pretty sure that the Screenshot Verification is choosing this option, which is why my firewall verification screenshot shows no network adapters. I think it's also why one of my Windows VMs (the Domain Controller) has problems with screenshot verification, as having no network creates all sorts of mayhem for something that is an AD Domain Controller, DHCP server, DNS server, and Network Policy Server. I've increased the timeout to a ridiculously long time, and it still struggles to get to the login screen (again - didn't have that issue on VMware). Can we get a technical fix for this? Each vNIC should connect to a separate dummy bridge on the Proxmox host, to fool the VM into thinking it has a network connection, but without actually connecting to anything. Having my VMs come up for screenshot verification with no network interfaces is ... well it's not good... not happy with that.

The Proxmox Full Recovery for Proxmox VE leaves a lot to be desired when it comes to Network Selection. I only have these options: But they are no good to me. I use SDN VNets. These all set a VLAN tag on either of vmbr1 (for my "VMmain" zone) or vmbr4 (for my "VMfwlan" zone): One example is of my hosted firewall with for virtual NICSs the first of the vNICs uses the vmbr directly (vmbr3), but the rest reference the SDN VNets. So the Nakivo restore option really should list all my SDN VNet IDs as well as the vmbr bridges. Even better why can't Nakivo default to whatever the VM was using when it was backed up? I've always wondered why I have to manually put this information in? It's annoying enough when it's just the one vNIC. But it's annoying on multiple levels when there are multiple vNICs, AND I can't even choose the VNet names. This part of the Nakivo B&R product needs a lot of work, as I've always found it a major pain point.

I had a look at the beta User Guide, which the Home page says is for 11.2. I checked supported platforms.... https://beta-helpcenter.nakivo.com/User-Guide/Content/Deployment/System-Requirements/Supported-Platforms.htm Still says the supported platform is Proxmox VE v8.3-1 - v8.4-1 A bit concerning. Hopefully that gets updated to VE 9.x by release.