[SOLVED] How to restore a VM from encrypted PBS via CLI?

UdoB

Distinguished Member
Nov 1, 2016
1,748
633
183
Germany
Good morning,

this is for preparation of a desaster recovery, I am just evaluating ways to handle a problematic situation. Let's assume I have
  • a dead PVE
  • a working PBS
  • another PVE Node (in another unrelated Cluster) to run a restored VM; already connected to PBS - but with a different Encryption key, so I don't want to destroy that configuration
For accessing encypted PBS by CLI I can successfully fetch single files. I've verified that this works correctly:
Code:
~# proxmox-backup-client  restore     vm/2016/2023-07-19T22:05:06Z      --keyfile /root/pbsdeadnode.key --repository pbs.local   qemu-server.conf.blob qemu-server.conf
Using encryption key from '/root/pbsdeadnode.key'..
I can successfully reconstruct that VM from here by "qm importdisk" and so on. But that just feels wrong.

On the other hand for classic (and unencrypted) _dump_-files I can successfully restore a backup easy peasy like this:
Code:
qmrestore  vzdump-qemu-2057-2023_07_18-18_38_04.vma.zst  802057  --storage ceph0
What I currently fail to do is something like this:
Code:
~# qmrestore  'synopbs:backup/vm/2016/2023-07-19T22:05:06Z' 802016 
Error: missing key - manifest was created with key f2:aa:........
error before or during data restore, some or all disks were not completely restored. VM 802016 state is NOT cleaned up.
command '/usr/bin/proxmox-backup-client restore '--crypt-mode=none' vm/2016/2023-07-19T22:05:06Z index.json /var/tmp/vzdumptmp3221647/index.json --repository xxxx@pbs@192.168.3.110:xxxxxx' failed: exit code 255
I feel I am missing something obvious: qmrestore can not handle encryption and proxmox-backup-client does not handle the complete task? What is the equivalent command to manually restore a VM from encrypted PBS?

Best regards
 
just add a second PBS storage entry..
 
Okay, done.

I've added a secondary PBS specification on the PVE, this time with the known encryption-key and with the same physical Datastore on the PBS as it holds the relevant chunks. This was successful then:
Code:
proxmox-backup-client login --repository synopbs.ifi.loc:newencryptedaccess
But because this "newencryptedaccess" is only configured and known by the PVE client, not by PBS itself, this fails:
Code:
proxmox-backup-client list  --repository synopbs.ifi.loc:newencryptedaccess 
Error: no such datastore 'newencryptedaccess'

Of course using the well-known "old" name is wrong also. So no progress with this (incomplete?) approach.

I hesitated to create a second "overlay"-Datastore on the PBS side as it was not clear to me of this would affect the status quo of the existing backups.

The Solution for my situation: actually the "old" definition was simply unencrypted. So the simple way to success was to add the encryption key to the old PBS definition on PVE. This works. From now on new backups are encrypted with the single defined key. Unencrypted (old) backups stay restorable nevertheless.

While I've lost my separation between my two use-cases I're reached an acceptable situation. The n-dimenstional grid of users/auth realms/tokens and pbs-local-datastores/pve-side-pbs-connections with and w/o encryption and present/absent namespaces and WebGui/CLI is just not simple to grok.

And misunderstandings in an early implementation phase have consequences on the long run...

Best regards
 
the PVE-side *storage* name and the PBS side *datastore* name don't have to be the same. if I understand you correctly, you have

- a single datastore called "XXX" on the PBS side, containing both unencrypted and encrypted backups
- a single storage without an encryption key on the PVE side, pointing at this datastore

you can now simply add a second PBS entry on the PVE side, pointing at the same datastore, but using the encrypting key - the name on the PVE side has to be different of course ;)
 
ideally, you would at least separate the unencrypted and encrypted part via namespaces, else you might try to create backups/restore them via the wrong "name" on the PVE side and confusion will ensue ;)
 
Yes, that is exactly what I did. Then I could successfully "proxmox-backup-client login". It seems my second step after this was plainly wrong. Then I tried the other approach by adding the key to the old connection.

And because now I have a working situation I am fine :)
 
no, it's not what you did. you configured a non-existing datastore on the PVE side, instead of the existing one.. if you look in /etc/pve/storage.cfg, the entries should be identical except for encryption-key (and the storage name, e.g. "pbs: foo" and "pbs: bar") - most importantly, "server", "username", "datastore" and (if used), "namespace" need to be the same for both storage entries if they should point at the same content.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!