[SOLVED] PVESH or API: get cluster/backup/id not working

[napalu]

The command `pvesh get cluster/backup` returns a list of defined backups in the following format:

200 OK
[
   {
      "compress" : "lzo",
      "dow" : "mon,tue,wed,thu,fri,sat,sun",
      "enabled" : "",
      "id" : "7d3875b8db02bfcb258d1904f0c6745af64db4ea:1",
      "mailnotification" : "always",
      "mailto" : "some@email",
      "mode" : "snapshot",
      "node" : "some-id",
      "quiet" : 1,
      "starttime" : "00:00",
      "storage" : "shared_san",
      "vmid" : "330,309,313,315"
   }
]

But querying an individual job as described in the documentation at https://pve.proxmox.com/pve-docs/api-viewer/index.html querying an individual backup id does not work.

For instance in the above example none of :
`pvesh get cluster/backup/7d3875b8db02bfcb258d1904f0c6745af64db4ea:1`
`pvesh get cluster/backup/1`
`pvesh get cluster/backup/:1`

works - the server responds with id: 'no such job'

Is the documentation wrong or the output of `pvesh get cluster/backup` or am I doing something wrong or what?

Thanks in advance.

 

[dietmar]

Works here

# pvesh get /cluster/backup
200 OK
[
   {
      "compress" : "lzo",
      "dow" : "sat",
      "enabled" : "",
      "id" : "d6fc41931c16988fd8b3ed34296caf4a9af640d8:1",
      "mailnotification" : "always",
      "mode" : "snapshot",
      "quiet" : 1,
      "starttime" : "00:00",
      "storage" : "local",
      "vmid" : "100"
   }
]
lola:~ # pvesh get /cluster/backup/d6fc41931c16988fd8b3ed34296caf4a9af640d8:1
200 OK
{
   "compress" : "lzo",
   "dow" : "sat",
   "enabled" : "",
   "id" : "d6fc41931c16988fd8b3ed34296caf4a9af640d8:1",
   "mailnotification" : "always",
   "mode" : "snapshot",
   "quiet" : 1,
   "starttime" : "00:00",
   "storage" : "local",
   "vmid" : "100"
}

 

[dietmar]

Please note that those IDs changes as soon as you modify something, so you cannot store them and use it later. They are currently used to implement the GUI.

 

[napalu]

Thanks. I was retrieving the Backup Ids, then making a modification and then using the stored id under the assumption that the id would only change on the next call to retrieve the cluster backup ids Problem solved.