Backup Error - Exit Code 1

[t4x]

Hi zusammen,

ich verwende schon des längeren Proxmox und bin sehr begeistert. Des Öfteren habe ich kleine Fehler oder Probleme die ich bisher aber alle mit Hilfe älterer Threads lösen konnte. Diesmal komme ich allerdings nicht mehr weiter. Vielleicht könnt ihr mir helfen.

Ich habe einen LXC-Container (102) und eine VM (103). Seit vergangener Woche funktionieren die wöchentlichen Backups bei beiden nicht mehr.

Hier alle Info's zum Container. Vielleicht könnt ihr das bei Gelegenheit einmal ansehen und vielleicht fällt euch was auf?

Spoiler: pveversion -v

-bash: pveversion-v: command not found
root@pve:~# pveversion-v
-bash: pveversion-v: command not found
root@pve:~# pveversion -v
proxmox-ve: 5.4-1 (running kernel: 4.15.18-14-pve)
pve-manager: 5.4-6 (running version: 5.4-6/aa7856c5)
pve-kernel-4.15: 5.4-2
pve-kernel-4.15.18-14-pve: 4.15.18-39
pve-kernel-4.15.18-9-pve: 4.15.18-30
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-10
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-52
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-43
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-28
pve-cluster: 5.0-37
pve-container: 2.0-39
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-21
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-2
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-51
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.13-pve1~bpo2

Spoiler: pct config 102

arch: amd64
cores: 4
description: lxc.cgroup.devices.allow%3A c *%3A* rwm%0Alxc.mount.entry%3A /dev/bus/usb/001/003 dev/bus/usb/001/003 none bind,optional,create=file%0Alxc.aa_profile = lxc-container-default-with-mounting%0Alxc.mount.entry%3A /dev/serial dev/serial none bind,optional,create=file%0Alxc.mount.entry%3A /dev/serial/by-id dev/serial/by-id none bind,optional,create=file%0A
hostname: iobrokerdb8
memory: 2048
net0: name=eth0,bridge=vmbr0,gw=192.168.178.1,hwaddr=8A:B8:4A:3D:11:6C,ip=192.168.178.6/24,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-102-disk-0,size=16G
swap: 512
lxc.cgroup.devices.allow: c 189:* rwm
lxc.cgroup.devices.allow: c 166:* rwm
lxc.mount.entry: /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file
lxc.mount.entry: /dev/bus/usb/001/004 dev/bus/usb/001/004 none bind,optional,create=file

Spoiler: cat /etc/pve/storage.cfg

dir: local
path /var/lib/vz
content iso,vztmpl,backup
maxfiles 10
shared 0

lvmthin: local-lvm
thinpool data
vgname pve
content rootdir,images

nfs: synology_nfs
export /volume1/backups
path /mnt/pve/synology_nfs
server 192.168.178.5
content backup,images,rootdir,iso
maxfiles 20
options vers=3

Spoiler: cat /etc/vzdump.conf

# vzdump default settings

#tmpdir: DIR
#dumpdir: DIR
#storage: STORAGE_ID
#mode: snapshot|suspend|stop
#bwlimit: KBPS
#ionice: PRI
#lockwait: MINUTES
#stopwait: MINUTES
#size: MB
#stdexcludes: BOOLEAN
#mailto: ADDRESSLIST
#maxfiles: N
#script: FILENAME
#exclude-path: PATHLIST
#pigz: N

Und hier das Problem:

Spoiler: vzdump

INFO: starting new backup job: vzdump 102 --storage synology_nfs --compress lzo --remove 0 --node pve --mode snapshot
INFO: Starting Backup of VM 102 (lxc)
INFO: Backup started at 2020-03-30 15:39:10
INFO: status = running
INFO: CT Name: iobrokerdb8
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
Using default stripesize 64.00 KiB.
Logical volume "snap_vm-102-disk-0_vzdump" created.
INFO: creating archive '/mnt/pve/synology_nfs/dump/vzdump-lxc-102-2020_03_30-15_39_10.tar.lzo'
INFO: tar: ./opt/iobroker/iobroker-data/backup-objects/2020-03-27_22-36_objects.json.gz: File shrank by 599095 bytes; padding with zeros
INFO: Total bytes written: 2301675520 (2.2GiB, 3.2MiB/s)
INFO: remove vzdump snapshot
Logical volume "snap_vm-102-disk-0_vzdump" successfully removed
ERROR: Backup of VM 102 failed - command 'set -o pipefail && tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/synology_nfs/dump/vzdump-lxc-102-2020_03_30-15_39_10.tmp' ./etc/vzdump/pct.conf '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | lzop >/mnt/pve/synology_nfs/dump/vzdump-lxc-102-2020_03_30-15_39_10.tar.dat' failed: exit code 1
INFO: Failed at 2020-03-30 15:50:59
INFO: Backup job finished with errors

TASK ERROR: job errors

Vielen Dank und Beste Grüße,
Martin

 

[fabian]

tritt das immer beim selben file auf?

 

[t4x]

Hier mal noch der Fehler im Backup der VM (103)

Spoiler: backup vm

