Restore order

[Streght]

Hi,
I currently have my Proxmox VE installed on a single SSD and I plan to move to 2 SSD in mirror mode.

I'll have to reinstall PVE. My PVE and PBS settings are backed up with Proxsave and all my VM / CT (installed on local-lvm, so on the SSD I'm replacing...) are backed up with PBS on the same machine but on dedicated drives.

I'm a bit confused on how I should proceed after the initial install of PVE to restore everything the way it was.

If I understood correctly, I should:

1. Perform a fresh install on the new SSDs with same hostname / IP
2. Perform a full restore from Proxsave
3. Restore my local PBS LXC from a backup save stored on another computer
4. Restore all my VM from PBS

Does this makes sense, am I taking the things in the right order?

I'll appreciate some help on this topic as I feel a bit lost here on how I should proceed.

Thanks,
Nick

[tis24dev]

Hi, your plan is fine: reinstall PVE (same hostname/IP) → Proxsave restore → restore PBS → restore VMs from PBS.

Clarifications:

• Proxsave = config only (network, storage, jobs, VM .conf). Not VM disks or PBS backup chunks on the dedicated drives.
• Mount the PBS data disks before Proxsave (or right after, before using PBS).
• PBS must be up before bulk VM restore from PBS.
• If PBS is an LXC (not co-installed on the host), Proxsave on PVE may only restore PVE settings; PBS config may need a second restore inside the PBS CT after you restore that container.

To narrow this down:

• PBS co-installed on the host or LXC only?
• Proxsave backup type: PVE or dual?
• Will PBS datastore disks be mounted before the Proxsave restore?

[Streght]

Thanks a lot for the answer!
In the meantime, I actually landed on your Restore Guide which made things a bit more clear as well (I should have look a bit deeper before)...

To answer your questions:

All the disks are on the same physical machine, with only one node and no cluster (standalone):

• 1 SSD for PVE + VM in local-lvm, which will be replaced by 2 SSDs in RAID1
• 1 HDD with PBS datastore
• 4 HDD for Truenas

PBS is installed on a LXC (and with its own Proxsave JIC) and the datastore is mounted in PVE. The Proxsave backup type is therefore PVE in PVE, and PBS in PBS.

The plan is as follow:

1. Retrieve on another machine Proxsave backup .tar + Proxsave config + VM / LXC latest backups .tar.zst just in case
2. Remove old SSD, add the 2 new ones, don't change anything else physically on the machine.
3. Install fresh PVE with same hostname / IP
4. Install Proxsave, update the config with the backed up one, run a full restore.

After this, am I correct to say that the storage pool / NFS / datastore connection will be restored as all the disks are physically there? /etc/pve/storage.cfg file contains all the info, if the PBS disk is connected, will it show up or does it need the PBS LXC as well?

5. Restore PBS LXC for the .tar.zst file

On this point, if the datastore is already mounted as discussed above, do I actually need to restore from the .tar.zst, or can I just restore them from the datastore?

6. Restore all other VM / LXC

[tis24dev]

Thanks, that setup is clear (standalone, PBS in LXC, separate Proxsave backups on PVE and PBS).

Your order is fine: new PVE → Proxsave on PVE → PBS LXC back → Proxsave on PBS → restore VMs from PBS.

After Proxsave on PVE

Settings come back (network, storage list, jobs, VM/CT definitions).
VM disks on the new SSD and backup files on the PBS HDD do not.
Disks / storage

TrueNAS NFS: usually OK once TrueNAS is up and the network matches.
PBS in Proxmox: the PBS container must be running. The datastore HDD alone is not enough.
If the PBS HDD and backups are intact: you usually do not re-import VM backups from .tar.zst. Use .tar.zst mainly for the PBS container, then Proxsave on PBS.
Hostname / access

Same hostname and IP (as you planned) is recommended. Use the same Proxmox URL as before (helps PBS and 2FA/passkeys).
root password is from the new install, not the backup.
If Proxsave restores network, use local console if you can (SSH may drop).
Optional: Proxmox → Storage: is PBS listed as “PBS” (container address) or as a folder on the host?

[Streght]

Thanks for the answer, it's a lot clearer now!

On the host, PBS is listed as "Proxmox Backup Server" in the Storage menu.

Just one most question regarding the PBS step: I restore the .tar.zst backup for PBS after Proxsave on PVE, the backup itself is already configured, I don't need to run Proxsave in it right, as this isn't a new install?

Once the backup is restored, the datastore in the PVE storage list should now show the backup files right? Is the datastore already showing before PBS restore, simply without the files? Config allow the datastore to show but the files aren't there yet right?

[tis24dev]

Exactly right on both points.

PBS container: No, you don't need to run Proxsave inside it. Restoring the .tar.zst brings the container back fully configured (config + database), so Proxsave-in-PBS is only needed for a fresh PBS install, which isn't your case.

