Ein paar irrelevante Tutorials

Proxmox Virtual Environment (PVE)

Hardware

Als Hardware dienen bei mir Mini-PCs. Das Wichtigste ist ein Prozessor, der Vitualisierung unterstützt und möglichst viel Arbeitsspeicher; je mehr, desto besser. Die PCs, die ich als Serverhardware nutze, sind jeweils mit zwei Netzwerkkarten ausgestattet, die an zwei unterschiedliche Switches angeschlossen sind, um Ausfallsicherheit zu gewährleisten. Natürlich kann man einen PVE auch mit nur einer Netzwerkkarte betreiben. Da intern in meinen Geräten keine zwei SSDs oder sogar NVMes installiert werden können, wird für die Basisinstallation auf ein RAID verzichtet.
 
An die PCs sind externe Festplatten per USB angeschlossen.

Basisinstallation

Zur Erstinstallation sind Monitor und Tastatur erforderlich. Später ist eine vollständige Administration und Wartung per Web-GUI und SSH möglich. 
 
Am Einfachsten ist die Installation mittels Bootmedium. Mehr Kontrolle über die Basiskonfiguration hätte man, wenn man den PVE auf einem Debian-Server installiert. Ich verwende das Bootmedium, welches zunächst von der Homepage https://www.proxmox.com/de/downloads/proxmox-virtual-environment/iso herunterzuladen und auf einen Stick zu kopieren ist. Das geht unter Linux mit verschiedenen Tools, z.B. usb-creator oder Ventoy. Um von diesem ISO-Installer zu booten, muss man den Stick einsetzen und beim Booten des Rechners ins Bootmenü gehen. Dazu drückt man die Tasten F2 oder ESC (je nach BIOS). 
 
Die Installation ist weitestgehend selbsterklärend. Man wählt das Ziellaufwerk aus (hier könnte man auch ein RAID anlegen, wenn man entsprechende Hardware im Rechner hat) und gibt einen Namen vor. Standardmäßig wird "PVE" vorgeschlagen. Wenn man mehrere Server betreiben möchte, sollte man das manuell ändern. Statt DHCP sollte man statische IP-Adressen auswählen. Das Bonding der Netzwerkkarten kann später erfolgen (s.unten).   Man wird noch nach einem Root-Passwort und einer eMail-Adresse gefragt. Die eMail-Adresse ist zunächst unwichtig. Das Passwort muss man sich aber natürlich merken. Mehr braucht man zunächst nicht vorzugeben. Nach der Basisinstallation kann man sich an der Web-GUI anmelden. Dazu ruft man die IP-Adresse des Servers mit https und dem Port 8086 auf. Die Sicherheitswarnung wegen des selbstsignierten Zertifikats kann man ignorieren.

Konfiguration

Proxmox-Repository anpassen

Per default ist das Enterprise-Repository aktiviert.  Wenn man keine Enterprise-Subscription erworben hat, dann kann man das nicht nutzen. Darauf wird man bei Anmeldung hingewiesen. So kann man keine Updates beziehen. Darum muss man das freie Repository auswählen. Auf der Weboberfläche des PVE-Knotens kann man unter "Updates" den Eintrag "Repositories" auswählen, die Enterprise Subscription deaktivieren und das Repository "pve-no-subscription" hinzufügen. Genauso verfährt man mit dem Ceph-Repository, wenn man es denn überhaupt braucht. Anschließend kann man über Updates/Aktualisieren das System auf den aktuellen Stand bringen. Dabei werden auch die Debian-Sourcen aktualisiert.

Netzwerkkarten bündeln

