Search results

I should have been more specific - we do not support "incremental restore" on top of an already restored guest, for the same reason. It is a bit of a similar issue like persistant bitmaps - the blockage is not so much technical (the hurdles there can be overcome), but the associated risk of data...

"continuous restore" is not implemented. one issue with it is that it can (silently!) break if something/someone modifies the disk that has been restored inbetween restore runs, unless you re-verify it which is very expensive.

you have other weird errors in your logs as well.. please double check the full journal for possible causes.

https://bugzilla.proxmox.com/show_bug.cgi?id=7305 - thanks!

could you file an issue on bugzilla.proxmox.com and include the commands to reproduce and their output? thanks!

"burning" previously used IDs is what the referenced patch series is about, so if you want that semantics, somebody needs to pick it up and drive it over the finish line, like I wrote above. yes, reuse in the context of backup/restore is the most common issue (but not the only one, so to avoid...

we've had plenty of discussions about this. we have no plans at the moment to switch the used IDs to a non-human-readable one, and there are already two IDs in the VM config that identify the VM and are generated on creation and re-generated at various life cycle points: - smbios1 uuid - vmgenid...

I don't know of any plans to pick up that particular patch series on our end, but we'd be happy to review if somebody else wants to drive it across the finish line. I think for your particular use case, you could use a tuple of (smbios uuid, vmid) as identifier, or use "different smbiod uuid"...

I haven't seen any announcement, but I also haven't followed developments too closely.. maybe @fiona knows more?

as far as I can tell, there was never a new version of the patch series after the last round of reviews..

I am not sure if Grub supports LVM RAID, it's not used by the PVE installer and thus not tested by us. you can probably switch to using proxmox-boot-tool, which will put Grub (or systemd-boot) and the kernel + initrd on the ESP, and thus no longer require Grub to be able to access the root file...

1. please use code tags to post logs or config files.. 2. this is a bug that was fixed already, you need to upgrade PVE 8.x to a later version for it to be able to migrate to PVE 9.x

please provide the full task log and VM config. .sometimes there are bugs affecting migration compatibility. in general we try hard to make old->new and new->new work, new->old isn't always possible to support.

das ist ein problem auf Debian seite - fuer security updates werden die changelogs erst mit dem naechsten point release sichtbar. https://lists.debian.org/debian-security-announce/2026/msg00022.html

jein. der cache dient hautpsaechlich dazu, gewisse operationen schneller zu machen. beim backup wird schon (asynchron) auf den S3 storage gewartet - ein chunk/index/.. gilt erst als geschrieben wenn er im cache und im S3 abgelegt ist.

thanks! that seems very odd. can you run a zpool scrub using one of the kernel versions that boot?

the package in question hasn't been bumped yet, once it is the referenced bug will be updated. yes, the overload might very well be on the storage level. the log indicates that both pvestatd and the ha loops/cycles take way too long.

this part is already implemented on the PVE side, the VNETs are part of the ACL tree..

der "lokale" benchmark auf hetzner seite ist schon recht schlecht (der benchmark interagiert gar nicht mit dem storage, er testet nur den upload throughput!). vermutlich wirds in kombination mit der geringen bandbreite zwischen lokal und hetzner nicht besser - backup/restore/sync basieren auf...

check your reverse proxy and PVE access logs..