Recent content by fabian

the snapshot volumes need to be active. could you describe which symptoms you are seeing exactly? the only time volumes are usually deactivated are - as part of error handling for freshly allocated volumes - as part of migration to another node if you are missing some deactivation when...

tracked at https://bugzilla.proxmox.com/show_bug.cgi?id=4853

which version are you running on the PBS server? this should be fixed with proxmox-backup-server >= 4.0.17-1

that's not 100% correct - there's two ways chunks can be detected as duplicate, either by the client or by the server. when creating a backup, the client only knows about the chunks referenced by the previous snapshot in the same group, and can therefor only deduplicate against those. in the...

flushing just means that those writes are not done sync (which is faster) so there is a backlog of them that still needs to be written out. for bulk data like this this is the best way to do it normally, I don't think the async-ness is the cause of your slowness here, rather the huge backlog is...

that sounds like flushing the pending writes at the end..

could you try without sync? but still, those numbers don't look super good..

sorry, I didn't read the log closely enough! could you try benchmarking the performance of an LV on your LVM storage (directly on the host) and then of a volume allocated to a VM from within the VM? keep in mind that a clone will incur a double network penalty, as it has to read from the...

and the synology?

possibly a regression caused by https://git.proxmox.com/?p=qemu-server.git;a=commitdiff;h=528df523161aa424cc6dca69230eae1f9a503cef @fiona ?

the whole clone took 1,5h? that's around 500mbit/s of throughput, depending on your network setup that might just be the bottle neck.. how is the connectivity to both storages?

seems like the patch got into 6.17 and 6.16.9, so it should be included in our kernels one way or another soon.

you can switch to chrony..

we haven't yet managed to reproduce this issue in our test lab (as far as I know), and the feedback regarding the patch was not 100% good, so we need more testing. if you are on 9.x, you can also try the 6.17 opt in kernel.

the built-in file restore can only recover what is (easily) readable in a linux VM using the vanilla ntfs3 driver from the linux kernel. anything else requires a windows VM, which needs to be done manually.