Beim Start wurde einer Netzwerkkarte die ausgewählte IP-Adresse zugewiesen. Die Bündelung der Netzwerkkarten zu einem ausfallsicheren Bond kann über die Weboberfläche vorgenommen werden. Vorher ist es keine schlechte Idee, die bisherige Konfiguration zu sichern. Das muss über die CLI gemacht werden. Man ruft über die Weboberfläche die Shell auf und meldet sich dort, falls erforderlich als root an. Dann setzt man den Befehl 
cp /etc/network/interfaces /etc/network/interfaces-bup
ab. So lässt sich eine eventuell fehlerhafte Änderung der Netzwerkkonfiguration durch den gleichen Befehl mit umgekehrten Parametern wieder rückgängig machen. Zunächst löscht man in der Web-GUI die vorhandenen Einträge der IP-Adressen und Gateways bei den Netzwerkkarten nur das Häkchen bei "Autostart", falls noch nicht gesetzt. Dann erstellt man neu ein Linux Bond. Unter Slaves trägt man die Namen der beiden Karten ein, die man bündeln möchte (Space spariert). Autostart ist auszuwählen und der Modus ist active-backup, um Ausfallsicherheit zu gewährleisten. Eine Karte wird noch als bond-primary ausgewählt. Die anderen Felder bleiben leer.

Bridge einrichten

Nun muss die virtuelle, gebündelte Netzwerkkarte noch mit einer Bridge verbunden werden, um im Netz erreichbar zu sein. Dazu erstellt man eine Linux-Bridge mit IP-Adresse inkl. Subnetzmaske (z.B. 192.168.0.102/24), aktiviert auch wieder Autostart und trägt als Bridge Port den Namen des og. Netzwerkbündels ein.
Wenn man nun auf "Konfiguration anwenden" klickt, dann wird die Datei "/etc/networking/interfaces geändert und die neue Netzwerkkonfiguration angewendet. Sollte dabei etwas schief gelaufen sein, dann kann man an der Konsole, also mittels an der Hardware anzuschießender Tastatur und Monitor diese Datei bearbeiten, um den Server wieder über das Netzwerk zu erreichen. Die Datei sollte folgendermaßen aufgebaut sein: 
auto lo
iface lo inet loopback

auto enp0s25
iface enp0s25 inet manual

auto enxa0cec88afd37
iface enxa0cec88afd37 inet manual

auto bond0
iface bond0 inet manual
       bond-slaves enp0s25 enxa0cec88afd37
       bond-miimon 100
       bond-mode active-backup
       bond-primary enp0s25

auto vmbr0
iface vmbr0 inet static
       address 192.168.88.100/24
       gateway 192.168.88.1
       bridge-ports bond0
       bridge-stp off
       bridge-fd 0

