Is this the expected behavior for chunk lock files with an S3 backend? If so, is there any mechanism to clean them up periodically without having to restart the server?
the lockfiles not being cleaned up is intentional behavior to not run into races since the locking relies on flock() internally. But for these to consume so much space is definitely not intentional and we need to find a solution, so please open an issue for this at https://bugzilla.proxmox.com, referencing this thread.
As a workaround for the time being you could do one of the following:
Set the datastore to maintenance mode offline and mount a filesystem backed by a physical disk on top of /run/proxmox-backup/locks/<datastore>/.chunks/, making sure of the correct backup:backup ownership for files and directories on that path.
Periodically set the datastore into maintenance mode offline, once set, run rm -rf /run/proxmox-backup/locks/<datastore>/.chunks/* and then bring the datastore back online.
currently I'm running Proxmox Backup-Server 4.2.5 with production ready enterprise subscription on
Ugreen NAS DXP6800Pro
* 12 Core i5 CPU
* 8GB RAM (I know quiet less)
* 2x 1TB Samsung 990Pro NVMe SSD (50GB for ZFS root, 2nd unused NVMe only datastore)
* 4x 16TB Seagate Exos HDD
* there is a sync job to an OCI S3 Storage (with Archive)
* there is NO swap, which seems to be intentionally on ZFS root
The system died already 3x with OOM - which took a while to identify as systemd-journal was one of the first process to kill
claude-code created a logging script to watch io pressure, hdd temperature and slabcache and current proxmox-jobs (like verify, GC, sync, backup..) running.
After investigating this forum entry was found.
This steps where done
1. what is the current bugzilla report?
2. Should the cleanup done regulary, before the GC to an S3 storage is started?
3. it also recommended to add special vdevs to my hdd- ZFS pool - require first better understanding from my side.