INFO: starting new backup job: vzdump 103 --remove 0 --compress lzo --storage synology_nfs --mode snapshot --node pve
INFO: Starting Backup of VM 103 (qemu)
INFO: Backup started at 2020-03-31 06:57:42
INFO: status = running
INFO: update VM 103: -lock backup
INFO: VM Name: conbee
INFO: include disk 'scsi0' 'local-lvm:vm-103-disk-0' 16G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating archive '/mnt/pve/synology_nfs/dump/vzdump-qemu-103-2020_03_31-06_57_42.vma.lzo'
INFO: started backup task '7701f3c5-0288-46fc-900f-b4d6178bf6db'
INFO: status: 0% (52822016/17179869184), sparse 0% (37412864), duration 3, read/write 17/5 MB/s
INFO: status: 1% (179568640/17179869184), sparse 0% (98267136), duration 8, read/write 25/13 MB/s
INFO: status: 2% (360775680/17179869184), sparse 0% (98267136), duration 24, read/write 11/11 MB/s
INFO: status: 3% (516947968/17179869184), sparse 0% (102461440), duration 36, read/write 13/12 MB/s
INFO: status: 4% (701693952/17179869184), sparse 0% (106684416), duration 51, read/write 12/12 MB/s
INFO: status: 5% (862846976/17179869184), sparse 0% (108965888), duration 60, read/write 17/17 MB/s
INFO: status: 6% (1041498112/17179869184), sparse 0% (133062656), duration 72, read/write 14/12 MB/s
INFO: status: 7% (1220149248/17179869184), sparse 1% (199790592), duration 82, read/write 17/11 MB/s
INFO: status: 8% (1381761024/17179869184), sparse 1% (236843008), duration 91, read/write 17/13 MB/s
INFO: status: 9% (1559101440/17179869184), sparse 1% (271355904), duration 103, read/write 14/11 MB/s
INFO: status: 12% (2082996224/17179869184), sparse 3% (661139456), duration 116, read/write 40/10 MB/s
INFO: status: 13% (2254045184/17179869184), sparse 4% (783880192), duration 121, read/write 34/9 MB/s
INFO: status: 16% (2898264064/17179869184), sparse 7% (1323835392), duration 129, read/write 80/13 MB/s
INFO: status: 17% (2949644288/17179869184), sparse 7% (1323835392), duration 132, read/write 17/17 MB/s
INFO: status: 18% (3096051712/17179869184), sparse 7% (1324617728), duration 142, read/write 14/14 MB/s
INFO: status: 19% (3265134592/17179869184), sparse 7% (1326796800), duration 152, read/write 16/16 MB/s
INFO: status: 20% (3435986944/17179869184), sparse 7% (1341624320), duration 163, read/write 15/14 MB/s
INFO: status: 20% (3486908416/17179869184), sparse 7% (1341624320), duration 170, read/write 7/7 MB/s
ERROR: job failed with err -61 - No data available
INFO: aborting backup job
ERROR: Backup of VM 103 failed - job failed with err -61 - No data available
INFO: Failed at 2020-03-31 07:00:39
INFO: Backup job finished with errors
TASK ERROR: job errors

Was meinst du mit dem gleichen file? Das backup-file hat ja einen Zeitstempel.

 

[fabian]

Im ersten Log war es ein bestimmes File aus dem Container das als Fehlerursache aufschien:
INFO: tar: ./opt/iobroker/iobroker-data/backup-objects/2020-03-27_22-36_objects.json.gz: File shrank by 599095 bytes; padding with zeros

jetzt im zweiten Log ist es eine VM, das heißt der Backupmechanismus ist ein ganz anderer, der Fehler aber in gewisser Weise ähnlich. deutet in den Logs (Host oder Gäste) irgendetwas darauf hin, dass der local-lvm Storage Probleme hat? laufen die Gäste ansonsten stabil? was sagt pvs, lvs ?

Ein Upgrade auf die neueste 5.x Version würde sicher auch nicht schaden (und dann in weiterer Folge, wenn das Problem behoben ist auf 6.x - 5.x geht in Bälde EOL!)

 

[t4x]

Ich hatte das nicht als Fehler interpretiert. Aber ja, es ist immer die gleiche Datei.

INFO: tar: ./opt/iobroker/iobroker-data/backup-objects/2020-03-27_22-36_objects.json.gz: File shrank by 599095 bytes; padding with zeros

Genau, das zweite ist eine VM die seit dem gleichen Zeitraum ebenfalls nicht mehr funktioniert. Das wäre aber der nächste Step. Wichtiger wäre mir vorerst der Container 102.

pvs und lvs:

root@pve:/# pvs
  PV         VG  Fmt  Attr PSize   PFree
  /dev/sda3  pve lvm2 a--  232.35g 15.96g
root@pve:/# lvs
  LV            VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve twi-aotz-- 151.30g             5.40   0.31                          
  data_meta0    pve -wi-a-----   1.55g                                                  
  root          pve -wi-ao----  58.00g                                                  
  swap          pve -wi-ao----   4.00g                                                  
  vm-102-disk-0 pve Vwi-aotz--  16.00g data        24.59                                
  vm-103-disk-0 pve Vwi-aotz--  16.00g data        26.60                                
root@pve:/#

Im PVE unter LVM finde ich folgende Info. Da wird mir angezeigt, dass meine Gruppe fast voll ist. Ist das normal?


Mein local-lvm sieht aber eigentlich gut aus:


Soll ich dann vorerst mal ein Update auf 5.x machen?

 

[t4x]

Ein kleines Update dazu.
Ich habe ein apt-get update und ein apt-get dist-upgrade durchgeführt. Anschließend war das File-System schief. Ich musste dann an den Server um das zu fixen. Hat aber soweit funktioniert.

Anschließend habe ich die genannte Datei von Fabian gelöscht. Das war eine ältere Sicherungsdatei von meiner Smart-Home Lösung. Daraufhin war das Backup-Problem gelöst! Ich konnte wieder ein Backup des Containers machen.

Das Problem mit dem Backup der VM besteht weiterhin - hierzu würde ich aber bei Bedarf einen neuen Thread aufmachen. Dazu gehe ich mal noch mehr auf Suche. Vielleicht hat es damit zutun, dass mein physical Volume als fast voll angezeigt wird.


Danke an Fabian!

Gruß,
Martin