source /etc/network/interfaces.d/*
Den Gästen wird dann später eine virtuelle Netzwerkkarte mit der zuvor erstellen Bridge zugewiesen.

Storage hinzufügen

Unter [Rechenzentrum/Storage] werden die angebundenen Speicher angezeigt. Bei der Basisinstallation nicht genutzter Platz der Bootplatte(n) wird als "local-lvm" angezeigt. Dieser kann für Gäste genutzt werden. Weitere, an die Hardware angeschlossene Laufwerke (USB oder anderweitig) sind unter [Knotenname/Disks] aufgeführt. Wenn sie nicht als für das System verfügbar angezeigt werden, müssen sie zunächst formatiert werden (unter Disks/Disk formatieren). **Achtung: Wenn da schon Daten drauf sind, gehen die natürlich verloren!**
Danach können sie als LVM oder ZFS genutzt werden. ZFS bieten mehr Anwendungsmöglichkeiten, ist aber auch sehr speicherhungrig. Etwa die Hälfte des verfügbaren Arbeitsspeichers eines Proxmox-Hosts wird für ZFS verwendet. RAID-Level oder HA-Funktionalität kann man nur mit ZFS abbilden. 
ZFS
Ein neues ZFS erstellt man, indem man unter [Knotenname/Disks/ZFS] "Erstellen: ZFS" anklickt. Dann vergibt man einen eindeutigen Namen. Der sollte sich im Netzwerk möglichst noch nicht befinden und es wäre auch gut, wenn er nicht schon einmal früher verwendet worden wäre. Unter "Gerät" kann man die zu nutzenden Laufwerke auswählen. Für ein RAID1 werden mindestens 2 Laufwerke, für höhere RAID-Level entsprechend mehr benötigt. RAID1 wird als Mirror angeboten. Der Parameter "ashift" bestimmt die die Blockgröße der Daten, die auf dem ZFS-Pool gespeichert werden. Er kann wie vorgegeben übernommen werden. 
Unter Kompression ist "on" voreingestellt. Das kann man so lassen. Dann wird LZ4-Kompression angewendet, die ein gutes Verhältnis von Kompressionsrate, CPU-Hunger und Geschwindigkeit aufweist. Der Wert kann so belassen werden. Wenn man nun "erstellen" anklickt, dann wird das ZFS entsprechend angelegt und steht unter [Rechenzentrum/Storage] sowie für Gäste zur Verfügung.  
LVM
LVM steht für Logical Volume Manager. Hier können Logische Volumegroups eingerichtet werden. Dazu klickt man auf "Erstellen: Volume Group" und wählt die verfügbaren, noch nicht anderweitig genutzten Laufwerke aus. Man vergibt einen Namen und setzt (wenn nicht schon voreingestellt) das Häkchen "Storage hinzufügen. Wenn man nun "erstellen" anklickt, wird die Volume Group angelegt und steht unter [Rechenzentrum/Storage] zur Verfügung.

eMail-Benachrichtigungen einrichten

Damit der PVE (oder das Cluster) eMails senden kann, muss man zunächst die dazu erforderliche Software installieren und konfigurieren. Zunächst meldet man sich auf der Shell des Hosts als root an. Dann installiert man die benötigten Pakete 

apt install postfix libsasl2-modules -y

Dann muss man die Datei "/etc/postfix/main.cf" bearbeiten. 

nano /etc/postfix/main.cf

Dort kommentiert man die Zeichenkette "relayhost =" aus und fügt ein: 

relayhost = smtpserver:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_cert_file = /etc/pve/local/pve-ssl.pem
smtp_tls_key_file = /etc/pve/local/pve-ssl.key
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_security_level = may
sender_canonical_classes = envelope_sender, header_sender sender_canonical_maps = regexp:/etc/postfix/sender_canonical_maps smtp_header_checks = regexp:/etc/postfix/header_check

Danach muss man die Absenderadresse anpassen: 

nano /etc/postfix/sender_canonical_maps 

/.+/    proxmox@absender.koeln

zweimal: 

nano /etc/postfix/header_check 

/From:.*/ REPLACE From: proxmox@absender.koeln

Die Benutzerdaten sind gesichert zu hinterlegen: 

nano /etc/postfix/sasl_passwd 

accountname.smtpserver.com:587 {Username}:{Passwort}

und daraus eine gehashte Datenbankdatei zu erstellen: 

postmap /etc/postfix/sasl_passwd

Nun müssen die Zugriffsrechte angepasst werden: 

chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db 
chmod 0600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

und Postfix ein allgemeines Zertifikat zugewiesen werden: 

cat /etc/ssl/certs/ssl-cert-snakeoil.pem | tee -a /etc/postfix/cacert.pem

Danach ist der Postfixdienst neu zu starten: 

postfix reload

und die Absenderadresse in der Web-GUI unter "Datacenter/Options/Email from address" einzutragen. Danach kann man das wieder auf der Shell testen: 

echo "Proxmox SMTP Test" | mail -s "SMTP Test" mail@hanswurst.de -r proxmox@absender.koeln

Backups und Restore

Backup der Gäste

