Search results

This is a PVE with two VMs 80GB in size. I don't plan on running another local PBS for that. I am not even really keen on using fleecing, simply because I have not yet understood why it should be a problem and not a bug to begin with. Ahh, re-reding the fleecing docs, I know think I know where...

I mean, it is the QEMU guest agent service having the issue, so I would argue it is not a Windows issue, but a QEMU on Windows issue. Just like the high DB load issue with VirtIO is not Windows issue but a QEMU on Windows issue. Sure, that is why I am bringing it up here. My suspicion is the...

Gave it a try based on this. Still think that this is just a workaround and even 120s won't help. It even says: I don't think so, since my other PVE can backup just fine without fleecing. There is also basically no io pressure during that time, and the VM does not get unresponsive or anything...

How is that connected with QEMU guest agent not starting?

Ich würde cache deaktivieren. Bringt IMHO mit ZFS nix und ist ein kleines bis grosses Risiko.

WAN Which is what basically happens now already. I don't know how this would help the service being able to start. That is definitely not the case, but the Upload might be a bottleneck. First one I am doing already, second one is not really an option, since I don't want to take the...

Not sure if I can follow what you mean. PBS is not slow, but PVE there is. HPEproliant microserver gen 10 with two SSDs in mirror plus a very slow copper upload connection.

Yes, since the backup is at 01:00. I think that the system gets shut down for backup, boots up again and then for some reasons these two services won't start.

PS: Both errors are about a connection timeout (45s) to the service. And both services are not running, even thought the are in autostart mode.

Still suffering from this issue on 9.1.5 and 0.1.271. I am not sure if the Windows Server SQL problem is related or not. The DB load is pretty low (only real load is probably for backup dumps), but coincidently or not it is mostly the VM running the DB that is suffering from that issue. Found...

I would try another USB stick.

Ahh, so it is only there to know what it needs to backup, to get a backup from the shutdown state, without the changes that happened to the disk during the backup. So maybe on ZFS it would theoretically also be possible to create a snapshot and do a backup of that snapshot, while the VM is...

but apparently also in stop mode. As seen by my output logs from stop mode. Sure it might not get used or used in a differently way, but it seams like it at least gets created?

Watch out when doing PBS backups with that setting. If I remember correctly, PBS makes use of that. To get back to your initial question "How to reduce wear out" the correct answer IMHO would be: Don't worry! Others here recommended PLP drives, but in reality most workloads are perfectly fine...

That is what I thought, but I am not sure if this is entirely correct. In the logs you can see this, no matter if the VM was running or not, when using stop mode: INFO: scsi0: dirty-bitmap status: created new So there is some dirty-bitmap that gets created. How that is used? I have no idea and...

Someone else has to chime in. I simply assume it is not possible, since there is no option in the gui or cli or anything written in the docs about concurrent backups AFAIK. IO workers is, well about IO workers (webGUI shows me default of 16 for me), not about how many backup task can run...

Do you need to shutdown VMs to backup them with stop mode? Or is it needlessly loosing uptime by doing so? Here is how I used to think it works: I thought it does not matter if the VM is running or not. In both cases the VM will be shutdown, a complete backup taken, during that the VM will be...

AFAIK that is not possible. That is about IO workers, not about how many VMs are backed up simultaneously. Why would you want to do multiple backups at the same time anyway? If you have a performance bottleneck, running multiple backups at the same time would make it even worse.

Ist das immer noch RAIDZ1? Was bekommst du denn auf PVE direkt raus, wenn du PVE benchmarkst? Sowas in die Richtung: fio --ioengine=libaio --direct=1 --sync=1 --rw=write --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --time_based --name seq_read --filename=/path to pool

Like others already said, by default it reads everything. The money quote line is this one: 107: 2026-02-28 21:00:07 INFO: scsi0: dirty-bitmap status: created new Since the VM is not running and/or you have the stop backup mode, it can't make use of the dirty-bitmap and has to read the whole...