prune-backups: invalid format

J

jazzl0ver

Renowned Member
Mar 6, 2013
75
1
73
Hi,

Code: 
root@vm-box-4:~# pveversion
pve-manager/6.3-3/eee5f901 (running kernel: 5.4.78-2-pve)

I cannot say the action from my side that caused this issue (probably, installing the latest updates), Proxmox backups stopped working. There's a letter from crond:
Code: 
400 Parameter verification failed.
prune-backups: invalid format - value without key, but schema does not define a default key

vzdump {<vmid>} [OPTIONS]

Its subject line:
Code: 
Cron <root@vm-box-4> vzdump 107 --prune-backups 'HASH(0x5610c5811400)' --mode snapshot --compress zstd --quiet 1 --storage filer-1-images --mailto root@mydomain --mailnotification failure

Obviously, it's not working anymore b/c of that HASH stuff in prune-backups key. Any ideas how to get that fixed?

storage.cfg:
Code: 
root@vm-box-4:~# cat /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content iso,rootdir,vztmpl,images
        prune-backups keep-all=1

dir: LVM-Storage
        path /mnt/pve/storage
        content images,backup,vztmpl,rootdir,iso
        prune-backups keep-last=2

nfs: filer-1-images
        export /zmir/backup/images
        path /mnt/pve/filer-1-images
        server filer-1-ceph
        content backup
        prune-backups keep-last=5

nfs: filer-1-iso
        export /zmir/ISO
        path /mnt/pve/filer-1-iso
        server filer-1-ceph
        content vztmpl,iso

nfs: filer-1-vms
        export /zmir/VMs
        path /mnt/pve/filer-1-vms
        server filer-1-ceph
        content images,vztmpl

nfs: trendy-images
        export /free/backup/images
        path /mnt/pve/trendy-images
        server trendy
        content backup
        prune-backups keep-all=1

nfs: trendy-backup-oracle
        export /free/backup/oracle
        path /mnt/pve/trendy-backup-oracle
        server trendy
        content rootdir,images
        prune-backups keep-all=1

nfs: trendy-backup-mysql
        export /free/backup/mysql/bin/mysql
        path /mnt/pve/trendy-backup-mysql
        server trendy
        content images,rootdir
        prune-backups keep-all=1
 
what does /etc/pve/vzdump.cron contain?
 
Code: 
root@vm-box-4:/etc/pve# cat /etc/pve/vzdump.cron
# cluster wide vzdump cron schedule
# Automatically generated file - do not edit

PATH="/usr/sbin:/usr/bin:/sbin:/bin"

45 0 * * 7           root vzdump 100 116 130 131 132 126 --mode snapshot --prune-backups 'HASH(0x55e4ca7691e0)' --mailnotification failure --mailto root@mydomain --storage filer-1-images --quiet 1 --compress zstd
30 0 * * 6           root vzdump 105 106 101 --mailto root@mydomain --mailnotification failure --storage trendy-images --quiet 1 --compress zstd --mode snapshot --prune-backups 'HASH(0x55e4ca7914b0)'
30 0 * * *           root vzdump 107 --storage filer-1-images --mailnotification failure --mailto root@mydomain --compress zstd --quiet 1 --mode snapshot --prune-backups 'HASH(0x55e4ca7dac00)'
30 2 * * 6           root vzdump 122 127 --compress zstd --quiet 1 --storage trendy-images --mailto root@mydomain --mailnotification failure --prune-backups 'HASH(0x5610c5811800)' --mode snapshot
0 0 * * 6           root vzdump 117 --storage trendy-images --mailnotification failure --mailto root@mydomain --compress zstd --quiet 1 --mode snapshot
0 4 * * *           root vzdump 124 --mode snapshot --compress zstd --quiet 1 --storage filer-1-images --mailnotification failure --mailto root@mydomain
 
can you try removing that --prune-backups part from the first entry?
 
What was the reason for that? The other entries still have that "HASH" stuff and won't run upon schedule..
 
ah sorry, I missed that the others also have it but sorted differently. please remove them from all the entries! they should not return with the current version when editing the jobs..
 
  • Like
Reactions: jazzl0ver
We can't update a backupjob with option -maxfiles 3 or -prune-backups keep-last=3 using the API. The system return:
error during cfs-locked 'file-vzdump_cron' operation: value without key, but schema does not define a default key

How to fix it? This is some bug, we can't work.

pve-manager/6.3-3/eee5f901 (running kernel: 5.4.41-1-pve)
 
-prune-backups keep-last=3 this option work for vzdump, but does not work for backup job. Why? How to set a backup limit?
 
please include your version (pveversion -v), and which command/API call/GUI action you are doing EXACTLY
 
root@nl-518:~# pveversion -v
proxmox-ve: 6.3-1 (running kernel: 5.4.41-1-pve)
pve-manager: 6.3-3 (running version: 6.3-3/eee5f901)
pve-kernel-5.4: 6.3-3
pve-kernel-helper: 6.3-3
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.4.73-1-pve: 5.4.73-1
pve-kernel-5.4.41-1-pve: 5.4.41-1
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.18-2-pve: 5.3.18-2
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.0-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.7
libproxmox-backup-qemu0: 1.0.2-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-3
libpve-guest-common-perl: 3.1-4
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-6
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.8-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-5
pve-cluster: 6.2-1
pve-container: 3.3-3
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.1-3
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.1.0-8
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-5
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 0.8.5-pve1

API call
 
Example
pvesh set /cluster/backup/7a53d4455a95556981da13e2e1836f4595fffcff:5 -starttime 0:0 -all 0 -bwlimit 50000 -dow sat -enabled 1 -ionice 8 -lockwait 60 -prune-backups keep-last=3 -vmid 14766
 
fixed in libpve-guest-common-perl 3.1-5, please upgrade to that (not yet available in pve-enterprise)..
 
  • Like
Reactions: Andrii.B
done now - sorry for the long wait!
 
sorry.. took another look, and this also requires pve-manager >= 6.3-4 to be fully fixed, and that is held up in the qemu 5.2 migration at the moment..
 
You must log in or register to reply here.
Top Bottom