Unter Datacenter/Backup werden die Backup-Jobs verwaltet. Um einen neuen Backup-Job einzurichten, klickt man hier auf "Add". In dem sich hier öffnenden Dialog kann man zunächst auswählen, welche Gäste welcher Nodes gesichert werden sollen. Wenn man kein Cluster hat, dann ist es egal, ob man das voreingestellte "-- All --" stehen lässt oder den einzigen Knoten auswählt, den man hat. Der nächste Eintrag "Storage" ist schon interessanter. Voreingestellt ist hier "local". Man kann jeden Speicher auswählen, den man dem Knoten oder Cluster mit dem erlaubten Content "VZdump backup file" zugewiesen hat. Idealerweise nutzt man hier einen Proxmox Backup Server. Unter Schedule gibt man die Zeitplanung für die regelmäßigen Backups vor. Das ist selbsterklärend. Unter "Selection Mode" wählt man aus, ob die darunter ausgewählten VMs eingeschlossen oder ausgeschlossen werden sollen, ob alle VMs des Knotens oder Clusters eingeschlossen werden oder ob man Poolbasiert sichern möchte. VMs ist hier gleichbedeutend mit LXCs zu verstehen.

Unter "Notification mode" ist "auto" voreingestellt, was so bleiben kann. Unter "Send email to" kann man eine eMailadresse eingeben, an die Mails zu Erfolg oder Misserfolg von Sicherungen gesendet werden. Wenn man dort eine Adresse eingibt, dann kann man noch auswählen, ob jedes Mal eine Mail geschickt wird oder nur bei Misserfolg. Wichtig: Damit die email notification funktioniert muss der PVE (oder das Cluster) in der Lage sein, eMails zu senden (s. hier Abschnitt "eMail-Benachrichtigung einrichten").

Wenn man einen PBS nutzt, dann kann man den Reiter "Retention ignorieren, weil die Retention dort geregelt ist. Die Reiter "Note Template" und "Advanced" kann man ignorieren.

Restores durchführen

Restores kann man über die Web-GUI des PVE oder Clusters durchführen. Man wählt entweder den Gast aus und klickt auf "Backup". Um die Sicherungen, die nicht auf dem local Storage liegen, zu sehen, muss man das Auswahlfeld "Storage" bemühen und dort den verwendeten Storage, z.B. den PBS auswählen. Dann werden die verfügbaren Sicherungen angezeigt. Wenn man das Häkchen "Filter VMID" entfernt, dann werden auch die Sicherungen anderer Gäste angezeigt. Dabei werden für VMs immer nur die vorhandenen Sicherungen der VMs angezeigt und für LXCs die der LXCs. Das ist nicht ganz sinnfrei, denn ein Restore einer VM auf einen LXC oder umgekehrt dürfte nicht funktionieren. 

Ein anderer Weg, Restores zu starten, ist über den Backup-Storage, den man über die Web-GUI des Knotens oder Clusters direkt anspricht. Wenn man den Backup-Storage (z.B. PBS1) auswählt, dann hat man die Auswahlmöglichkeiten "Summary", "Backup" und "Permissions". Unter Backup werden alle verfügbaren Backups angezeigt. Wir können einfach ein Backup auswählen und einen Restore oder ein File Restore anstoßen. Auf diese Weise kann man auch einen Proxmox-Gast von einem PVE auf einen anderen umziehen (s.u.). 

Full restore

Wenn man eine Sicherung ausgewählt hat, dann kann man mit dem Button "Restore" einen kompletten Restore des Gastes auf einen früheren Sicherungsstand anstoßen. Dabei werden alle Daten gelöscht. Laufwerke, die vorher nicht vorhanden waren, werden eingebunden oder erstellt und Laufwerke, die vor der letzten Sicherung noch nicht vorhanden waren, werden abgeklemmt. Es könnte hier also nicht schaden, wenn man wüsste, was man tut. Bei einem kompletten Restore werden auch alle anderen Parameter des Gastes, also CPUs, RAM, Netzwerk usw. zurück gesetzt. 

File Restore