Datastore in the PVE storage list: The PBS storage entry shows up as soon as the storage config is restored on PVE, so yes, it's already listed before you restore the PBS container, just offline/empty. PVE lists the snapshots by querying the
PBS server over the network, not by reading the disk directly. So once the PBS container is back up and reachable, the entry goes active and the existing backups (which never left the datastore HDD) appear on their own. Nothing gets
re-imported.

So your sequence is spot on.

[Streght]

Perfect! I'm really sorry to take just one more minute of your time, I marked this as answered but I actually have an additional question while reviewing one last time the Restore Guide.
Regarding the Export Only categories, if I understand correctly, these are not restored even with a full restore.

I don't have a cluster (so no corosync) so if I follow the guide, I only need to restore datacenter (not much in it in my case), user and storage config files, plus VM / CT.
So for the VMs, I need to run the following (adapting the ID):

cp /opt/proxsave/proxmox-config-export-*/etc/pve/qemu-server/100.conf \
   /etc/pve/qemu-server/100.conf

For the CT (adapting the ID):

cp /opt/proxsave/proxmox-config-export-*/etc/pve/lxc/100.conf \
   /etc/pve/lxc/100.conf

and for the configuration files:

cp /opt/proxsave/proxmox-config-export-*/etc/pve/user.cfg \
   /etc/pve/user.cfg
cp /opt/proxsave/proxmox-config-export-*/etc/pve/datacenter.cfg \
   /etc/pve/datacenter.cfg
cp /opt/proxsave/proxmox-config-export-*/etc/pve/storage.cfg \
   /etc/pve/storage.cfg

Also, should I restore pve-ssl.pem and pve-ssl.key (sorry for the noob question, I don't know what these are for...)

A full restore plus these restores everything configuration-wise except VM volumes, I just have to run pbs restore after that right? Anything else I'm forgetting?

Anyway, if I get through this successfully, coffee is definitely coming your way!

[tis24dev]

No worries, happy to help.

A small but important correction: user.cfg, datacenter.cfg and storage.cfg are not export-only. They are staged categories that a FULL restore applies for you (storage/datacenter via the pvesh API, access control via pmxcfs), so you don't need to cp them by hand. Copying storage.cfg straight into /etc/pve actually bypasses the safer API apply, so let the restore handle those.

The only things you genuinely copy from the export directory are the guest configs, because the whole /etc/pve is export-only. So your VM/CT commands are exactly right:

cp /opt/proxsave/proxmox-config-export-*/etc/pve/qemu-server/100.conf /etc/pve/qemu-server/100.conf
cp /opt/proxsave/proxmox-config-export-*/etc/pve/lxc/200.conf        /etc/pve/lxc/200.conf

pve-ssl.pem / pve-ssl.key: skip them. They're the node's web/API TLS cert and key. A fresh PVE install generates a new CA and node cert, and restoring the old cert without the old CA just causes a mismatch. Leave them to PVE (if ever needed: pvecm updatecerts -f). Custom web certs would be a different file (pveproxy-ssl.pem).

So the flow is: FULL restore (applies network/storage/datacenter/users) → manually copy the VM/CT .conf from the export dir → bring the PBS LXC back → restore VMs from PBS. Then just check the guests start and storages are online. That's it.

Coffee appreciated. 😄 If you'd like to support the project, there's a button here:

[Streght]

Hello, everything went almost smoothly, I was able to restore everything correctly (granted my setup is pretty minimal). Coffee incoming!

A couple of points I struggled on (but maybe it's just me):

• The notification config file wasn't restored, I had to copy it manually but maybe this is intended.
• The NFS share in Proxmox weren't restored, there were some mount guards applied and I didn't really understand how to manage this, I ended up setting up the NFS shares manually and delete the guard file so I'm interested to know what's the correct way to proceed on this.

[tis24dev]

Hi, I understand the issue. I checked it out, and there was indeed both a bug in the code and a lack of documentation regarding this step.
I'm working on fixing it and hope to release the fix soon.

[tis24dev]

@Streght Hi, I’ve conducted a thorough analysis and found the bug that was causing problems with your restore. It shouldn’t happen again during the next restore.
Those mounts are locked to prevent incorrect writes to non-existent mounts; now, if they’re present, they’re automatically unlocked at the end of the restore. I’ve also added a specific command to force them to unlock in edge cases.

Sorry for the delay, but my investigation also uncovered other bugs that I had to address, which took some time.

They're in the next release

[Streght]

Hey, happy to help and thanks for the feedback, it's good to know that these are adressed, at least now I went through the whole process so if I have to do it again I know you got me covered!
I'll ad the command to unlock the share to my personal wiki as soon as your documentation is updated.
Again, thanks for you work, dedication and help on this!

[tis24dev]

here the fix: v0.26.0

Added --cleanup-guards for removing leftover restore mount guards after storage returns.