Die congenio setzt Proxmox ein, sowohl das Proxmox Virtual Environment (PVE), als auch den Proxmox Backup Server (PBS). Wir haben hier einige Praxistipps zusammengefasst, die sich in der täglichen Arbeit als hilfreich erwiesen haben. Ein Tipp: Diese Anleitung ausdrucken - später steht sie nicht live zur Verfügung! Die erste Frage ist die nach der Partitionierung für PVE. Zunächst gehen wir davon aus, dass das Basissystem auf einer (oder mehreren gespiegelten) NVME-SSDs installiert wird. Unabhängig davon kann zusätzliche Storage auf normalen HDDs angelegt werden, diese sollte vorzugsweise als RAID10, nicht als RAID5 oder RAID6 (oder deren ZFS-Äquivalenten raid-z1 bzw. raid-z2) angelegt werden, außer, wenn die Performance eine untergeordnete Rolle spielt. Bei der Auswahl der SSDs ist darauf zu achten, dass diese eine vernünftige TBW aufweisen. Überlegungen zu ZFS als Basis-Storage für Proxmox:

• ZFS als Dateisystem ist prinzipiell vorteilhaft, wegen Kompression, Verschlüsselung und Checksumming ABER:
• Swap auf ZFS ist problematisch, weil beim Auslagern eventuell mehr Speicher angefordert wird, was zu einem Deadlock führen kann. Lösung: Bei der Installation nicht den ganzen Platz für das ZFS allozieren, später Swap-Parition anlegen.
• Snapshots auf ZFS funktionieren nur "linear", d.h. ein Zurücksetzen auf einen anderen als den letzten Snapshot ist unmöglich. Um also auf den vorletzten Snaptshot zurückzusetzen, müsste man den letzten zuerst löschen. Somit sind insbesondere automatische Snapshots wie cv4pve-autosnap nur bedingt nutzbar. Es wird zwar oft behauptet, man kann die Snapshots klonen, aber das ist recht komplex. Eine (Teil-)Lösung kann sein, dass man /rpool/data als Directory-Storage anlegt, damit man dort QCOW2-Images anlegen kann, die nicht-lineare Snapshots erlauben. Hier gibt es wieder mehrere ABER:
• LXCs können nur RAW-Images verwenden, keine QCOW2. Legt man diese auf einem beliebigen Directory-Storage (nicht: ZFS-Pool als Volume) an, kann man aber nicht snapshotten (Directory-Storage kann selbst keine Snapshots, nur wenn die Dateien als QCOW2 angelegt werden, geht das). Somit sollten die LXCs weiterhin auf "local-zfs" angelegt werden, können dann aber keine nicht-linearen Snapshots.
• Cloudinit-Disks kann man zwar als QCOW2 anlegen, aber nicht umformatieren. Lösung: Machine herunterfahren, Cloudinit-Disk entfernen, sofort wieder hinzufügen und dann unter Cloud-Init neu generieren.
• TPM-State Disks funktionieren nur RAW, nicht als QCOW2. Entweder muss man sie entfernen oder damit leben, dass damit ausgestattete VMs nicht gesnapshottet werden können.

Also ist LVM-Thin als Default keine ganz dumme Idee, denn dort funktionieren Snapshots auch nicht-linear. Allerdings gibt es dann kein Checksummung - stellt sich natürlich die Frage, ob das bei VMs relevant ist. Man könnte auch einen Teil des Datenträgers für LVM reservieren, um dort ein local-lvm einzurichten - anders wüssten wir nicht, wie man für LXCs nicht-lineare Snapshots ermöglichen sollte. Snapshotting unterliegt aber ohnehin gewissen Beschränkungen (z.B. wenn Devices oder Ressourcen durchgereicht werden). Es gibt anders als bei Backups auch nicht die Möglichkeit, Disks vom Snapshot auszuschließen. Von Beginn an genug Swap auf dem PVE-Host einplanen. Diesen bei der PVE-Installstion zunächst nicht belegen und später eine Swap-Partition von Hand einrichten. Grund: Swap-Partitionen sind ein Problem bei etwaiger Vergrößerung von Disks. Man sollte sie, wenn, "vorne" auf der Disk anlegen. Besser: Mit LVM einrichten. Noch besser: Separate Disk mit Swap-Partition und Mount als UUID mit "nofail" und ohne Backup, dann belegt es keinen Platz in Backups. Außerdem: /etc/sysctl.conf mit "vm.swappiness = 10" überall. Beste Alternative: Gar kein Swap auf den VMs und genug Speicher zuweisen (Ballooning wird es richten). Man sollte folgende wichtige Pakete nachinstallieren:

• Microcode-Pakete
• Screen, um lang laufende Jobs zu starten und zu überwachen

