Identifying backup files

[grin]

I'm curious whether nobody yet noticed the problem with backups: they get a date and the number of CT (or VM), and that's all. It is a bit confusing when the CT is around but it's close toimpossible to handle when the original CTs get destroyed, then someone would like to recreate them from the backup. Except there is no indicator that, say, "CT-1234" was "air-defense-controller" and "CT-4321" was "bubblegum-painter-developer-environment".

Displaying some metadata [original name, disk, mem size] would be nice. Even being able to attach notes / summary would be a nice welcome from the current state of affairs.

 

[ojaksch]

You haven't to get curious. Just use the search function and read the docs more attentive
As usual somebody had the same question or idea before you: https://forum.proxmox.com/threads/put-vm-name-into-backup-name.27495

 

[grin]

You haven't to get curious. Just use the search function and read the docs more attentive
As usual somebody had the same question or idea before you: https://forum.proxmox.com/threads/put-vm-name-into-backup-name.27495

Thanks! Nice pointer. I am guilty of not searching first.

Blame notwithstanding, the pointed resources raise more problems. Hook example is pretty basic (show the stages and env variables), but as far as I see the intent I am supposed to rename the file and the log in the backup-end hook. This requires the access to the data of the CT. So I thought it's time to get familar with the API.

It has been a mistake. It seems API is seriously underdocumented (or, rather, its perl interface), the two examples don't work (I was able to tweak them to work by guessing).
There is pvesh which interestingly work, doesn't choke with "proxy error" for accessing even other nodes, but large amount of sources would require heavy reverse engineering to figure out why do example1.pl fail while pvesh don't (probably related to the token handling but hard to tell from the uncommented code). So I may fall back to call pvesh with exec which is kind of ugly, but possibly work.

 

[grin]

Tried, failed. Or rather it isn't correct since the renamed image seem to have lost its metadata: restore >> show info gives error 500. This renaming method isn't the one.

 

[dcsapak]

there is another possibility:

in recent versions, there is an api call "extractconfig" which can extract the config
of the backup (including name), so you can either do

pvesm extractconfig <path-to-backup>

or

pvesh get /nodes/<nodename>/vzdump/extractconfig -volume <path-to-backup>

where <path-to-backup> is either an absolute path or the volume syntax from the
vm config files (e.g. local:backup/vzdump-qemu-vmid-date.vma.lzo )

in the gui, you find this in the backup tab of vms
there is a button "show configuration" which shows this information