With the release of Veeam B&R 12.2, Proxmox support is built in. I've got a free proxmox server running with a handful of non-production VMs for testing. I followed Veeam's instructions to the letter and attempted to back up one VM, which worked without errors. However, the challenge I'm running in to is restoration. I tried to do a whole VM restore from Veeam back to my Proxmox host and it fails on preparing the disks for restore. They are suggesting I go look for logs on the Proxmox side and I would like a little guidance as to where to look on the host for this virtual disk failure.
Veeam Support for Proxmox
- Thread starter terrigan
- Start date
Hi @terrigan , welcome to the forum.
We had a similar experience with Veeam. We did open a case as requested by @Pavel Tide , but essentially were politely asked to go away and find a 3rd party integrator. The ticket is scheduled to be closed today. We have not heard back from @Pavel Tide since as well.
Hopefully, these type of issues are on Veeams radar and being worked on!
https://forum.proxmox.com/threads/ama-ask-me-anything-thread-veeam-pm.154015/#post-700974
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
We had a similar experience with Veeam. We did open a case as requested by @Pavel Tide , but essentially were politely asked to go away and find a 3rd party integrator. The ticket is scheduled to be closed today. We have not heard back from @Pavel Tide since as well.
Hopefully, these type of issues are on Veeams radar and being worked on!
https://forum.proxmox.com/threads/ama-ask-me-anything-thread-veeam-pm.154015/#post-700974
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Firstly, I assume that you have made sure that there is enough disk space on the host where you want to restore the VM; if this is not the case, please check again.
I have already tried the new feature myself and had no problems when backing up and restoring, so here are a few questions to find out how our setup differs.
To restrict the logs, you can specify a time span, for example.
Please check your logs for errors, if you are not sure about logs you can also post them here, anonymized if you like
I have already tried the new feature myself and had no problems when backing up and restoring, so here are a few questions to find out how our setup differs.
- I assume you are restoring it to the original location?
- If so, does the actual VM still exist there and do you try to delete it automatically?
- Which storage are you trying to restore the VM to?
- Is it the same storage on which the actual VM was already located?
journalctl.To restrict the logs, you can specify a time span, for example.
journalctl --since 2024-09-15 --until 2024-09-17Please check your logs for errors, if you are not sure about logs you can also post them here, anonymized if you like
There is enough space, this server is a test server and the VM was backed up off of it. I have not added anything to it. The VM does not show up in Proxmox. I am trying to restore it to the storage it was originally located in which is local-lvm. I will try to check logs on my own otherwise I will do as you suggested and post here.
Hi @hd-- , thank you for jumping in. Based on our investigation, Veeam needs to integrate natively into the backup flow the way PBS does. Currently, some essential integration is missing.
Specifically, Veeam creates the necessary volume to restore to. However, it does not _activate_ the volume. So, in cases where _activate_ is responsible for bringing the volume online, restore fails. A similar issue is present for virtual machines that are powered off.
The implementation of _activate_ is dependent on (i.e., overloaded in) the storage plugin. So, results vary from storage to storage. There are some possible, but kludgy, workarounds for the plugins to support Veeam's behavior. However, it seems they just need to properly integrate with _activate_ similarly to PBS.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Specifically, Veeam creates the necessary volume to restore to. However, it does not _activate_ the volume. So, in cases where _activate_ is responsible for bringing the volume online, restore fails. A similar issue is present for virtual machines that are powered off.
The implementation of _activate_ is dependent on (i.e., overloaded in) the storage plugin. So, results vary from storage to storage. There are some possible, but kludgy, workarounds for the plugins to support Veeam's behavior. However, it seems they just need to properly integrate with _activate_ similarly to PBS.
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Last edited:
But the VM was originally created on your Promox VE node?
And did the VM have any Snapshots when you created the Backup?
Thank you very much for the details @bbgeek17!
I will try to reproduce the behavior and understand how veeam is backing up/restoring the VM.
It was NOT originally created on Proxmox. It was migrated over from vmware quite some time ago to test the ease of transition to Proxmox. This was was before your migration tool was created. The VM did not have snapshots to my knowledge, unless Proxmox takes them automatically.
When the VM was deleted during restore i was able to restore it to proxmox from the built in backup. After having done that i was able to backup and restore the machine from Veeam. In Veeam the inventory was showing the VM real size instead of 0 byte like before. It looks like Veeam is not able to read the actual size of the machine before i remove and restore it once with built in backup. Note that it only applies to machines migrated from VMware.
Last edited:
Random thought (not tried out Veeam on Proxmox yet, do plan to just not enough time for it yet), but for the VM's migrated over from ESXi, did you already increase the disk-size (even by just 1 GB)? Maybe something somewhere wasn't properly set during the migration, and increasing the disk-size corrects that as well.
And what if you attach the migrated-over disks to a proxmox-made VM? To see if it is disk-related or settings-related.
Sidenote on the second idea: maybe also test both a VM that was and was not already backed up once by Veeam, to have all options there.
So:
So:
- Migrate VM from ESXi to Proxmox
- Create first new VM on proxmox with the same settings as the migrated VM's (bar the ID of course)
- Detach the disks from the esxi-VM, assign owner to the first new VM, attach disks (use the same disk-format as esxi as well)
- Test if the VM itself works
- Backup/restore VM
- Create a second new VM on proxmox with the same settings as the migrated VM's (bar the ID of course)
- Backup/restore VM
- Detach the disks from the first VM (or from the esxi-VM if you migrated it over again), assign owner to the second new VM, attach disks (use the same disk-format as esxi as well)
- Backup/restore VM