Wenn man nur einzelne Dateien wieder herstellen möchte, dann wählt man den Button "File Restore" aus. Es erscheint ein Dateiauswahldialog, in dem man einzelne Dateien oder Verzeichnisse zum Download auswählen kann. Der Download wird dann natürlich nicht auf den Gast, sondern über den Browser lokal durchgeführt.

Exkurs Umzug eines Servers

Man kann auf einem PVE einen Server recovern, der dort bisher gar nicht vorhanden war. Dazu muss auf dem PBS eine Sicherung des umzuziehenden Servers vorhanden sein. Auf dem Ziel-Knoten wählt man den Backup-Storage aus und stößt einen Full-Restore an. Es wird eine neue ID vorgeschlagen. Hier muss man darauf achten, dass es diese ID nicht schon einmal im Netz gab. Nach diesem Umzug muss man ggf. noch die Netzwerkparameter anpassen und dann kann man das umgezogene System auch schon hochfahren.

Backup des PVE

Um auch den PVE über den PBS sichern zu können, müssen zunächst auf dem PBS ein Sicherungs-User und ein API-Token erzeugt werden. Auf der Web-GUI des PBS unter "Access Control/User Management" wird zunächst ein neuer User angelegt. Hier kann man einen beliebigen (am besten sprechenden) Namen vergeben. Unter "Realm" ist vorausgewählt "Proxmox Backup authentication server", was übernommen werden muss. Dann vergibt man ein Passwort (das aber später nicht unmittelbar verwendet wird). Alle anderen Angaben kann man übernehmen bzw. leer lassen. Bei der Erzeugung des API-Tokens brauchen wir nur einen Token Namen vergeben. Nach dem Klick auf "Add" wird ein Token Secret angezeigt. Dabei wird sehr deutlich darauf hingewiesen, dass dieser Token nicht erneut angezeigt wird. Er muss also weggesichert werden. Nun muss man unter "Permissions" dem user und dem Token die Berechtigungsrolle "DatastorBackup" ab dem Pfad /datastor/{Name des Datastors} geben.

Danach muss ein Namespace für die Sicherungen erzeugt werden. Auf der Web-GUI des PBS unter "Datastor" wird der Sicherungsspeicher ausgewählt und über die Schaltfläche "Add Namespace" ein Namespace hinzugefügt. Der Parent Namespace Root ist vorausgewählt und kann so bleiben. Den Namespace Namen kann man frei vergeben.

Damit ist auf Seiten des PBS alles vorbereitet. Nun muss ein Skript auf dem PVE angelegt werden. Ich habe dazu auf dem PVE ein Verzeichnis /services/skripte angelegt und dort die Datei backup.sh erstellt: 

#!/bin/bash
export PBS_REPOSITORY=sys-pve01@pbs!sys-pve01@10.10.0.10:zfsbup
export PBS_PASSWORD=fab7a49d-82a8-4504-salat-undmuell
export PBS_FINGERPRINT=ec:47:11:08:15:11:88:00:...:19:58:fe:ad:43
proxmox-backup-client backup etc.pxar:/etc/ etcpve.pxar:/etc/pve/ --ns pve01

PBS_PASSWORD ist natürlich der Secret-Code, der uns eben angezeigt wurde und den Fingerprint des PBS kopieren wir von der Web-GUI des PBS (s.o.). Gesichert werden die Verzeichnisse "/etc" und "/etc/pve". Letzteres ist ein eigener Mount-Pont auf dem PVE und nicht wirklich ein Unterverzeichnis von "/etc". Es würde also nicht mit gesichert, wenn man nur "/etc" sichern würde. Das Script muss noch ausführbar gemacht werden mit 

chmod 700 backup.sh

und kann dann erstmals ausgeführt werden. Damit das automatisch regelmäßig passiert, trägt man noch einen entsprechenden Task in die Datei "/etc/crontab" des PVE ein, z.B.: 

30 12   * * *   root    /services/skripte/backup.sh

Jetzt werden die Daten aus Verzeichnis /etc/ und /etc/pve täglich um 12:30 Uhr gesichert.