• Root SSH Keys aufspielen
• Autosnapshots für rpool richtig setzen Grundsätzlich muss man mit dem Paket zfs-auto-snapshot aufpassen: Für rpool/data sollte man das z.B. nicht einschalten, sondern stattdessen das Paket cv4pve-snapshot einsetzen. Es ist aber sinnvoll für Root.
• CV4PVE-Snapshot einrichten
• Es gibt ein After-Installation-Skript von Bashclub für PVE, das - bis auf den Auto-Snapshot, ganz sinnvoll ist. Insbesondere richtet es einen Spiegel für /etc/pve unter /rpool/pveconf ein, der gesnapshottet wird, außerdem sorgt es über einen Cronjob dafür, dass das virtio-ISO immer aktuell gehalten wird.
• Swap einrichten (Vorsicht!): fdisk /dev/nvme1n1 <<EOF1 n 4 t 4 19 w EOF1 mkswap /dev/nvme1n1p4 && echo "/dev/nvme1n1p4 none swap sw,nofail 0 0" >>/etc/fstab swapon -a cat >/etc/sysctl.d/99-swap.conf <<EOF2 # Swap vm.swappiness = 10 # Dirty ratio vm.dirty_ratio = 5 EOF2
• Backup /etc/pve einrichten
• Einrichtung des Community-Repositories.  Warnung zum Community-Repository entfernen und Updates ermöglichen: rm /etc/apt/sources.list.d/pve-enterprise.list echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list apt update apt upgrade echo 'sed -Ezi.bak "s/(Ext.Msg.show\(\{\s+title: gettext\('No valid sub)/void\(\{ \/\/\1/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service' >/root/no-sub-script.sh chmod +x /root/no-sub-script.sh echo 'DPkg::Post-Invoke {"sh /root/no-sub-script.sh"};' > /etc/apt/apt.conf.d/99-no-sub-script apt --reinstall install proxmox-widget-toolkit
• Samba und NFS inlusive Zugriff auf ZFS-Snapshots
• VLANs / Netzwerk-Bridges

Das Backup-Storage wird normalerweise auf HDDs eingerichtet und als Zpool angelegt, z.B.: zpool create tank mirror \ /dev/disk/by-id/ata-WDC_WUH721818ALE6L4_3RG84J81 \ /dev/disk/by-id/ata-WDC_WUH721818ALE6L4_3RG84J82 zfs create tank/backup -o mountpoint=/backup zfs set com.sun.auto-snapshot=false tank/backup Wir lassen den PBS oft als VM laufen, obwohl eine physische Maschine auch hilfreich ist. Es gibt prinzipiell die Möglichkeit, PBS zusammen mit PVE in drei Varianten zu betreiben:

1. Als Side-by-Side-Installation zu PVE durch Installation des Pakets "proxmox-backup-server". Der Port, auf dem der PBS lauscht, ist 8007, also funktioniert das ohne Probleme. Man kann dann auch den Datastore direkt lokal anlegen, was eine optimale Ausnutzung des Platzes gewährt. Es findet aber keine logische Trennung statt und man kann auch keine einfache Sicherung der Konfiguration machen.
2. Als LXC-Container. Der Vorteil liegt darin, dass durch Einrichten eines Mountpoints auf die lokale Backup-Storage eine guten Ausnutzung des Speicherplattes erfolgen kann. Allerdings verhindert diese Nicht-Standard-Konfiguration ein Snapshotting.
3. Als VM. Hierbei muss man sich entscheiden, ob der Datastore per NFS gemounted werden soll (langsam) oder eine separate virtuelle Disk (feste Allokation) genutzt wird. Theoretisch kann man zwar Snapshots anlegen, aber im Fall einer Datastore-Disk wäre das angesichts des Platzbedarfs wenig sinnvoll.

Wir verwenden normalerweise Variante 3 mit einer Datastore-Disk. Dabei sollte man das ZFS-Dateisystem "uncompressed" einrichten, da die zugrundeliegende Storage bereits komprimiert ist. Außerdem werden die Backups sowieso komprimiert. Sicherungsjobs sollte man gleich mit Namespaces einrichten, dann lassen sich später Sync-Jobs kreuz und quer machen. Man sollte separate Backup-User anlegen, damit die Clients nichts löschen können. Der zugehörige Datastore sollte, falls die Basis-Storage schon komprimierbares ZFS ist, nicht mehr komprimiert werden. qemu-guest-agent bzw. virtio ISO zur Überwachung der VM, außerdem Balooning-Treiber zur optimalen Nutzung des RAMs.

• Microcode-Updates werden nicht mehr benötigt.
• Swap vorzugsweise abschalten.
• Im Normalfall Netzwerk nicht statisch, sondern per DHCP konfigurieren.