Need to backup broken Proxmox without ethernet

S

storskogen

New Member
Oct 30, 2025
7
0
1
Hello
Long story short: I broke my servern (something with Python) and now my I need to backup my VM's.
I can access my server with a local keyb and monitor but I cant run vzdump because I don't have a vmbr0 (obvious because I can't start the network).

Is there some other way to export the VM's? I have a fresh install on another disk where I would like to import the VM's.

And yes, I have backups but they are not up to date :(
 
Welcome to the Forum, storskogen!

You should be able to vzdump to a local disk. The existing one, if it has a sufficient amount of free space, or other - after connecting one (with SATA or USB).

Then restore the backup in a new host.
 
I'm surprised that (if?) the network is necessary to use vzdump to the local storage...

Could you post the exact command and the exact output?

(To not have to type the details manually into the post here, you can mount a USB stick in the host, copy the command and the error to a file and copy the file to the USB stick).
 
If you are already planning to use a different installation disk, what stops you from connecting the disk that contains the VM data now as secondary, and then copying/importing it?

How to do that depends on your storage configuration. It may be as simple as "cp /some/path/disk.qcow /right/path/disk.qcow". Or could be "qm disk import".

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Onslow said:
I'm surprised that (if?) the network is necessary to use vzdump to the local storage...

Could you post the exact command and the exact output?

(To not have to type the details manually into the post here, you can mount a USB stick in the host, copy the command and the error to a file and copy the file to the USB stick).
Click to expand...
The command I use is:
Code: 
vzdump 100 --compress gzip --storage local

and the error:
Code: 
INFO: starting new backup job: vzdump 100 --storage local --compress gzip
INFO: Starting Backup of VM 100 (qemu)
INFO: Backup started at 2025-03-06 17:08:37
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: VM Name: haos10.5
INFO: include disk 'scsi0' 'local-lvm:vm-100-disk-1' 32G
INFO: include disk 'efidisk0' 'local-lvm:vm-100-disk-0' 4M
INFO: snapshots found (not included into backup)
INFO: creating vzdump archive '/var/lib/vz/dump/vzdump-qemu-100-2025_03_06-17_08_37.vma.gz'
INFO: starting kvm to execute backup task
bridge 'vmbr0' does not exist
kvm: -netdev type=tap,id=net0,ifname=tap100i0,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on: network script /usr/libexec/qemu-server/pve-bridge failed with status 512
ERROR: start failed: QEMU exited with code 1
INFO: aborting backup job
ERROR: VM 100 not running
VM 100 not running
ERROR: Backup of VM 100 failed - start failed: QEMU exited with code 1
INFO: Failed at 2025-03-06 17:08:38
INFO: Backup job finished with errors
INFO: notified via target `mail-to-root`
 
bbgeek17 said:
If you are already planning to use a different installation disk, what stops you from connecting the disk that contains the VM data now as secondary, and then copying/importing it?

How to do that depends on your storage configuration. It may be as simple as "cp /some/path/disk.qcow /right/path/disk.qcow". Or could be "qm disk import".

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Click to expand...
Nothing but my knowledge I guess.
my /etc/pve/storage.cfg:
Code: 
dir: local
    path /var/lib/vz
    content iso,vztmpl,backup

lvmthin: local-lvm
    thinpool data
    vgname pve
    content rootdir,images
 
storskogen said:
Nothing but my knowledge I guess.
Click to expand...
You will likely need to rename the volume group of the old disk so that there is no conflict, then you'd add a new storage pool that points to the renamed VG.
You'd then restore you VM configs , then rescan for disks "qm disk rescan". The disks will be added as "unused" and you'd assign them to proper scsi/sata/etc bus/interface.


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: Onslow
alexskysilk said:
Then create it. there is no requirement for the bridge to have an uplink.
Click to expand...
It's not that simple because I broke the Python installation (or I don't understand how to do it :rolleyes:) I can't access the GUI or use commands like ifup. Nothing else changed in the config execept I messed up the Python-config I think.
 
ok, so you have two options.

first, you dont need a working python environment to edit /etc/network/interfaces and insert a stanza for vmbr0

but in your case, lets think through what you're actually able to accomplish. the most important question to ask here is WHERE would you back up your virtual machines to? if its on a remote machine and you dont have networking, what would it matter if vzdump was functioning?

Assuming you have some local disk (like a usb disk) that you can backup to, you dont HAVE to use vzdump. simple copy the disk and its respective /etc/pve/qemu-server/vmid.conf to the target disk.

If you do not and you backup target is on the network, all is still not lost. You can boot with a livecd (any ubuntu installer would do) and that regain you access to the networks. you can then use rsync to copy the above files to the destination.

Once you get everything dealt with, I hope you will learn the lesson of NOT COMINGLING your os disks with your payload disks.
 
alexskysilk said:
ok, so you have two options.

first, you dont need a working python environment to edit /etc/network/interfaces and insert a stanza for vmbr0

but in your case, lets think through what you're actually able to accomplish. the most important question to ask here is WHERE would you back up your virtual machines to? if its on a remote machine and you dont have networking, what would it matter if vzdump was functioning?

Assuming you have some local disk (like a usb disk) that you can backup to, you dont HAVE to use vzdump. simple copy the disk and its respective /etc/pve/qemu-server/vmid.conf to the target disk.

If you do not and you backup target is on the network, all is still not lost. You can boot with a livecd (any ubuntu installer would do) and that regain you access to the networks. you can then use rsync to copy the above files to the destination.

Once you get everything dealt with, I hope you will learn the lesson of NOT COMINGLING your os disks with your payload disks.
Click to expand...
I didn't mix up the disk, I made the mistake of following a guide that wasn't correct (or I did something wrong).
The server is non-essential, I have actually lived without it for more than 6 months, that's why I don't mind messing around with it.
Lessons learned and after trying to attach the VM-disks without success I decided to do a fresh install of Proxmox and create the VM's from scratch.

Thank you everyone that tried to help me!
 
alexskysilk said:
If the payload is on another disk (or raid volume) then you dont need to do anything. simply copy all your vmid.conf files and reinstall pve. once its installed, simply import your existing data stores and put the vmid.conf files back.
Click to expand...
It is on the same physical disk but LVM. I tried to attach the disk as bbgeek17 recommended but my knowledge wasn't good enough.
I installed Proxmox on a new disk instead.
 
storskogen said:
Then create it. there is no requirement for the bridge to have an uplink.
Click to expand...
storskogen said:
It's not that simple because I broke the Python installation (or I don't understand how to do it :rolleyes:) I can't access the GUI or use commands like ifup. Nothing else changed in the config execept I messed up the Python-config I think.
Click to expand...
There is no magic in the GUI. At the end it invokes standard linux commands.
Bash: 
ip link add name vmbr0 type bridge
ip link set dev vmbr0 up
should do that magic.
 
You must log in or register to reply here.
Top Bottom