Hi,
That was a beginner mistake.
Real root cause (found 2026-05-06): discard=on was missing from scsi1 in the QEMU config. For over a year, every ext4 TRIM was silently dropped by QEMU and never propagated down to Ceph → 2.7 TiB of orphaned RBD...
Thank you for the output!
The pool can perform well, but the affected VM image itself is slow. That is the important distinction. For the recreate, I would a temporary second RBD storage ID pointing to the same pool. That avoids direct manual...
We're pleased to announce the release of Proxmox Backup Server 4.2.
This version is based on Debian 13.4 ("Trixie"), uses Linux kernel 7.0 as the new stable default for improved hardware support, and comes with ZFS 2.4 for reliable...
Thank you for the output!
The `rbd bench` numbers are from a scratch image. That confirms the pool cluster can deliver high throughput, but it does not fully rule out an issue specific to the actual VM image object layout. We recently had a case...
Thank you for the test!
Could you please run the following read-only benchmarks on the same RBD image used for VM 701?
rbd bench --io-type read --io-size 64K --io-threads 1 --io-total 1G pool_nvme_vm/vm-701-disk-0
rbd bench --io-type read...
Thank you for the test and the output!
At this point, this looks more like the Ceph RBD access path on the PVE side than a generic PBS side issue. Before going deeper into tracing, could you please test one non-critical ceph backend VM with...
Hi,
Thank you for the output!
Could you please share the output of `pveversion -v` from Proxmox VE and the output of `proxmox-backup-manager versions --verbose` from the Proxmox Backup Server, and the storage config i.e., `/etc/pve/storage.cfg`...