Schwierigkeit nach Neuinstallation

O

ollibraun

Member
Jan 28, 2023
64
16
13
Hallo,

ich experimentiere mit dem PBS (und bin im Test-Zweig auf 4.0.21, also ein Experimentiergerät). Versuchsweise habe ich den PBS neu aufgesetzt und den vorhandenen Datastore (Wasabi S3) neu eingebunden. Unter "Content" im Datastore werden mir die alten Backups auch angezeigt.

Allerdings funktionieren neue Backups nicht mehr, immer mit solchen Fehlern, und gleich am Anfang des Jobs (eine VM mit 20GB-HD):

ERROR: VM 115 qmp command 'backup' failed - backup connect failed: command error: mkstemp "/run/proxmox-backup/active-operations/Wasabi-Datastore.tmp_XXXXXX" failed: ENOSPC: No space left on device

Liegt das eher an der aktuellen Testversion, oder habe ich etwas falsch gemacht im Zusammenspiel? Ich habe den Backup-Job im PVE schon neu angelegt, jedoch ist die Anzeige im Storage auf dem PVE recht hakelig, ich muss immer mal den PBS neu starten, habe ich das gefühl.

Kein Speicher? Auf dem S3 oder auf dem PVE oder auf dem PBS?

PBS:

df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 390M 928K 389M 1% /run
/dev/mapper/pbs-root 39G 9.5G 28G 26% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
efivarfs 256K 92K 160K 37% /sys/firmware/efi/efivars
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service
tmpfs 2.0G 0 2.0G 0% /tmp
/dev/sda2 511M 8.8M 503M 2% /boot/efi
tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service
tmpfs 390M 4.0K 390M 1% /run/user/0

Ich weiß gerade nicht, aus welcher Ecke der Fehler kommt... der PBS ist genauso dimensioniert wie vorher, und da liefen die Backups durch.

1763909580118.png

PBS

cat datastore.cfg
datastore: Wasabi-Datastore
backend bucket=proxmox-backup-server,client=Wasabi-SE,type=s3
comment
gc-schedule 15:30
notification-mode notification-system
path /var/lib/proxmox-backup/local-cache/mein-wasabi/

PVE

cat storage.cfg
pbs: Ollis_PBS
datastore Wasabi-Datastore
server 192.168.10.50
content backup
fingerprint b3:...
prune-backups keep-all=1
username root@pam

Viele Grüße
Oliver
 
Vielen Dank, Chris, und das wurde wohl schon behoben in 4.0.22.

Allerdings läuft bei mir die Garbage Collection scheinbar ins Leere; das Log endet in diesem Status:

1764056162984.png
1764056207846.png
Unteres Bild: Ich habe zwischendurch den PBS neu gestartet und dann die GC erneut ausgeführt.
 
BItte output von mount und df -i posten während die GC scheinbar hängt. Wie viele chunks sind den im chunk store vorhanden (find <datastore-path>.chunks/ -type f -print | wc -l)?
 
Einmal mehr vielen Dank für die schnelle Reaktion! Ich vermute inzwischen, dass der Job einfach noch läuft...?

Code: 
root@pbs:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1948324k,nr_inodes=487081,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=600,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=398908k,mode=755,inode64)
/dev/mapper/pbs-root on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
none on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=6577)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,nosuid,nodev,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/credentials/systemd-journald.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/proxmox-backup type tmpfs (rw,nosuid,nodev,noexec,relatime,nr_inodes=0,mode=755,uid=34,gid=34,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=1994540k,nr_inodes=1048576,inode64)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=398904k,nr_inodes=99726,mode=700,inode64)
tmpfs on /run/credentials/getty@tty1.service type tmpfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,size=1024k,nr_inodes=1024,mode=700,inode64,noswap)

Code: 
root@pbs:~# df -i
Filesystem            Inodes  IUsed   IFree IUse% Mounted on
udev                  487081    503  486578    1% /dev
tmpfs                 498634    751  497883    1% /run
/dev/mapper/pbs-root 2596864 667319 1929545   26% /
tmpfs                 498634      1  498633    1% /dev/shm
efivarfs                   0      0       0     - /sys/firmware/efi/efivars
tmpfs                 498634      3  498631    1% /run/lock
tmpfs                   1024      1    1023    1% /run/credentials/systemd-journald.service
tmpfs                      0      0       0     - /run/proxmox-backup
tmpfs                1048576      9 1048567    1% /tmp
/dev/sda2                  0      0       0     - /boot/efi
tmpfs                  99726     26   99700    1% /run/user/0
tmpfs                   1024      1    1023    1% /run/credentials/getty@tty1.service

Code: 
find /var/lib/proxmox-backup/local-cache/.chunks/ -type f -print | wc -l
536739
 
Last edited:
in phase2 gibt es derzeit keine fortschrittsanzeige, sie kann allerdings eine weile dauern:

- es werden (in batches von 1000 objekten) alle chunks auf dem S3 storage gelisted
- fuer jeden dieser chunks wird geschaut ob es lokal einen marker gibt, und falls ja, ob der chunk garbage ist oder nicht
- jeder garbage chunk wird lokal entfernt
- garbage chunks werden (wiederum gebatched) auf S3 seite geloescht
 
Hallo Fabian, vielen Dank für die Erklärung. Ich hatte das die letzte Nacht durchlaufen lassen, ohne dass die Aufgabe fertig wurde, habe aber inzwischen bei Wasabi eine Löschung im Cockpit gesehen (roter Balken):

1764064667332.png

Also wird wohl aufgeräumt. :)
 
ich nehme an es gibt auf wasabi seite keine genaueren logs? die GC sollte einen halbwegs konstanten stream an listobjects und (falls garbage vorhanden ist) delete calls ausloesen..
 
You must log in or register to reply here.
Top Bottom