Recent content by fabian

https://docs.ceph.com/en/latest/cephfs/administration/#settings

it is, but only up to the test repositories.

one last thing to try, although it seems unlikely based on your benchmark numbers, would be to retry the test with an unencrypted backup (you can use test data for this of course, instead of real production data).

you can try the pstore interface, a serial console or a netconsole to get the full log..

@monkfish: we only want one entry per issue, and usually re-use the older one (as it often already has some discussion, and the lower number also servers a signal for "this has been filed a while ago"). I've updated it while merging the two, so that it is now current once more. you also get...

yes, proxmox-backup-client/server >= 4.1.5 supports it, both sides need to be updated for it to work.

did you set up this path as *medium* and synced it? it looks like it might just be where you store your snapshots?

this is a kernel regression affecting these devices with some firmware versions: https://bugzilla.kernel.org/show_bug.cgi?id=220693 https://lore.kernel.org/all/176467086520.364377.182740446463637461.b4-ty@kernel.org/ the fix should come in via stable kernel updates, I'll see if we can expedite...

what is your backup target?

thanks! what if you run the same command on the PBS host?

you need proxmox-offline-mirror-helper >= 0.7.3 for that..

potentially interesting would be to try a restore using `proxmox-backup-client restore`, once to /dev/null (to just benchmark the retrieving part) and then to a zvol..

Verify speed: 1068.22 MB/s is a bit curious given the rest of the numbers.. but I guess this should be amortized when processing chunks in parallel. the TLS speed also looks better than your actual throughput. dd-ing /dev/zero is not a valid benchmark at all, in particular if you are using ZFS...

what does "proxmox-backup-client benchmark --repository <...>" say if you run it on one of the PVE hosts? at what speed does a single backup task peak? might be that the actual transfer over HTTP 2.0/TLS with a single TCP connection is your bottle neck

if you have access to the guest volumes in a format that Qemu understands (e.g., flat vmdk or plain raw) you can import those and try to recreate matching configs on the PVE side. it might take a bit of fiddling and guess work, depending on how your guests were set up on ESXI.