In my source.list the German version server has been configured during installation
deb http://ftp.de.debian.org/debian buster main contrib
deb http://ftp.de.debian.org/debian buster-updates main contrib
# security updates
deb http://security.debian.org buster/updates main contribapt clean && apt update there is still nothing to update
as described in the reference documentation I linked: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_package_repositories
deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_single_file_restore
Hmm, personally I'd not mind doing that, but as dev I'm a bit hesitant do to that for disks, as most vendors use GB (base 10) units on data sheets, so switching there from GB to GiB may seem to some like "Proxmox VE ate my space", as GiB is always lower - e.g., most 1 TB disks are ~ 931 GiB. I keep it in mind though.Since you switched from GB to GiB gauges with RAM, would you mind doing the same with disk usage?
Package upgrade is as safe as then, but yes, one should avoid enabling new zpool features when using GRUB to boot from a ZFS root pool. Also, from reading the thread it does not seem that your host got destroyed but that boot got temporarily broken - which was recoverable, you just decided to not do so as you had recent backups anyway. Surely, still a big hassle/PITA, but there was nothing destroyed by simply upgrading, and also no data destroyed by the zpool upgrade directly. I'm stating that just for the case that someone else reads this when experiencing a similar situation, so that they do not think something got destroyed permanently, such setups can be recovered, as my colleagues and other community member helped to do in the linked thread.
But the package update itself did not broke anything, and that is what we rolled out. The problematic zpool upgrade was not done by us, so please do not make it sound like that. If you're unsure how changes to the ZFS pool you boot from play out you can always ask here, as quite a few have done and were saved from such situations.
Why you don't use no-sub repo as default finally and remove all such questions once for all?
Because it is not production ready, so we setup the enterprise repository which is production ready.
that is a bug currently: https://bugzilla.proxmox.com/show_bug.cgi?id=3405
Lvm support would be very nice, any idea when that is approximately in the planning
That's a game changer for everyone using file storing services within VMs!
I already assumed that this is the reason.
Should work now with the proxmox-backup-file-restore 1.1.5-3, when XFS is mounted during backup it may refuse to mount on another system by default, so we had to configure specific mount options to tell it that's OK in the file-restore VM.
check the journal for messages from pveproxy after a reboot (`journalctl -b -u pveproxy`) - check `ss -tlnp|grep 8006` - if this does not solve the issue please open a new thread with the information from the journal and ss
$ journalctl -b -u pveproxy
-- Logs begin at Thu 2021-04-29 16:34:25 CEST, end at Thu 2021-04-29 17:49:01 CEST. --
Apr 29 16:34:44 srv001 systemd[1]: Starting PVE API Proxy Server...
Apr 29 16:34:45 srv001 pveproxy[2361]: Using '/etc/pve/local/pveproxy-ssl.pem' as certificate for the web interface.
Apr 29 16:34:45 srv001 pveproxy[2367]: starting server
Apr 29 16:34:45 srv001 pveproxy[2367]: starting 3 worker(s)
Apr 29 16:34:45 srv001 pveproxy[2367]: worker 2368 started
Apr 29 16:34:45 srv001 pveproxy[2367]: worker 2369 started
Apr 29 16:34:45 srv001 pveproxy[2367]: worker 2370 started
Apr 29 16:34:45 srv001 systemd[1]: Started PVE API Proxy Server.$ ss -tlnp|grep 8006
LISTEN 0 128 [::]:8006 [::]:* users:(("pveproxy worker",pid=2370,fd=6),("pveproxy worker",pid=2369,fd=6),("pveproxy worker",pid=2368,fd=6),("pveproxy",pid=2367,fd=6))