Dokumentation

Dokumentation von den Kursen von sysops

Proxmox

Die Dokumentation für "Proxmox Produktiv mit ZFS betreiben" basiert auf einem kostenpflichtigen Kurs und soll dessen Inhalte wiedergeben, kann aber nicht die Betreuung und Beantwortung von Fragen, wie sie der Besuch des Kurses bietet, ersetzen. Es soll das Wissen von den hauptberuflichen Sysops Admins an Interessierte weitergegeben werden, die es danach auf den von Ihnen betreuten Systemen umsetzen können.

https://cloudistboese.de - Das Schulungsportal von sysops.tv

Proxmox VE - Alternative zu vSphere und Hyper-V mit Support aus Deutschland und Österreich

Was ist Proxmox VE

Wo sind die Grenzen von Proxmox VE

Weitere Funktionen, die eher weniger Sinn machen

Indikation für Einsatz

** Bei Proxmox kommt alles aus den Kernel (ZFS, Ceph, LXC, KVM, uvm.) **

Linux Kommandos die man kennen sollte

Proxmox Installation

Um Proxmox mit ZFS nutzen zu können, müssen die Platten direkt an Proxmox angebunden werden. Es sollte kein RAID Controller mit RAID 0 genutzt werden, da dies früher oder später zu Problemen und Datenverlusten führen wird! Damit auch eine Update von Promox 7.x auf 8.x gezeigt werden kann, wird im Kurs mit der Installation einer Proxmox Version 7.x begonnen und später auf 8 aktualisiert. Das Postinstall Script aus dem Bashclub wird installiert, um auch alle benötigten Tools für die tägliche Arbeit und im Problemfall im Zugriff zu haben. (z.B. ohne ein Netzwerkverbindung kann nichts mehr nachinstalliert werden)

Spickzettel für Installation

Proxmox GUI Zugriff

Update nach Proxmox 8.x - Für Einsteiger am einfachsten bei Erstinstallation zu üben

Proxmox Update 7 to 8

Das Pre-Upgrade Check Script pve7to8 sollte ausgeführt werden, um mögliche Probleme vor dem Upgrade erkennen zu können. Erstmal ohne Parameter und anschließend mit Parameter (--full: alle Checks).

** Für das Upgrade muss entweder eine Subskription erorben werden. Alternativ kann man auch das Enterprise Repository deaktivieren und das No-Subkription Repository aktivieren. Nur so erhält man Proxmox Updates!!! Ohne diese Auswahl kommen nur Debian Security Fixes!!!

Hier der Stand Version 7 zu 8

Wir empfehlen die VMs und Container zu stoppen und einen zeitnahen Reboot - Der neue Kernel passend zur GUI kann nur so aktiviert werden

apt update apt dist-upgrade pveversion

Letzte Version PVE 7 sollte nun installiert sein, kein Reboot notwendig hier

Upgradeprozedur bei Standardsystem

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list # ändert alle Repositories von Bullseye (Debian 11) zu Bookworm (Debian 12)

Enterprise Repo anpassen

echo "deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise" > /etc/apt/sources.list.d/pve-enterprise.list

Debian update

screen # falls etwas schief geht kann man mit screen -r zurück zur Sitzung apt update apt dist-upgrade #sollte hier mehrere hundert Aktualisierungen ankündigen

Während des Upgrades sollte man alles mit N beantworten und den Diensteneustarts zustimmen. Es kommt ggf. auch ein Textdokument was mit w zu verlassen ist

Unser Postinstaller sorgt in kürzester Zeit für alle notwendigen Sicherheits- und Komforfunktionen für den Notfall

Postinstall aus bashclub (proxmox-zfs-postinstall) auf github

Wir sichern extra die /etc Ordner nach rpool/pveconf, da der Ordner /etc/pve aus einer Datenbank live erstellt wird. Er wäre bei einer Reparatur via Boot ISO leer!!!

Die ZFS auto Snapshots werden über die crontab ausgeführt. Dafür gibt es verschiedene Verzeichnisse:

In den Ordner liegt dann für jede "Aufgabe" ein eigene Datei (z.B. zfs-auto-snapshot), in welcher die auszuführen Kommandos enthalten sind. Dort ist auch hinterlegt wieviele auto snapshots aufgehoben werden sollenn. (--keep=96)

Die Zeitpunkte wann dieses ausgeführt werden sind in der Datei /etc/crontab definiert. z. B. könnte dort der tägliche Zeitpunkt angepasst werden

Ebenfalls finden sich Skripte ab Werk unter /etc/cron.d für z. B. Scrubbing und Trimming am Sonntag. Nicht jedem taugt dieser Zeitpunkt!

cat /etc/crontab 
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *	* * *	root	cd / && run-parts --report /etc/cron.hourly
25 6	* * *	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6	* * 7	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6	1 * *	root	test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
#

Zusätzlich gibt es für jeden User (z.B. root) noch eine eigene crontab, diese liegen unter cd /var/spool/cron/crontabs/. Dort gibt es dann eine Datei root für den User root, falls diese erzeugt wurde. Diese Datei wird z.B. auf den Linux VMs genutzt, um das Trimming zeitgesteuert ausgeführen zu können.

proxmox-boot-tool / ZFS Feature Upgrade / Trimming einschalten

Mit dem promox-boot-tool könnten Platten nach einen Hardwaretausch wieder bootfähig gemacht werden. Heute sollte nach Möglichkeit uefi Boot eingesetzt werden und nicht mehr legacy Boot, damit werden die Boot Platten automatisch erkannt und müssen nicht einzeln durch probiert werden, wie bei legacy boot. Autotrim sollte auf den SSD ZFS Datasets eingeschaltet sein, damit gelöschte Blöcke wieder im Dateisystem schnell verfügbar gemacht werden.

Optionale Funktionen zur ZFS Storage Optimierung

Einige wichtige Ordner vom Proxmox:

PVE startet noch, hat aber defekte Installation oder Konfiguration - Rollback vom Debian mit PVE

Wenn der Proxmox nicht mehr richtig funktioniert, werden die folgenden Schritte durchgeführt, um ihn wieder herzustellen zu können. Die erforderlichen ZFS snapshots werden durch die "Tools" des Postinstaller erzeugt. Beim PVE Ordner (/etc/pve) handelt es sich um eine Datenbank (/dev/fuse 128M 20K 128M 1% /etc/pve), die ohne den Postinstaller nicht gesichert würden (rpool/pveconf 884G 128K 884G 1% /rpool/pveconf).

Daher sollte der Postinstaller aus dem Bashclub auf jeden Promox PVE installiert sein, damit die Konfigurationsverzeichnisse von Proxmox auf ZFS gesichert und mit Auto Snapshosts versehen werden !!!

**Sollte der Rollback Punkt z. B. auf einen Punkt von PVE 7 zeigen, so kann man beim Booten einen älteren Kernel auswählen

Nach erfolgreichem Neustart empfehle ich

Installation Windows mit VirtIO Treiber

** Inzwischen installiert der Postinstaller einmalig eine aktuelle Virtio Treiber ISO als stabile Version - Für spätere Downloads...**

Inzwischen kann man die geladene virtio.iso als zweites Laufwerk in die VM einklinken

q35 Version 5.2 - weniger Probleme als mit Version 8.0 wegen deutschen Treibern - ist für US optimiert ... - Probleme mit Netzwerkkarten möglich

EFI hat feste Bildschirmauflösung - kann nur im EFI der VM eingestellt werden (EFI BIOS) - Im Bootvorgang in der Console (Proxmox GUI) - ESC drücken

Während der Installation am einfachsten nur die VIOSCSI Treiber installieren, da sonst keine Disks angeboten werden Den Rest des Setups von der VIRTIO ISO kann nach der Installation erledigt werden. Das spart die dummen Sicherheitsfragen und geht schneller.

Am Ende sollte auf der VM Statusseite die IP Adresse zu sehen sein, ansonsten noch prüfen ob der Haken bei Guest Agent an ist!

Für alle die von den APPS genervt sind etwas lustiges zum nachbasteln

Get-appxPackage | Remove-appxPackage # man verliert Taschenrechner - alle App werden entfernt - auch der Storage wird entfernt - Nach Feature Update wieder alles da

**Windows installiert am Ende des Setups eine Wiederherstellungspartition. Diese ist eventuell zu entfernen, da ansonsten kein Resize möglich ist. Der Resize ist auf der Disk in PVE jederzeit möglich

** Windows ist inzwischen in der Lage freie Blöcke an ZFS zurückzugeben, für den Fall daß wie beschreiben SCSI Single + SSD Emulation plus Discard gewählt wurde**

Optional noch Hilbernation Mode aus

Unser Datastore Swap kann genutzt werden um die Auslagerungsdatei auf eine eigene Disk zu legen. Das spart bei ramhungrigen Systemen viel Platz, da dort keine automatischen Snapshots ausgeführt werden. Die Platte muss nicht gesichert werden. Bei Linux bitte die Swap Disks mit Backup einmal sichern

Trimming unter Linux

fstrim -av # muss eine Ausgabe bringen - sonst ist die VM falsch konfiguriert - VM Platten auf SSD und Discard umstellen

Festplatten Tausch bei Defekt oder S.M.A.R.T Fehler

Es reicht nicht mit zpool replace eine fehlende oder defekte Disk zu ersetzen. Sie könnte danach nicht booten. Wir benötigen ebenfalls zwei Partitionen mit dem Bootimage!

Der Fall beschreibt den Tausch optional gleich gegen eine größere Festplatte oder SSD

Erklärung zum Kommando sgdisk ... -- R ...

dmesg -Tw

Platte einbauen und Output prüfen, sdf ist neue Disk

zpool set autoexpand=on rpool # Erweiterung des Pools erfolgt am Ende automatisch! Bei Raid 10 reicht es zwei Disks zu Tauschen, bei RaidZx müssen allte getauscht werden um den Platz zu erweitern!

ls -althr /dev/disk/by-id | grep sdf (sdf wurde als neue Disk erkannt)

zpool status

Output zeigt aktive oder defekte Disks

	rpool                                                 ONLINE       0     0     0
	  mirror-0                                            ONLINE       0     0     0
	    ata-INTEL_SSDSC2KB019T8_PHYF951101ZS1P9DGN-part3  ONLINE       0     0     0
	    ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3  ONLINE       0     0     33

Wir tauschen nun die zweite Disk vorsorglich

-part3 zeigt deutlich daß es sich hier um die dritte Partion handelt die ersetzt werden muss, folglich sind Parition 1 und 2 zum booten!!!

ls -althr /dev/disk/by-id | grep ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3

lrwxrwxrwx 1 root root 10 Oct 15 17:38 ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 -> ../../sdb3

Wir müssen also sdb3 ersetzen

Als erstes Paritionstabelle übernehmen und erweitern, falls größere Disk

sgdisk /dev/sdb -R /dev/sdf #sdb ist eine gute Disk, sdf die neue Disk
sgdisk -G /dev/sdf # neue GUID damit EFI die Disk unterscheiden kann
proxmox-boot-tool format /dev/sdf2 #format mit fat32
proxmox-boot-tool init /dev/sdf2 #kopiert Bootimage und notiert die Disk für künftige Updates

Optional

cfdisk /dev/sda # Partition vergrößern

** Beim nächsten sgdisk der Paritionstabelle einfach die große Disk als Vorlage nehmen

Jetzt den eigentlichen Datenbestand ersetzen

ls -althr /dev/disk/by-id | grep sdf | grep part3
zpool replace rpool ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 ata-INTEL_SSDSC2KB019T8_PHYF95111111PXXX-part3

** Kontrolle des Erfolgs mit

zpool status # da soll dann die alte Disk raus sein und keine Fehler
zpool list # eventuell mehr freier Speicher nach Austausch von zwei Disks oder mehr
proxmox-boot-tool status #sollte zwei Treffer und einen Fehler melden, wegen gezogener defekter Disk
proxmox-boot-tool clean entfernt tote Bootdatenträger

Windows kaputt machen - Trojanersimulation

ZFS Cache

zpool add -n rpool cache ata-intense..
zpool add -nf rpool cache ata-intense.. # wenn schon Daten auf der Platte
zpool add -f rpool cache ata-intense..
zpool iostat -v 3
zpool iostat -v 1 # 1 sec

Das Wort "cache" im Kommando ist sehr wichtig, da sonst die Platte evt. als einzel Mirror an den stehenden Mirror angehängt wird und das wollen wir nicht, daher immer mit -n testen !!!

Proxmox Cluster

cd /etc/pve

service pveproxy restart


cd /rpool/pveconf 
zfs list -t snapshot rpool/ROOT/pve-1 


zfs rollback -r rpool/ROOT/pve-1@zfs-auto-snap_hourly-2023-09-28-1017 # panic Variante und Stromkabel nach 2 s


dd if=/dev/zero of=/dev/sda2 bs=1M count=511 
dd if=/dev/zero of=/dev/sdd2 bs=1M count=511 
proxmox-boot-tool status

Backup Proxmox Datenbank - Wie funktioniert das ?

Backup und Monitoring

zfs list # Ziel Backup Disk - Pool Backup
zfs create backup/repl -o com.sun:auto-snapshot=false 
zfs set com.sun:auto-snapshot=false backup 
bash-club-zfs-push-pull # auf Ziel ausführen


git clone https://github.com/bashclub/bashclub-zfs-push-pull.git
cd bashclub-zfs-push-pull
chmod +x 02pull
bashclub-zfs
cp bashclub-zfs /usr/bin

vi 02pull # Anpassen - In for Schleife ein echo zum Testen
bashclub-zfs # Parameter I und R - alte Snapshot und Zwischen-snapshots mitnehmen # Prinzipiell pull !!! - Quelle kommt nicht auf das Ziel, sondern nur Ziel kommt auf Quelle
cp 02pull /etc/cron.hourly

Für Trojaner sicher immer die "pull Methode" anwenden. Nur Ziel kommt auf die Quelle und nicht umgekehrt.

Monitoring

wget -O /usr/local/bin/checkzfs https://raw.githubusercontent.com/bashclub/check-zfs-replication/main/checkzfs.py  
chmod +x /usr/local/bin/checkzfs 
checkzfs --sourceonly 
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns +message 


checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns +message --output checkmk
# Datei generieren und auf anderen Server kopieren - über scp 
zfs mount -a 
ls /backup/repl/subvol-100-disk-0/etc/pmg 
mkdir /mnt/restore 

mount /dev/zvol/backup/repl/vm-101-disk-1-part3 /mnt/restore 
ls /mnt/restore # Damit kann man Daten aus dem Windows zurückspielen 
umount /mnt/restore 

zfs create backup/klon -o com.sun:auto-snapshot=false 
zfs list -t snapshot backup/repl/vm-101-disk-1 
zfs clone backup/repl/vm-101-disk1@bashclub-zfs_2023-09-28_16:21:30 backup/klon/vm-101-disk-1 

mount /dev/zvol/backup/klon/vm-101-disk-1-part3 /mnt/restore 
ls /mnt/restore 
vi /etc/pve/qemu-server/9101.conf # Anpassung das der Klon verwendet wird 
    

umount /mnt/restore 
zfs get guid 
zfs get guid | grep bashclub-zfs_2023-09-28_16:46:50 
zfs get creation rpool/data/subvol-100-disk-0@bashclub-zfs_2023-09-28_16:46:50

zfs snapshot rpool/data/vm-100-disk-0@snap1 # snapshot auslösen 
zfs send rpool/data/vm-100-disk-0@snap1 | zfs recv -dvF backup/repl # local 
zfs send rpool/data/vm-100-disk-0@snap1 | ssh rot@zielip zfs recv -dvF # anderes System


ssh root@sourceip zfs send rpool/data/vm-100-disk-0@snap1 | zfs recv -dvF backup/repl # pull


checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns+message --output mail

Verschlüsselung mit Proxmox, ZFS und Debian / Windows

Hier mal zur Überlegung was für einen Sinn macht

Physischer PC
Proxmox LXC


Proxmox LXC ZFS verschlüsselt

zfs create rpool/encrypted -o keylocation=prompt -o keyformat=passphrase -o encryption=on

#Datastore im PVE anlegen auf rpool/encrypted

nach Reboot zfs load-key #Passphrase eingeben, dann pct start xxx

Alternativ kann man das auch von außen alle Stunde auf Verdacht oder nach Prüfung per SSH auslösen

Proxmox VM



Proxmox VM ZFS verschlüsselt

zfs create rpool/encrypted -o keylocation=prompt -o keyformat=passphrase -o encryption=on

#Datastore im PVE anlegen auf rpool/encrypted

nach Reboot zfs load-key #Passphrase eingeben, dann qm start xxx

Alternativ kann man das auch von außen alle Stunde auf Verdacht oder nach Prüfung per SSH auslösen

Proxmox VM Gast verschlüsselt

Verschlüsselung wird bei der Installation vorgenommen. Nach jedem Reboot muss das Passwort in KVM Konsole von Proxmox eingegeben werden. Automatisierung nicht möglich
Abschließend ist das Ziel zu prüfen. Verschlüsselung gegen Diebstahl ist die ZFS Lösung völlig ausreichend. Replikation geht mit Raw (send -w), Backup nur wenn entsperrt ist.  Eine Sicherung einer intern verschlüsselten VM ist jederzeit, mit jeder Methode (PBS, ZFS) möglich, muss halt in jeder VM vorgenommen werden, LXCs lassen sich verschlüsselt nur gegen Diebstahl schützen, nicht gegen Einsicht.

Proxmox Best Practice Setup für ZFS und / oder Ceph im Cluster für Einsteiger (Stand Dezember 2024)

Proxmox Cluster mit ZFS und Ceph – Best Practices für Einsteiger

Praxiswissen aus rund 150 Proxmox- und ZFS-Systemen

Der Verfasser dieses Artikels, Christian-Peter Zengel, verfügt über rund 15 Jahre Praxiserfahrung mit Proxmox VE und ZFS und betreibt aktuell etwa 150 Systeme mit Proxmox und ZFS.

Die Erfahrungen reichen von Standalone-Installationen bis hin zu Proxmox-Clustern mit bis zu zehn Hosts. Der Schwerpunkt liegt klar auf ZFS, Replikation, Backup, Monitoring und praxistauglicher Hochverfügbarkeit.

Hinweis: Dieser Artikel versteht sich nicht als Ceph-Expertenleitfaden. Ceph wird hier vor allem zum Funktionsvergleich und als Einstieg behandelt. Für viele kleine und mittlere Installationen bis etwa zehn Hosts ist ZFS mit Replikation in unserer Praxis häufig die einfachere, günstigere und besser beherrschbare Lösung.

Proxmox Best Practice Kurs mit ZFS und Ceph

Diese Dokumentation basiert auf einem Onlinekurs von cloudistboese.de.

Proxmox Best Practice Cluster mit ZFS und Ceph für Einsteiger

Der Kurs vermittelt einen schnellen, praxisnahen Einstieg in den Aufbau eines Proxmox-Clusters mit ZFS, einfacher Ceph-Grundlage, Backup, Snapshots, Monitoring und Hochverfügbarkeit.

Aktuelle Kurse und Wiederholungen auf cloudistboese.de ansehen

Für wen eignet sich diese Anleitung?

Der folgende Artikel richtet sich besonders an Einsteiger, Administratoren und IT-Dienstleister, die mit mehr als einem Proxmox-Host starten möchten und eine robuste, nachvollziehbare Cluster-Grundlage suchen.

Nach diesem Kurs können Sie einen kleinen Proxmox-Cluster sicherer planen, installieren und betreiben.

ZFS oder Ceph im Proxmox Cluster?

ZFS ist für kleine und mittlere Proxmox-Installationen eine sehr starke Grundlage. Durch Prüfsummen, Snapshots, Replikation und einfache Wiederherstellung schützt ZFS zuverlässig vor vielen typischen Problemen wie defekten Datenträgern, versehentlichen Änderungen und manchen Folgen von Ransomware-Angriffen.

ZFS ersetzt jedoch kein Backup. Gegen kompromittierte Root-Zugänge, Brand, Diebstahl, vollständigen Standortausfall oder absichtlich gelöschte Snapshots hilft nur ein sauberes Backup- und Replikationskonzept.

Ceph bietet echten verteilten Storage und hohe Skalierbarkeit, benötigt aber deutlich mehr Hardware, Netzwerkplanung und Betriebserfahrung. Für viele Umgebungen bis etwa zehn Hosts ist ZFS mit Replikation oft wirtschaftlicher und einfacher zu betreiben.

Installation von Proxmox VE auf ZFS

Für den Workshop wird ein HPE Microserver Gen10 Plus V2 verwendet. Empfehlenswert ist eine Ausstattung mit ECC-RAM und direkt ansprechbaren Datenträgern.

HPE Microserver Gen10 Plus V2 ansehen

Proxmox VE Installation auf HPE Microserver mit ZFS

Wir installieren Proxmox VE bevorzugt auf ZFS Mirror, RAID10 oder RAIDZ. Hardware-RAID-Controller sollten für ZFS vermieden werden. Empfehlenswert sind Controller im HBA- oder IT-Mode, damit ZFS direkten Zugriff auf die Datenträger erhält.

Für Cluster sollten Hostnamen, IP-Adressen, Netzwerke und DNS-Einträge vor der Installation sauber geplant werden. Nachträgliche Änderungen verursachen häufig unnötige Zusatzarbeit.

Proxmox VE Installation mit ZFS Storage Auswahl

Proxmox Cluster mit drei Nodes erstellen

Ein Proxmox-Cluster kann sehr schnell erzeugt werden. Auch ein einzelner Node kann zunächst problemlos allein laufen. Für echte Cluster-Funktionen und Quorum sollten jedoch mindestens drei Nodes oder ein sinnvoller QDevice-Aufbau geplant werden.

Proxmox VE Cluster erstellen

Proxmox Cluster Join Informationen anzeigen

Proxmox Cluster Konfiguration mit mehreren Nodes

Weitere Proxmox Nodes hinzufügen

Weitere Nodes werden über die Join-Informationen des ersten Cluster-Nodes hinzugefügt. Auf dem neuen Node werden die Informationen unter Join Cluster eingefügt. Zusätzlich werden Root-Passwort und Cluster-Netzwerk angegeben.

Proxmox VE Join Cluster Dialog

Proxmox VE Cluster Join Einstellungen

Proxmox VE Node wird Cluster hinzugefügt

Während des Cluster-Beitritts kann der neue Node kurzzeitig die Verbindung zum Browser verlieren, da Schlüssel und Zertifikate des Clusters übernommen werden. Danach sollte die Weboberfläche neu geladen werden.

Proxmox Cluster mit mehreren Nodes nach erfolgreichem Join

Postinstaller für Proxmox VE

Unser Proxmox ZFS Postinstaller vom Bashclub hilft bei vielen wiederkehrenden Aufgaben nach der Installation.

Für Cluster-Setups sollten die Optionen bewusst gewählt werden. Im Workshop verzichten wir beispielsweise auf Autosnapshots für rpool/data und auf SSH-Hardening, soweit dies aus Kompatibilitätsgründen sinnvoll ist.

Bashclub Proxmox ZFS Postinstaller Einstellungen

ZFS RAID demonstrieren und überwachen

ZFS-Software-RAID lässt sich im Fehlerfall sehr schnell analysieren und wiederherstellen. Der direkte Zugriff auf die Datenträger ermöglicht ein gutes Monitoring und kann Probleme frühzeitig sichtbar machen.

Im Workshop wird beispielhaft eine Platte vor einem Reboot offline gesetzt. Das ist eine Demonstration und sollte auf produktiven Systemen nicht unüberlegt nachgestellt werden.

ZFS RAID Status in Proxmox VE

ZFS Pool mit fehlerhaftem Datenträger in Proxmox

Das Proxmox-Dashboard zeigt nicht alle Storage-Probleme so deutlich, wie es für den produktiven Betrieb wünschenswert wäre. Für professionelle Umgebungen empfehlen wir zusätzliches Monitoring, zum Beispiel mit Checkmk oder CV4PVE.

Proxmox Summary Dashboard ohne deutliche ZFS Fehleranzeige

S.M.A.R.T Kontrolle von Datenträgern in Proxmox VE

VMs und LXCs unter Proxmox richtig anlegen

Für moderne virtuelle Maschinen sollten heute in der Regel q35 und OVMF/UEFI verwendet werden. Ältere Einstellungen wie i440FX und klassisches BIOS sind für neue Systeme meist nicht mehr empfehlenswert.

Proxmox VE VM Erstellung mit moderner Hardware-Konfiguration

Proxmox VM mit UEFI und TPM Einstellungen

VirtIO SCSI Single Controller in Proxmox VE

Proxmox VM Disk Einstellungen mit Discard SSD Emulation und IO Thread

Proxmox CPU Typ Host für virtuelle Maschinen

Proxmox Memory Ballooning für virtuelle Maschinen

VirtIO Netzwerkkarte für Proxmox VM

ZFS-Replikation in Proxmox VE

Die eingebaute ZFS-Replikation von Proxmox VE ist für viele kleine und mittlere Cluster eine sehr gute Grundlage. Bei vorhandener Replikation liegt der größte Teil der VM bereits auf dem Zielsystem und muss nur inkrementell ergänzt werden.

Ohne vorherige Replikation muss die komplette VM oder der komplette Container übertragen werden. Je nach Zustand erfolgt die Übertragung über KVM-Mechanismen oder ZFS. Dabei kann es Unterschiede beim Erhalt von Snapshots geben.

Proxmox VE ZFS Replikation einrichten

Proxmox VE Replikationsjob für VM

Replikationsintervalle von 15 bis 60 Minuten sind für viele Umgebungen ein guter Kompromiss. Eine Minute ist technisch möglich, sollte aber nicht pauschal für jede VM verwendet werden.

Ceph-Grundlagen im Proxmox Cluster

Ceph ermöglicht verteilten Storage innerhalb eines Proxmox-Clusters. Dadurch können VMs auf gemeinsamem Storage liegen und bei passender Architektur sehr flexibel zwischen Nodes betrieben werden.

Ceph benötigt jedoch sorgfältige Planung, geeignete Netzwerke, passende Hardware und ausreichende Redundanz.

Für produktive Ceph-Cluster empfehlen wir mindestens eine Proxmox-Subscription und erfahrene Planung. Ein fehlerhaft aufgebauter Ceph-Cluster kann selbst zum kritischen Ausfallrisiko werden.

Ceph Installation in Proxmox VE starten

Ceph Netzwerk und Cluster Einstellungen in Proxmox VE

Die Auswahl der Netzwerke für Cluster, Ceph, Redundanz und weitere Segmentierungen sollte durch erfahrene Fachleute erfolgen. Für produktive Ceph-Umgebungen sollte das normale LAN nicht einfach mitverwendet werden.

Ceph Public und Cluster Network in Proxmox VE

Ceph OSDs und Pools einrichten

Jeder Host benötigt geeignete Datenträger als OSDs. Für ein einfaches Testsetup reichen drei OSDs, produktiv sollte Ceph jedoch deutlich sorgfältiger und redundant geplant werden.

Hardware-RAID-Controller sollten auch für Ceph nicht verwendet werden. Ceph benötigt direkten Zugriff auf die Datenträger.

Ceph OSD in Proxmox VE erstellen

Ceph Pool in Proxmox VE anlegen

Monitor- und Manager-Rollen sollten auf mehrere Nodes verteilt werden. Andernfalls kann bereits ein Reboot eines einzelnen Nodes zu Problemen führen.

Migration zwischen Nodes

Die Migration laufender VMs oder gestoppter LXCs ist sowohl mit ZFS als auch mit Ceph möglich. Der wesentliche Unterschied liegt im Storage-Konzept.

Proxmox VE Migration einer VM zwischen Nodes

Proxmox Klonen zwischen ZFS und Ceph Storage

QEMU Guest Agent installieren

Der QEMU Guest Agent sollte in virtuellen Maschinen immer installiert und aktiviert werden. Er ermöglicht geordnetes Herunterfahren, bessere Backup-Konsistenz, IP-Erkennung und weitere Verwaltungsfunktionen.

QEMU Guest Agent Installation in Proxmox VM

Proxmox Sicherheit: 2FA, SSH und Netzwerksegmentierung

Zwei-Faktor-Authentifizierung aktivieren

Root- und Proxmox-Benutzer sollten mit Zwei-Faktor-Authentifizierung abgesichert werden.

Proxmox VE Zwei Faktor Authentifizierung aktivieren

Proxmox VE Benutzer mit 2FA absichern

SSH gegen Passwort-Login absichern

SSH-Zugänge sollten nach Möglichkeit nur mit Schlüsseln und ohne Passwort-Login betrieben werden.

Proxmox SSH Daemon gegen Passwort Login absichern

Verwaltungsnetz trennen

Wenn die Ressourcen vorhanden sind, sollten Anwender- und Gast-VMs keinen direkten Zugriff auf Proxmox VE, Switches oder Firewalls erhalten.

Proxmox VE virtuelle Switche zur Trennung von Verwaltungsnetz und VM Netz

Replikationen zuverlässig prüfen

Ein Blick auf ZFS allein zeigt nicht zuverlässig, welche VM gerade auf welchem Host aktiv ist. Deshalb müssen Replikationen kontrolliert und nachvollziehbar überwacht werden.

Das Proxmox Dashboard zeigt defekte Platten, RAID-Probleme und Replikationsfehler nicht immer so zentral, wie es für größere Umgebungen wünschenswert wäre. Deshalb sollten Checkmk, CV4PVE oder eigene Prüfwerkzeuge eingesetzt werden.

Proxmox VE Replikationen pro VM prüfen

Proxmox Dashboard ohne zentrale Anzeige aller ZFS Replikationen

Proxmox Konfiguration sichern

Die Proxmox-Konfiguration liegt in einer Cluster-Datenbank und wird unter /etc/pve eingebunden. Unser Postinstaller kann diese Konfiguration regelmäßig nach /rpool/pveconf sichern und mit ZFS-Autosnapshots historisieren.

Proxmox Konfiguration mit Rsync und ZFS Auto Snapshot sichern

Hochverfügbarkeit mit Proxmox HA

Die Proxmox HA-Engine sorgt dafür, dass VMs oder LXCs beim Ausfall eines Hosts auf einem anderen Host gestartet werden können.

Wichtig ist die Unterscheidung:

Bei ZFS hängt das mögliche Datenverlustfenster vom Replikationsintervall ab. Daher eignet sich HA mit ZFS besonders für Systeme wie Firewalls, Telefonanlagen oder Dienste, bei denen ein kurzer Rückstand vertretbar ist.

Proxmox HA Gruppe mit Prioritäten konfigurieren

Proxmox VM einer HA Gruppe zuweisen

Wird ein Node regulär neu gestartet, sollten VMs vorher bewusst migriert werden. Ein Reboot ersetzt keine geplante Wartung.

Snapshots manuell und automatisch nutzen

Manuelle Snapshots über die Proxmox GUI oder API werden abhängig vom darunterliegenden Storage erzeugt – beispielsweise auf ZFS, Ceph oder anderen Storage-Backends.

Bei ZFS werden Snapshot-Zustände mitrepliziert und in der VM-Konfiguration sichtbar.

Manuellen Snapshot in Proxmox VE erstellen

ZFS Snapshot einer Proxmox VM

CV4PVE-Admin für Snapshots, Monitoring und Replikationen

CV4PVE-Admin kann eine sinnvolle Ergänzung zu Proxmox VE sein. Es bietet bessere Übersicht über Replikationen, Snapshots und bestimmte Monitoring-Funktionen.

CV4PVE Admin für Proxmox VE Monitoring und Snapshots

CV4PVE Admin Übersicht aller Proxmox Replikationen

Automatische Snapshots können dort definiert werden. Wichtig ist, dass das System zuverlässig läuft und überwacht wird.

Automatische Snapshots mit CV4PVE Admin konfigurieren

Proxmox Backup Server einrichten

Proxmox VE kann klassische Backups erstellen. Der Proxmox Backup Server ergänzt inkrementelle, deduplizierte Backups, zentrale Verwaltung, Verify Jobs, Prune Jobs und Garbage Collection.

PBS kann auf eigener Hardware, in einer VM oder in bestimmten Szenarien auch als LXC betrieben werden. Für produktive Backups ist ein dediziertes, abgesichertes System vorzuziehen.

Proxmox Backup Server Installation

Proxmox Backup Server Weboberfläche Port 8007

Für den Datastore empfehlen sich lokale Dateisysteme oder geeignete Storage-Anbindungen. SMB verursacht in vielen Umgebungen zusätzlichen Overhead und ist für PBS meist nicht die beste Wahl.

Backup-Benutzer, Token und Rechte

Für Backups sollte ein eigener Backup-Benutzer mit Token verwendet werden. Root-Zugänge und Backup-Zugänge sollten mit Zwei-Faktor-Authentifizierung abgesichert werden.

Der Benutzer oder Token benötigt die Berechtigung Datastore Backup.

Proxmox Backup Server Benutzer mit Zwei Faktor Authentifizierung

Proxmox Backup Server API Token für Backup Benutzer erstellen

Proxmox Backup Server Rechte Datastore Backup vergeben

Proxmox Backup Server in Proxmox VE einbinden

Für die Einbindung des Proxmox Backup Servers in Proxmox VE werden mehrere Angaben benötigt:

Proxmox VE Backup Storage mit Proxmox Backup Server verbinden

Proxmox Backup Storage in allen PVE Nodes verfügbar

Das lokale Bootvolume von Proxmox VE sollte nicht als Backup-Ziel verwendet werden.

Backups, Prune, Garbage Collection und Verify

Das erste Backup einer VM ist in der Regel ein vollständiger Durchlauf. Danach werden mit Dirty Bitmap und Deduplizierung nur noch geänderte Daten effizient übertragen und gespeichert.

Nach einem Stop der VM oder Reboot des Hosts kann wieder ein vollständiger Scan notwendig werden. Durch Chunk-Deduplizierung werden jedoch nur neue oder geänderte Chunks gespeichert.

Erstes manuelles Backup mit Proxmox Backup Server

Inkrementelles Backup mit Proxmox Backup Server

Prune Jobs

Prune Jobs definieren Aufbewahrungszeiten. Der Proxmox-Simulator hilft bei der Prüfung der Regeln.

Proxmox Backup Server Prune Job konfigurieren

Garbage Collection

Die Garbage Collection räumt nicht mehr benötigte Chunks auf. Dieser Vorgang kann Last erzeugen und sollte sinnvoll geplant werden.

Proxmox Backup Server Garbage Collection starten

Verify Jobs

Verify Jobs prüfen regelmäßig die Integrität der Backups. Der Erfolg wird sowohl im PBS als auch in Proxmox VE angezeigt.

Proxmox Backup Server Verify Job zur Integritätsprüfung

Optional: Replikationskontrolle mit checkzfs

Mit checkzfs vom Bashclub können ZFS-Replikationen zusätzlich kontrolliert werden. Da nicht immer sofort erkennbar ist, welcher Host welche VM aktiv betreibt, kann ein Vergleich der Datastores hilfreich sein.

Der Check sollte nicht während laufender Replikationen ausgeführt werden, da dies zu Fehlmeldungen führen kann.

checkzfs Replikationskontrolle für Proxmox ZFS Cluster

CV4PVE als Alternative zur Replikationskontrolle in Proxmox

Fazit: Proxmox Cluster mit ZFS bewusst planen

Für viele kleine und mittlere Umgebungen ist ein Proxmox-Cluster mit ZFS, Replikation, Proxmox Backup Server und gutem Monitoring eine sehr leistungsfähige und wirtschaftliche Lösung.

Ceph ist besonders interessant, wenn echter verteilter Storage, hohe Skalierung und passende Hardware vorhanden sind. Für kleinere Installationen ist ZFS jedoch häufig einfacher zu verstehen, schneller einzurichten und leichter zuverlässig zu betreiben.

Ressourcen

Proxmox Schulung oder Beratung anfragen

Sie möchten Proxmox VE mit ZFS, Replikation, Backup und Monitoring professionell einsetzen? Die sysops GmbH unterstützt bei Planung, Installation, Migration, Schulung und Betrieb.

📧 info@sysops.de
📞 +49 (0) 6021 2125-0

Vielen Dank für Ihre Aufmerksamkeit.
Christian-Peter Zengel – sysops.tv

 

Update: Ceph-Vernetzung mit Proxmox VE 9 und Network Fabrics

Seit Proxmox VE 9 lässt sich die Ceph-Vernetzung deutlich einfacher abbilden. Mit den neuen SDN Network Fabrics können geroutete Underlay-Netzwerke direkt über die Proxmox-Oberfläche erstellt werden.

Damit werden insbesondere Full-Mesh-Netzwerke für Ceph übersichtlicher und wartbarer. Proxmox beschreibt selbst, dass Fabrics ab PVE 9 über den SDN-Stack in der GUI erstellt werden können und sich für Full-Mesh-Ceph-Setups eignen. [oai_citation:0‡Proxmox VE](https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server?utm_source=chatgpt.com)

Für neue Ceph-Installationen sollte daher geprüft werden, ob die Vernetzung über Datacenter → SDN → Fabrics sinnvoller ist als eine manuelle statische Netzwerkkonfiguration.

ZFS Grundlagen am Beispiel Proxmox VE(Stand Januar 2025)

Der Verfasser des Artikels, Christian-Peter Zengel, hat zum Zeitpunkt des Artikels ca 15 Jahre Erfahrung mit ZFS und Proxmox. Er betreibt aktuell ca 150 Systeme mit Proxmox und ZFS

Das Einsatzgebiet geht von Standaloneinstallation bis zu ca 10 Hosts im Cluster. Es ist keine Ceph Expertise vorhanden!

Dieser Dokumentation basiert auf diesem online Kurse von cloudistboese.de

21. + 23.01.2025 (13.00 Uhr bis 17.00 Uhr) - ZFS Grundlagen


ZFS ist die perfekte Grundlage für kleine und mittlere Systeme um gegen Ausfälle, Dummheit anderer und Erpressungstrojanern ideal aufgestellt zu sein.
In diesem Kurs erhalten sie Grundkenntnisse für Systeme wie Proxmox, TrueNAS oder ähnliche Systeme.

Der Fokus liegt auf der Technologie und der permanenten Sicherheit im Umgang mit Daten, Linux und dem Terminal.

Themen:

Nach diesem Kurs bist Du bei Ausfällen und Datenverlust vor dem Schlimmsten geschützt und in Minuten wieder produktiv!

https://de.wikipedia.org/wiki/ZFS_(Dateisystem)

https://www.proxmox.com/de/

https://cloudistboese.de

So erstellt Proxmox VE seinen ZFS Raid

zpool create -f -o cachefile=none -o ashift=12 rpool mirror disk1 disk2

Destruktives Anlegen (-f), kein automatisches Importieren beim Start (-o cachefile=none)
-o ashift=12 ist für 4k Festplatten, ashit=9 für 512e Disks, wobei man mit 12 nichts verkehrt macht
rpool ist der Name vom künftigen Pool, mirror der Raidlevel und die Disks wurden zweifelsfrei über Ihre ID definiert

Optionen für Raidlevel wären noch: ohne als Stripe, raidz, raidz2 oder raidz3, also Raid Level 5-7

 Bildschirmfoto 2025-01-21 um 13.41.23.jpg

Die ersten Zpool Manöver und die endlose Aktionsliste sieht man mit 

zpool history

Bildschirmfoto 2025-01-21 um 13.44.20.jpg

Manuelles Trimmen der SSDs um gelöscht Blöcke schner überschreiben zu können findet man unter /etc/cron.d
Ebenso wird nach diesem Zeitplan der sog. zpool scrub durchgeführt, der die Konsistenz der Redundanz prüft und ggf. korrigiert. Gefundene Fehler findet man dann mit zpool status

Bildschirmfoto 2025-01-21 um 13.47.45.jpg

Zum identifizieren der Platten bieten sich neben der PVE GUI noch folgende Befehle an. Es wird dringend empfohlen bereits genutzte Platten via PVE GUI zu wipen

dmesg -Tw (live)
lsblk
ls -althr /dev/disk/by-id

Bildschirmfoto 2025-01-21 um 13.50.01.jpg

Erstellen verschiedener Raidlevel und Ihrer Vorzüge

Mit ls -althr /dev/disk/by-id haben wir folgende Festplatten anhand ihrer aufgedruckten WWN Kennung identifiziert. Es ist dringend empfohlen bei HBAs sich die Slots und die Seriennummern beim Einbau zu notieren und in die Dokumentation aufzunehmen

wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  wwn-0x5000cca01a8417fc  

Stripe, also Raid0

zpool create -f test wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c  wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8

test                      ONLINE
 wwn-0x5000cca01a72ded4  ONLINE
 wwn-0x5000cca01a7b1e2c  ONLINE
 wwn-0x5000cca01a83a61c  ONLINE
 wwn-0x5000cca01a832d24  ONLINE
 wwn-0x5000cca01a83331c  ONLINE
 wwn-0x5000cca01a7495b8  ONLINE
 wwn-0x5000cca01a8417fc  ONLINE
Mirror, also Raid1

zpool create -f test mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c

test
 mirror
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
Striped Mirror, also Raid10

zpool create -f test mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c mirror  wwn-0x5000cca01a83a61c  wwn-0x5000cca01a832d24  mirror wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8

test
 mirror
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
 mirror
   wwn-0x5000cca01a83a61c
   wwn-0x5000cca01a832d24
 mirror
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8
RaidZ, also Raid 5, Nettoplatz x-1

zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  wwn-0x5000cca01a8417fc  

test                        ONLINE       0     0     0
 raidz1-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0
   wwn-0x5000cca01a832d24  ONLINE       0     0     0
   wwn-0x5000cca01a83331c  ONLINE       0     0     0
   wwn-0x5000cca01a7495b8  ONLINE       0     0     0
   wwn-0x5000cca01a8417fc  ONLINE       0     0     0
RaidZ2, also Raid 6, Nettoplatz x-2

zpool create test raidz2 wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  wwn-0x5000cca01a8417fc  

 raidz2-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0
   wwn-0x5000cca01a832d24  ONLINE       0     0     0
   wwn-0x5000cca01a83331c  ONLINE       0     0     0
   wwn-0x5000cca01a7495b8  ONLINE       0     0     0
   wwn-0x5000cca01a8417fc  ONLINE       0     0     0

RaidZ-0, also Raid 5-0, Nettoplatz x-2, in diesem Beispiel

zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c raidz wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  

 
test                        ONLINE       0     0     0
 raidz1-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0
 raidz1-1                  ONLINE       0     0     0
   wwn-0x5000cca01a832d24  ONLINE       0     0     0
   wwn-0x5000cca01a83331c  ONLINE       0     0     0
   wwn-0x5000cca01a7495b8  ONLINE       0     0     0
   wwn-0x5000cca01a8417fc  ONLINE       0     0     0

oder mit Spare, wenn Du davon nicht booten musst

zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c  wwn-0x5000cca01a83a61c raidz wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8  spare wwn-0x5000cca01a8417fc

Erweiterung eines RaidZ zum RaidZ-0

test                        ONLINE       0     0     0
 raidz1-0                  ONLINE       0     0     0
   wwn-0x5000cca01a72ded4  ONLINE       0     0     0
   wwn-0x5000cca01a7b1e2c  ONLINE       0     0     0
   wwn-0x5000cca01a83a61c  ONLINE       0     0     0

zpool add -n test raidz wwn-0x5000cca01a832d24  wwn-0x5000cca01a83331c  wwn-0x5000cca01a7495b8

test
 raidz1-0
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
   wwn-0x5000cca01a83a61c
 raidz1
   wwn-0x5000cca01a832d24
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8

Erweiterung eines Raid durch Ersetzen mit größeren Platten

Die Platten müssen die Gleiche Geometrie hanben, also 4k zu 4k oder 512e zu 512e

Bei Raid 1 und 10 reicht es zwei Disks zu tauschen, bei RaidZx müssen alle Disks getauscht werden

Replace Vorgänge können auch laufen ohne die Redundanz zu brechen, wenn weitere Slots frei sind

Bei Erweiterung durch Austausch von großen und vor allem älteren Raid 10 prüfen ob in einem Mirror ggf. neue Platten getauscht wurden, diese sollten weiter im Betrieb bleiben, während ältere Paare getauscht werden können

rpool-hdd
 mirror-0
  2024-8T (vorher Disk aus 2014)
  2024-8T (vorher Disk aus 2014)
 mirror-1
  2014-2T
  2021-2T
 mirror-2
  2022-2T
  2014-2T

Caches und Logdevices

Vorsichtig formuloiert, Lese- und Schreibcache

First Level Cache, sog. ARC kommt aus dem RAM und bekommt idealerweise ca. 1GB für 1TB Nettodaten

Second Level Cache wird als Cachedevice als Partition auf einer schnelleren Disk als der Pool hat bereitgestellt, z. B. am idealsten mit NVMe

zpool add test -n cache sdl

test
 raidz2-0
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
   wwn-0x5000cca01a83a61c
   wwn-0x5000cca01a832d24
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8
   wwn-0x5000cca01a8417fc
cache
 sdl
Logdevice (Writecache muss gespiegelt werden)
Damit der Log auch genutzt wird muss man noch mit zfs set sync den cache aktivieren

zpool add test -n log mirror sdl 

zfs set sync=always test

test
 raidz2-0
   wwn-0x5000cca01a72ded4
   wwn-0x5000cca01a7b1e2c
   wwn-0x5000cca01a83a61c
   wwn-0x5000cca01a832d24
   wwn-0x5000cca01a83331c
   wwn-0x5000cca01a7495b8
   wwn-0x5000cca01a8417fc
logs
 mirror
   sdl
   sdk
Arc wird mit "arcstat 1" ausgelesen, er wird bei der Installation festgelegt oder später unter /etc/modprobe.d/zfs.conf geändert. update-initramfs -u macht das dann persistent und aktiviert die Änderungen beim nächsten reboot.
Zur Laufzeit ändert man den Firstlevelcahce mit 
Cache- und Logdevices mit zpool iostat 1

echo 2147483648 > /sys/module/zfs/parameters/zfs_arc_max
echo 1073741824 > /sys/module/zfs/parameters/zfs_arc_min
free -h && sync && echo 3 > /proc/sys/vm/drop_caches && free -h

arcstat 1

Bildschirmfoto 2025-01-21 um 15.15.59.jpg

Test der Leistung eines Pools

zfs create -o compression=off test/speed
cd /test/speed
dd if=/dev/zero of=dd.tmp bs=256k count=16384 status=progress
dd if=/dev/zero of=dd.tmp bs=2M count=16384 status=progress

Bildschirmfoto 2025-01-21 um 15.30.20.jpg

Bildschirmfoto 2025-01-21 um 15.31.09.jpg

Erweiterung der Funktionen des Pools

zpool status meldet neue Funktionen im ZFS und kann leicht und schnell mit

zpool upgrade -a

erledigt werden

Jedoch würde ich in jedem Fall empfehlen zu prüfen ob meine Notfall ISO diese Funktionen bereits unterstützt!

Bildschirmfoto 2025-01-21 um 15.59.16.jpg

Bildschirmfoto 2025-01-21 um 15.59.26.jpg

Für das Auslesen der Parameter von Pools, Volumes, Datasets und Snapshots gibt es den Parameter get

 

Bildschirmfoto 2025-01-21 um 16.00.49.jpg

Bereitstellen und entfernen von Pools ohne löschen

zpool import #zeigt was es zum importieren, also bereitstellen gibt

zpool import poolname oder -a für alle importiert den Pool oder alle verfügbaren Pools

Am elegantesten importiert man den Pool über

zpool import -d /dev/disk/by-id

damit man hinterher nicht sda, sdb, sondern die Bezeichner im Status sieht

Bildschirmfoto 2025-01-21 um 16.12.48.jpg

Nach der Bereitstellung würde man hier lediglich einen Mountpoint /test finden, bei TrueNAS /mnt/test. Dazu noch die Systemdatasets vom Proxmox selbst. Danach legen wir gleich mal ein Dataset namens dateisystem und ein Volume namens volume an.

Bildschirmfoto 2025-01-21 um 16.27.43.jpg

Datasets werden als Ordner gemountet und / oder /mnt

Volumes findet man unter /dev/zd... und zusätzlich mit vernünftigen Namen unter /dev/zvol/tankname/....

Bildschirmfoto 2025-01-21 um 16.28.41.jpg

Datasets werden mit Linuxcontainern, Backupfiles, Vorlagen oder Serverdateien bespielt

Volumes verhalten sich wie eingebaute Datenträger, jedoch virtuell. Sie stehen nach dem Import des Pools bereit und können in einer VM genutzt werden. Manipulationen an Volumes zur Vorbereitung oder Datenrettung können jedoch ebenso auf dem PVE Host vorgenommen werden

Diese Schritte übernimmt üblicherweise der Installer in der VM und sollen nur aufzeigen wie diese ZVOLs genutzt werden

Bildschirmfoto 2025-01-21 um 16.42.58.jpg

Bildschirmfoto 2025-01-21 um 16.43.33.jpg

Bildschirmfoto 2025-01-21 um 16.48.11.jpg

Bildschirmfoto 2025-01-21 um 16.48.19.jpg

Proxmox legt seine Datasets für LXC so ab

Bildschirmfoto 2025-01-21 um 16.52.46.jpg

und so die ZVOLs für VMs mit KVM, hier findet man die virtuellen Disk und /dev/zvol...

Bildschirmfoto 2025-01-21 um 16.51.58.jpg

Thin- und Thickprovisioning für Datasets und Volumes

Am Beispiel von Proxmox VE via GUI wird hier eine Thinprovision Festplatte für VM 301 mit 32GB und einer Standardblockgröße von 16k erzeugt. 8k sind nur bei Raid1 und 10 möglich. Hakt man den Thinprovision Haken nicht an, wird beim Erzeugen noch die Option -o refreservation=32G ergänzt. Diese macht bei ZFS mit Autosnapshots aber keinen Sinn

zfs create -s -b 16k -V 33554432k rpool/data/vm-301-disk-4

rpool/data/vm-301-disk-4                                  56K  1.17T    56K  - #hier kein Mount sonder unter /dev/zvol/...

Bei LXC werden Datasets genutzt und der Platz via Reservierung genutzt, wobei bei der genutzten Refquota auch die Snapshotaufhebezeiten den Nettoplatz verkleinern, daher größer dimensionieren, gerne mal doppelt so groß

 zfs create -o acltype=posixacl -o xattr=sa -o refquota=33554432k rpool/data/subvol-106-disk-1

rpool/data/subvol-106-disk-1                              96K  32.0G    96K  /rpool/data/subvol-106-disk-1 #hostzugriff möglich

Virtuelle Diskimages wie QCOW2, VMDK oder RAW-Dateien legt man üblicherweise nicht in Datasets, bestenfalls für NFS oder iSCSI Server

Snapshots

Snapshots können jederzeit erstellt oder gelöscht werden. Die Datasets und Volumes befinden sich immer in einem Livezustand der sich durch die Vektorkette der eventuell vorhandenen Snapshots ergibt. Entfernt man einen Snapshot, so verändert sich der Weg der Vektoren. Das Ganze geschieht fast ohne Last!

ZFS selbst bringt weder Workflows für Snapshotting, noch Replikationen mit. Es stellt nur die Werkzeuge bereit

Snapshots generiert man bei Proxmox offiziell mit der GUI manuell oder für Replikationen, jedoch leistet dieser Workflow nicht genug.

Daher nutzen wir...

apt install zfs-auto-snapshot -y

ZFS-AUTO-SNAPSHOT legt seine Verknüpfungen in alle Cronordner. Proxmox VE weiß erst mal nichts davon. Zu berücksichtigen ist hier lediglich daß wir den Pool nicht über 80% befüllen wollen. Gehen wir darüber hinaus, müssen wir in den Cronordnern die Verknüpfungen anpassen um die Aufhebezeiten zu reduzieren.

nano /etc/crontab #kann angepasst werden, die viertelstündlichen finden sich unter cron.d!

# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6 * * 7 root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6 1 * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }

cat /etc/cron.hourly/zfs-auto-snapshot 

exec zfs-auto-snapshot --quiet --syslog --label=hourly --keep=96 // #also in dem Fall 96 Stunden

Wir empfehlen für den Start folgende Settings: Drei Monate, sechs Wochen, zehn Tage, 96h und 12 Viertelstunden

Damit kommt man auf ca. 2,5x- 3x so viele Daten wie belegt wären ohne Snapshots. Erfahrungswert.

Das wären pro virtueller Disk oder LXC Mountpoint etwa 127 Snaphots, bei 20 Disks über 2540. 

Nicht davon abschrecken lassen, es geht auch easy fünfstellig, wenn die IO stimmt!

Die in PVE eingebaute Snapshotfunktion sollte nicht mit den Autosnapshots kombiniert werden. 

Im Problemfall stoppen wir die VM, manipulieren was zu machen ist und starten sie wieder!

Der eigentliche Vorteil der Snapshots in der GUI ist die Notierung der VM Definition zur Zeit der Erstellung, was wir über ein Backup im hauseigenen Postinstaller kompensieren. Dort findet man die Historie der PVE Config

Bildschirmfoto 2025-01-23 um 14.29.16.jpg

Kleines manuelles Beispiel, was für uns aber Z-A-S übernimmt

 

Snapshot

zfs snapshot tank/sub/datasetodervolume@snapshotname

Auflisten

zfs list -t snapshot tank/sub/datasetodervolume

VM oder LXC ausmachen

Rollback 

zfs rollback -r rpool/data/vm-100-disk-0@Test #danach ist alles neuere weg!  

VM oder LXC starten

Dynamik von Snapshots

Wir unterscheiden zwei Sorten von Datennutzung

Dynamik von Snapshots

Dank ZFS kann man langfristig Replikationen inkrementell vornehmen, jedoch dauert die erste Replikation natürlich länger, wenn schon Datenbestand da war

Übliche Vorgehensweise einer Datenübertragung

PC NTFS>SMB> Datei > SAMBA Server BTRFS LVM > EXT4 Datei = Konsistent? Bitrod?

Zu viele Köche verderben die Köchin

Funktion von Snapshotreplikation

Von ZFS zu Datei, was wenig Praxis findet

zfs send tank/dataset@snapshot > datei.zfs

zfs recv tank < datei.zfs

Von ZFS zu ZFS, was üblich ist

zfs send | zfs recv #laufen immer gleichzeitig

zfs send rpool/data/vm-100-disk-0@Test | zfs recv -dvF backuptank  
#überträgt den Zustand Test auf ein lokalen weiteren Pool, wobei das zfs Tool immer doppelt läuft

Pushreplikation

zfs send -pvwRI rpool/data/vm-100-disk-0@Test rpool/data/vm-100-disk-0@zfs-auto-snap_hourly-2025-01-23-1317 | zfs recv -dvF backuptank 
#Fortschritt, Infos, Rohdaten plus Historie, ideal für verschlüsselte Volumes, erspart das De- und Komprimieren

Workflow

Trojanerproblem: Wer auf Quelle sitzt kann Pushziele löschen

Lösung: Pullreplikation, ähnlich Backupsoftware, Transport SSH, Daten ZFS
Quelle |> Pullserver

zfs recv | ssh root@quelle zfs send #Pull Replikation via SSH

Von PVE zu PVE, was uns zu wenig ist

Bildschirmfoto 2025-01-23 um 16.26.18.jpg

Bildschirmfoto 2025-01-23 um 16.26.33.jpg

Bildschirmfoto 2025-01-23 um 16.26.37.jpg

Proxmox baut selbst keine Notfallpunkte auf und nutzt ZFS nur als Transport, nimmt jedoch manuelle und automatisierte Snapshots mit, auch von Z-A-S!

Weitere Kopien per ZFS sind nur per Pushverfahren möglich, was ideal für Angreifer ist wenn sie alles löschen möchten. Ein Backupserver ist hier unverzichtbar, bei Pullreplikation gehts ggf. auch ohne. Außer Haus ist es nicht möglich ein ZFS Replikat zu senden, da sich der Partner im lokalen Cluster befinden muss!

Nondestruktiver Rollback nach Trojanerbefallt bei Forensikbedarf

OPNsense Migration Legacy zu Instance, ohne neues Ausrollen von Konfigurationen

OPNsense: OpenVPN Legacy zu Instances migrieren – ohne Neukonfiguration der Clients

In OPNsense werden die bisherigen OpenVPN-Legacy-Konfigurationen abgekündigt. Wer unter VPN → OpenVPN → Legacy arbeitet, kennt vermutlich bereits die folgende Meldung:

This component is reaching the end of the line, official maintenance will end as of version 26.1

Bestehende OpenVPN-Server sollten daher von der bisherigen Legacy-Konfiguration auf OpenVPN Instances migriert werden.

Die Migration ist grundsätzlich unkompliziert. Wenn die vorhandenen Parameter korrekt übernommen werden, kann die Umstellung erfolgen, ohne die komplette VPN-Konfiguration neu auszurollen. Es gibt allerdings einige Punkte, auf die besonders geachtet werden sollte.

1. Bestehende Legacy-Konfiguration dokumentieren

Öffnet zunächst die vorhandene OpenVPN-Konfiguration unter:

VPN → OpenVPN → Legacy

Die dort vorhandenen Werte werden anschließend in die neue Instanz übernommen. Es empfiehlt sich daher, die bestehende Konfiguration vor der Migration vollständig zu dokumentieren.

Wichtig: Die alte Konfiguration zunächst nicht löschen. Sie dient während der Migration als Referenz für sämtliche Einstellungen.

2. Alten OpenVPN-Server deaktivieren

Deaktiviert den bisherigen OpenVPN-Legacy-Server.

Da die neue Instanz denselben Port verwenden soll, darf der alte und der neue OpenVPN-Server nicht gleichzeitig auf diesem Port lauschen.

3. Shared Key übernehmen

Falls die bisherige OpenVPN-Konfiguration einen Shared Key / TLS Static Key verwendet, muss dieser zunächst übernommen werden.

Öffnet dazu:

VPN → OpenVPN → Static Keys

Übernehmt dort den bisherigen Schlüssel und verwendet als:

Einstellung Wert
Mode Auth

Dieser Key wird später der neuen OpenVPN-Instanz zugeordnet.

4. Neue OpenVPN-Instanz erstellen

Erstellt nun unter OpenVPN eine neue Instanz.

Mindestens die folgenden Einstellungen müssen aus der bisherigen Legacy-Konfiguration übernommen werden:

Neue OpenVPN Instance Wert / Quelle aus Legacy
Role Server
Enabled Yes
Port Number Bisherigen Port übernehmen, z. B. 1194
Type TUN
Server IP Wert aus IPv4 Tunnel Network, z. B. 172.16.1.0/24
Topology subnet
Certificate Alten Eintrag aus Server Certificate übernehmen
Certificate Authority Alten Eintrag aus Peer Certificate Authority übernehmen

5. Advanced Mode aktivieren

Blendet anschließend links oben den Advanced Mode ein.

Dadurch werden zusätzliche Einstellungen sichtbar, die für eine möglichst identische Übernahme der bisherigen Legacy-Konfiguration benötigt werden.

6. TLS Static Key konfigurieren

Unter:

TLS Static Key

wählt ihr den zuvor unter Static Keys angelegten bzw. übernommenen Schlüssel aus.

7. Authentifizierung übernehmen

Die bisherigen Authentifizierungsparameter müssen ebenfalls übernommen werden.

Einstellung Konfiguration
Auth Alten Wert aus Auth Digest Algorithm übernehmen, z. B. SHA256
Authentication Bisherigen Authentifizierungsserver auswählen, sofern vorhanden
Renegotiate Time 3600
Auth Token Lifetime 43200

Als Authentication Backend kann beispielsweise ein vorhandener Domain Controller, UCS-Server oder Samba Active Directory verwendet werden.

8. Lokales Netzwerk übernehmen

Unter:

Local Network

übernehmt ihr den bisherigen Wert aus:

IPv4 Local Network

Damit werden die bisher über den VPN-Tunnel erreichbaren internen Netzwerke wieder entsprechend bereitgestellt.

9. Achtung bei Compression

Hier befindet sich einer der wichtigen Fallstricke bei der Migration.

Falls in der bisherigen Legacy-Konfiguration unter Compression ein Wert ausgewählt war, muss in der neuen Instance im Advanced Mode zusätzlich:

Compression Migrate

aktiviert werden.

Achtung: Dies gilt auch dann, wenn in der bisherigen Konfiguration bei Compression Disabled ausgewählt war.

10. Weitere Parameter prüfen

Abhängig von der bisherigen OpenVPN-Konfiguration können weitere Parameter erforderlich sein. Vergleicht daher vor dem produktiven Einsatz die neue Instance vollständig mit der bisherigen Legacy-Konfiguration.

Besonders geprüft werden sollten:

Besonderheit der OPNsense Business Edition

Hinweis zur Business Edition: Die OPNsense Business Edition 24.10 verfügt noch nicht über die Option Compression Migrate.

Für entsprechende bestehende Konfigurationen muss daher auf eine geeignete Business-Version 25.x gewartet werden.

Technischer Stand

Diese Anleitung basiert auf dem technischen Stand von April 2025. Die beschriebene Migration wurde mit:

OPNsense 25.1.4_1-amd64

durchgeführt.

Hinweis: OPNsense entwickelt die OpenVPN-Instance-Konfiguration kontinuierlich weiter. Bezeichnungen und verfügbare Optionen können sich in neueren Versionen ändern.

image.png

Backup und Replikation trojanersicher für Proxmox VE mit Miyagi Workflow

Trojanersichere Backups und Replikationen mit Proxmox Backup Server, ZFS und Miyagi

Ziel ist eine Datensicherung mit drei Kopien der Daten, mindestens zwei Standorten und zwei unterschiedlichen Sicherungsmethoden. Zusätzlich muss die Kontrolle der Backups und Replikationen zuverlässig, automatisch und ohne Fehlerquote funktionieren.

Unsere Lösung kombiniert Proxmox Backup Server, ZFS-Replikation, Snapshots, Monitoring mit Checkmk und den Miyagi-Workflow. Dadurch entstehen sowohl klassische Backups mit langer Historie als auch startfähige ZFS-Replikate für schnelle Wiederherstellung im Notfall.

Backups bieten ein Wiederherstellungsversprechen.

ZFS-Replikate bieten eine sehr schnelle Wiederherstellungsmöglichkeit, weil replizierte Systeme auf geeigneter Hardware direkt gestartet werden können.

Was wir erreichen wollen

Als Ergebnis entsteht eine Backuphistorie über mehrere Monate bis Jahre sowie ein ZFS-Replikat mit typischer Aufbewahrung von ca. 14 Tagen bis drei Monaten.

Backup- und Replikationsübersicht mit Proxmox Backup Server und ZFS

Beispiel auf dem Zielserver

# Auf dem Zielserver sollte das dann so aussehen

# Proxmox Backups mit Snapshot-Schutz gegen Kompromittierung
zfs list
rpool/pbsstore                    4.9T  30.4T  4.62T  /rpool/pbsstore 

# PVE mit LXC Container
rpool/repl/lwpve2/rpool/data/subvol-100-disk-0    168G  34.8G   165G  /rpool/repl/lwpve2/rpool/data/subvol-100-disk-0
rpool/repl/lwpve2/rpool/data/subvol-102-disk-0    918M  31.1G   872M  /rpool/repl/lwpve2/rpool/data/subvol-102-disk-0

# PVE mit KVM
rpool/repl/lwpve3/rpool3/data/vm-301-disk-0       267K  41.0T   169K  -
rpool/repl/lwpve3/rpool3/data/vm-301-disk-1      40.6G  41.0T  26.7G  -
rpool/repl/lwpve3/rpool3/data/vm-301-disk-2       277G  41.0T   214G  -

# ZVOLs finden sich unter /dev/zvol/rpool...

Backups benötigen für eine Wiederherstellung den richtigen Zeitpunkt, genügend freien Platz und Zeit. ZFS-Replikate können dagegen auf ausreichend leistungsfähiger Hardware sehr schnell produktiv gestartet werden.

Die Aufbewahrungszeiten für Backups und Replikate können selbst festgelegt werden.

Überlegungen zu Proxmox VE, ZFS und Ceph

Proxmox VE ist eine leistungsfähige Virtualisierungsplattform auf Basis von KVM und LXC. Viele ältere VMware- und Hyper-V-Umgebungen können auf Proxmox VE migriert werden.

Der eigentliche Nutzen von Proxmox entsteht aber nicht nur durch die Weboberfläche, sondern durch die Kombination mit ZFS, Ceph, SDN, Snapshots, Replikation und dem Proxmox Backup Server.

Nutzt man Proxmox VE nur mit Hardware-RAID oder klassischem SAN, verliert man viele Vorteile, die Proxmox in Verbindung mit ZFS oder Ceph eigentlich bietet.

ZFS eignet sich besonders für kleinere und mittlere Installationen mit einem bis drei Proxmox-Servern. Hier können Systeme performant betrieben, regelmäßig snapshotiert und auf weitere Systeme repliziert werden.

Ceph kommt vor allem dann ins Spiel, wenn im Fehlerfall möglichst kein Datenverlust entstehen darf und ausreichend Budget, Netzwerkleistung und Know-how vorhanden sind. In der Praxis bedeutet Ceph häufig einen deutlich höheren Hardware- und Betriebsaufwand.

Mit ZFS erreicht man realistisch eine Sicherungslücke von unter fünf Minuten oder besser, wenn es notwendig ist. Nur weil bei einem Server das Licht ausgeht, sind die Daten noch lange nicht verloren.

Empfehlung für kleinere Umgebungen

Snapshots gegen Bedienfehler, Fahrlässigkeit und Ransomware

Vor Umstellungen, Updates oder riskanten Maßnahmen erstellt ein Administrator üblicherweise einen Snapshot. Bei VMware oder Hyper-V können zu viele oder zu lange bestehende Snapshots schnell zum Problem werden.

Hier spielt ZFS seine Stärke aus. ZFS-Snapshots sind sehr effizient und können regelmäßig erstellt werden, ohne den Betrieb in gleicher Weise zu belasten.

Durch die Arbeitsweise von ZFS sind permanente Snapshots im produktiven Betrieb ein großer Vorteil.

Empfohlene Snapshot-Strategie

Für automatische Snapshots eignen sich beispielsweise zfs-auto-snapshot oder CV4PVE als Web-GUI für Proxmox VE.

Für Aufbewahrungszeiten über drei Monate hinaus eignet sich zusätzlich die tägliche Sicherung mit dem Proxmox Backup Server.

Wichtig: Das System sollte nicht dauerhaft über 80 % belegt werden. Bei zu hoher Belegung müssen Aufbewahrungszeiten reduziert werden.

Proxmox Backup Server: Segen und Risiko

Der Proxmox Backup Server ist ein hervorragendes Sicherungswerkzeug für virtuelle Maschinen und Linux-Container auf Proxmox VE. Er bietet inkrementelle Backups, Deduplizierung, Verifizierung und effiziente Wiederherstellung.

Das Standarddesign sieht allerdings vor, dass Proxmox VE seine Sicherungen zum Proxmox Backup Server schiebt. Dadurch entsteht im Ernstfall Angriffsfläche, wenn Zugangsdaten oder Berechtigungen zu weit gefasst sind.

Der Backup-Benutzer sollte ausschließlich Sicherungs- und Wiederherstellungsrechte besitzen.

2FA, ein API-Token mit minimalen Rechten und deaktivierter SSH-Passwortlogin sind Pflicht.

Typische Probleme im Standardbetrieb

Der Miyagi-Workflow

Der Miyagi-Workflow kombiniert Proxmox Backup Server, ZFS-Replikation, Wartung, Updates, Verifizierung und Monitoring in einem Ablauf.

Das Ziel ist ein Backupserver an einem anderen Standort, der nur für den Sicherungslauf aktiv ist, die Sicherungen kontrolliert, Replikate erstellt und anschließend wieder herunterfährt.

Voraussetzungen

Bashclub Postinstaller:

https://github.com/bashclub/proxmox-zfs-postinstall

Proxmox Backup Server vorbereiten

SSH-Zugriff vorbereiten

Wichtige Hinweise zur PBS-Konfiguration

Kein NFS als Datastore für Proxmox Backup Server verwenden.

Optional kann beim Booten ein iSCSI-LUN von Synology oder einem anderen System eingebunden werden, wenn keine lokalen Platten genutzt werden.

@reboot iscsiadm --mode node --targetname "iqn.2xxxx" --portal "10.ipsyn...:3260" --login && zpool import -f iscsi

ZFS-Pool und Dataset für PBS erstellen

Bei direkter Nutzung von Festplatten:

zpool create -f iscsi /dev/sdx -o autoexpand=on
zfs create iscsi/pbsstore -o recordsize=1M -o com.sun:auto-snapshot=false

Bei nativ installiertem PBS:

zfs create rpool/pbsstore -o recordsize=1M -o com.sun:auto-snapshot=false

Die Festplatten sollten idealerweise über /dev/disk/by-id eingebunden werden.

Datastore im Proxmox Backup Server anlegen

Datastore in Proxmox VE einrichten

In Proxmox VE wird ein neuer Datastore vom Typ Proxmox Backup Server eingerichtet.

Proxmox Backup Server Datastore in Proxmox VE einrichten

Danach sollte direkt aus einer VM oder einem LXC ein Testbackup ausgeführt werden.

Achtung: Proxmox VE setzt den Store local standardmäßig teilweise auf Typ Backup. Das sollte dringend deaktiviert werden.

Miyagi installieren

Die Installation erfolgt auf dem Proxmox Backup Server.

apt install git open-iscsi
git clone -b dev https://github.com/bashclub/miyagi-pbs-zfs.git
cd miyagi-pbs-zfs
cp config.example ipdeinespve.conf
nano ipdeinespve.conf

Das Miyagi-Script sichert einen Proxmox VE Host mit maximal zwei ZFS-Pools auf ein Ziel. Für weitere Hosts oder Pools werden einfach mehrere Konfigurationsdateien verwendet.

Beispielkonfiguration

SSHPORT='22'

BACKUPSERVER=yes
MAINTDAY=6
SHUTDOWN=yes
UPDATES=yes

SOURCEHOST='dein-pve-ip'

# ZFS-Replikation
ZFSROOT='rpool/data'
ZFSSECOND='rpool-hdd/data'
ZFSTRGT='rpool/repl'

ZPOOLSRC=rpool
ZPOOLDST=rpool

# ZSYNC für ZFS-Replikation
ZPUSHTAG=bashclub:zsync
ZPUSHMINKEEP=3
ZPUSHKEEP=14
ZPUSHLABEL=zsync
ZPUSHFILTER="daily,weekly,monthly"

# Backup
PBSHOST='ip-des-pbs'
BACKUPSTORE=backup
BACKUPSTOREPBS=backup
BACKUPEXCLUDE='99999'

Wichtige Parameter

Testlauf durchführen

/root/miyagi-pbs-zfs/pbs-zfs-daily.sh -c /root/miyagi-pbs-zfs/192.x.x.x.conf

Die Ausgabe sollte zuerst die ZFS-Replikation und anschließend das Proxmox-Backup anzeigen. Danach fährt der Server bei entsprechender Konfiguration herunter.

Kontrolle des Testlaufs

Proxmox Backup Server

ZFS-Replikation auf dem PBS prüfen

checkzfs --sourceonly

Alternativ:

checkzfs --source ippve --filter rpool/data --threshold 1500,2000 --columns +message

ZFS-Replikation auf dem PVE prüfen

cat /var/lib/check_mk_agent/spool/*

Monitoring mit Checkmk

Ein zentraler Bestandteil des Workflows ist das Monitoring ohne Fehlerquote. Backups und Replikationen sollen nicht nur laufen, sondern zuverlässig überwacht werden.

Service Discovery auf Proxmox VE

Checkmk Service Discovery für Proxmox Backup Status

Dieser Dienst zeigt den Status des letzten Backups.

Checkmk Kontrolle von ZFS Replikationen

Dieser Dienst zeigt alle Quelldatasets und Volumes. Wenn innerhalb eines Tages keine neuen Daten kommen, geht der Status auf Unknown.

Ausgeschalteten Miyagi-Server überwachen

Da der Sicherungsserver nach Abschluss herunterfahren kann, wird in Checkmk ein eigener Host angelegt.

Checkmk Host für ausgeschalteten Miyagi Backupserver

Nach der Service Discovery erscheint der entsprechende Status.

Checkmk Miyagi Backup Monitoring

Damit bleibt auch ein ausgeschalteter Backupserver kontrollierbar. Wenn innerhalb eines Tages keine neuen Daten eintreffen, geht der Status auf Unknown.

Warum dieser Ansatz trojanersicherer ist

Der zentrale Vorteil liegt in der Kombination mehrerer Schutzebenen:

Fazit

Mit Proxmox VE, ZFS, Proxmox Backup Server, Miyagi und Checkmk entsteht ein sehr robuster Backup- und Replikationsworkflow für kleine und mittlere Unternehmen.

Die Lösung kombiniert eine lange Backuphistorie mit schnell startfähigen Replikaten und einer zentralen Überwachung. Damit lassen sich Ausfälle, Bedienfehler und Ransomware-Schäden deutlich besser beherrschen.

Passende Schulungen

Wenn Sie diesen Workflow im Detail verstehen oder gemeinsam aufbauen möchten, passen besonders diese Kurse auf cloudistboese.de:

Migration Univention Corporate Server & Kopano nach Zamba AD & Mailcow

Univention Corporate Server durch Zamba AD und Mailcow ersetzen

Migration von Univention UCS und Kopano zu Zamba Active Directory, Mailcow und Proxmox VE. Viele kleinere Unternehmen nutzen Univention Corporate Server hauptsächlich als Domain Controller und Benutzerverwaltung. Wenn UCS nur noch als Active Directory dient und Kopano ohnehin abgelöst werden soll, ist der Betrieb häufig unnötig aufwendig.

Mit Zamba Active Directory, Mailcow, Proxmox VE, optional Proxmox Mail Gateway und Mailpiler lässt sich eine schlanke, moderne Open-Source-Infrastruktur aufbauen, die schneller wartbar ist und sich ideal für kleine und mittlere Unternehmen eignet.

Updates von Mailcow und Zamba AD Controller laufen künftig in wenigen Minuten statt in mehreren Stunden.

Kunden, die Keycloak oder eine vollständig vom Hersteller supportete UCS-Umgebung benötigen, sollten weiterhin bei Univention bleiben.

Passende Kurse finden Sie auf cloudistboese.de unter den Themen Mailcow, Domain Controller ablösen und Alles ohne Windows.

Vorteile der Migration

Systemvoraussetzungen

Übersicht der Migration

  1. Zamba Active Directory als zweiten Domain Controller installieren
  2. Active Directory replizieren und prüfen
  3. DNS auf den neuen Domain Controller umstellen
  4. Mailcow installieren
  5. LDAP-Anbindung in Mailcow konfigurieren
  6. Benutzer und Mailboxen synchronisieren
  7. Mails von Kopano nach Mailcow migrieren
  8. Kalender und Kontakte übernehmen
  9. Aliase und Weiterleitungen prüfen
  10. Mailcow produktiv schalten
  11. FSMO-Rollen übernehmen
  12. Univention UCS demoten und abschalten
  13. LDAP-Clients auf den neuen Zamba AD umstellen

Zamba Active Directory als zweiten Domain Controller installieren

Die Installation erfolgt auf dem Proxmox Host, zum Beispiel im Verzeichnis /root.

git clone -b dev https://github.com/bashclub/zamba-lxc-toolbox
cd zamba-lxc-toolbox
cp conf/zamba.conf.example conf/zamba.conf

zamba.conf anpassen

In der Datei conf/zamba.conf werden die Werte an die bestehende Umgebung angepasst.

LXC_TEMPLATE_STORAGE="local"
LXC_ROOTFS_SIZE="32"
LXC_ROOTFS_STORAGE="rpool-data"
LXC_SHAREFS_SIZE="100"
LXC_SHAREFS_STORAGE="rpool-data"

LXC_HOSTNAME="zmb-ad"
LXC_DOMAIN="windomain.local"
LXC_IP="10.0.0.254/24"
LXC_GW="10.0.0.1"
LXC_DNS="10.0.0.4"

LXC_BRIDGE="vmbr0"
LXC_PWD='Admin123'

ZMB_REALM="WINDOMAIN.LOCAL"
ZMB_DOMAIN="WINDOMAIN"
ZMB_ADMIN_USER="administrator"
ZMB_ADMIN_PASS='Admin123'

Hinweis: LXC_DNS zeigt zunächst auf den alten UCS-DNS-Server. Bei Windows-Domänen sollte vorher gegebenenfalls das Funktionslevel geprüft werden.

Zamba AD Join starten

bash install.sh -i 100

Im Menü wird Zamba-AD-Join gewählt.

Replikation prüfen

Nach der Installation kann der Container betreten und die Replikation geprüft werden.

pct enter 100
su -
wbinfo -u
wbinfo -g

Wenn alle Benutzer und Gruppen angezeigt werden, ist der Join grundsätzlich erfolgreich.

Empfehlung: In Proxmox sollte anschließend der alte UCS-DNS-Server aus der Hostkonfiguration entfernt werden, sobald der neue Zamba AD DNS zuverlässig funktioniert.

smb.conf anpassen

Folgende Anpassungen können in der smb.conf hilfreich sein:

vi /etc/samba/smb.conf
[global]
ldap server require strong auth = no
dns forwarder = 1.1.1.1 1.0.0.1

DNS auf den neuen Domain Controller umstellen

DNS ist bei Active Directory fast immer der kritischste Punkt. Sobald der neue Zamba Domain Controller sauber repliziert, werden feste IP-Konfigurationen und DHCP-Einstellungen angepasst.

Merksatz: It was DNS.

Mailcow installieren

Für Mailcow wird ein weiterer LXC verwendet. Die Installation erfolgt ebenfalls über die Zamba LXC Toolbox.

cp conf/zamba.conf.example conf/zamba.conf

Für Mailcow müssen insbesondere Hostname und Netzwerkeinstellungen angepasst werden.

bash install.sh -i 101

Im Menü wird Mailcow gewählt.

Mailcow aktualisieren

pct enter 101
su -
cd /opt/mailcow-dockerized
apt install jq
./update.sh

Danach wird das Mailcow-Webinterface geöffnet:

https://10.0.0.253/admin

Grundkonfiguration von Mailcow

Unbedingt notwendige Schritte

LDAP in Mailcow konfigurieren

Die LDAP-Anbindung erfolgt unter:

System / Konfiguration / Zugang / Identity Provider

Der Erfolg wird unter E-Mail / Mailboxen kontrolliert.

E-Mails von Kopano nach Mailcow migrieren

Die Migration erfolgt über IMAP-Synchronisation.

Mailcow Sync Job erstellen

In Mailcow:

E-Mail / Synchronisationen / Neuen Sync Job erstellen

Kopano hat standardmäßig IMAP teilweise deaktiviert. In der server.conf nach disable suchen oder in UMC beim Benutzer unter Kopano IMAP aktivieren.

Der Erfolg der Synchronisation sollte im Dialog und in den Logs kontrolliert werden.

Kalender aus Kopano exportieren

Kopano stellt Kalender über CalDAV bereit. Beispiele:

http://kopano:8080/caldav/<user>/<folder-name>/ Kalender oder Aufgabenordner im Benutzerpostfach
http://kopano:8080/caldav/<user>/<sub-folder>/ Selbst erstellter Unterkalender
http://kopano:8080/caldav/<other-user>/<folder-name>/ Freigegebener Kalender eines anderen Benutzers
http://kopano:8080/caldav/public/<foldername>/ Öffentlicher Kalender
http://kopano:8080/caldav/<user>/ Standardkalender des Benutzers

Die exportierten Dateien können anschließend im SOGo-Frontend oder in einem Mailclient importiert werden.

Kontakte exportieren und importieren

Kontakte exportieren

Der Export kann über den alten Mailclient erfolgen. Alternativ kann ein Python-Script mit Kopano-MAPI genutzt werden.

sudo apt install python3-kopano
mkdir export
wget https://raw.githubusercontent.com/bashclub/trmm-scripts/refs/heads/main/kopano-export-contacts.py
python3 kopano-export-contacts.py

Das Script exportiert Kontakte in Unterordner pro Benutzer, da Kopano kein echtes CardDAV für diesen Zweck bereitstellt.

Kontakte importieren

Beispiel für CardDAV-Anbindung:

https://kunde.dyndns.org/SOGo/dav/user@domain.de/Contacts/personal/

Aliase und Weiterleitungen übernehmen

Aliase finden

univention-ldapsearch -LLL | grep @ | grep mailAlternative

Aliase werden in Mailcow unter E-Mail / Aliasse / Alias hinzufügen eingetragen.

Weiterleitungen finden

univention-ldapsearch -LLL | grep mailForward

Weiterleitungen werden im SOGo-Webfrontend unter E-Mail konfiguriert, nicht direkt in Mailcow.

Mailcow produktiv schalten

NAT und Portweiterleitungen

Auf der Firewall, zum Beispiel OPNsense, können Aliase verwendet werden.

p_mailcow: 80 443 465 993 4190
h_mailcow: 10.0.0.253

Port Forwarding:

any > WAN IP > p_mailcow > h_mailcow

Mailcow neu starten

pct enter 101
su -
rm /opt/mailcow-dockerized/data/conf/nginx/redirect.conf
cd /opt/mailcow-dockerized
docker compose down

Optional: Greylisting deaktivieren

vi /opt/mailcow-dockerized/data/conf/rspamd/local.d/greylist.conf
enabled = false;

Optional: Let’s Encrypt Einstellungen

vi /opt/mailcow-dockerized/mailcow.conf
SKIP_LETS_ENCRYPT=n
SKIP_HTTP_VERIFICATION=y
docker compose up -d

Let’s Encrypt kontrollieren

docker compose logs --tail=200 -f acme-mailcow

Alternativ eigenes Zertifikat verwenden

Eigene Zertifikate können hier abgelegt werden:

/opt/mailcow-dockerized/data/assets/ssl

Danach DNS-Werte beim Provider kontrollieren:

E-Mail / Domains / DNS

Abschluss der Migration

FSMO-Rollen übernehmen

pct enter 100
su -
samba-tool fsmo transfer --role=all -Uadministrator
samba-tool domain demote --remove-other-dead-server=UCS
rm /etc/cron.d/sysvol-sync

Bereinigung

LDAP-Clients anpassen

Für bestehende LDAP-Clients werden neue Bind-User pro Rolle angelegt. Anschließend werden die LDAP-Parameter angepasst.

Proxmox Mail Gateway mit Mailcow verbinden

Greylisting in Mailcow deaktivieren

vi /opt/mailcow-dockerized/data/conf/rspamd/local.d/greylist.conf
enabled = false;
docker compose restart rspamd-mailcow

Routing in Mailcow

Senderabhängige Transport Maps

Proxmox Mail Gateway

Beim DNS-Provider werden die PMG-Werte statt der direkten Mailcow-Werte gesetzt.

Mailpiler als Mailarchiv integrieren

Mailpiler kann ebenfalls über die LXC Toolbox installiert werden.

Mailcow für Archivweiterleitung vorbereiten

BCC an das Archiv

BCC-Maps einrichten

Unter:

E-Mail / Konfiguration / Adressumschreibung / BCC-Maps

Für jede Maildomain jeweils eingehend und ausgehend:

Kontrolle im Mailpiler:

tail -f /var/log/mail.log

Eine LDAP-Anpassung im Mailpiler wäre in config-site.php möglich, funktioniert jedoch nicht zuverlässig für Aliase.

Doppelte Mails bei mehrfacher Kopano-Synchronisation vermeiden

Die IMAP-Kompatibilität von Kopano ist in der Praxis oft problematisch. Wenn Mails doppelt oder dreifach erscheinen, kann eine gezielte Bereinigung und erneute Synchronisation helfen.

apt install kopano-migration-imap
nano migrate.sh
#!/bin/bash

set -euo pipefail

if [ "$#" -ne 6 ]; then
  echo "Verwendung:"
  echo "$0 <host1> <host2> <user1> <pass1> <user2> <pass2>"
  exit 1
fi

HOST1="$1"
HOST2="$2"
USER1="$3"
PASS1="$4"
USER2="$5"
PASS2="$6"

MAILCOW_DOVECOT_CONTAINER="565cef8dac49"

echo "=========================================="
echo "Bereinige Zielordner auf Mailcow"
echo "=========================================="

docker exec "$MAILCOW_DOVECOT_CONTAINER" \
  doveadm expunge -u "$USER2" mailbox "Gesendet" ALL || true

docker exec "$MAILCOW_DOVECOT_CONTAINER" \
  doveadm mailbox delete -u "$USER2" "Sent" || true

docker exec "$MAILCOW_DOVECOT_CONTAINER" \
  doveadm mailbox delete -u "$USER2" "Gesendete Objekte" || true

docker exec "$MAILCOW_DOVECOT_CONTAINER" \
  doveadm mailbox delete -u "$USER2" "Gesendete Objekte/Gesendete Objekte" || true

echo "=========================================="
echo "Starte IMAP Sync"
echo "=========================================="

kopano-migration-imap \
  --host1 "$HOST1" \
  --host2 "$HOST2" \
  --user1 "$USER1" \
  --password1 "$PASS1" \
  --user2 "$USER2" \
  --password2 "$PASS2" \
  --ssl1 \
  --ssl2 \
  --regextrans2 's#^Gel&APY-schte Objekte$#Papierkorb#' \
  --useheader Message-Id \
  --addheader \
  --usecache \
  --syncinternaldates \
  --skipsize \
  --nofoldersizes \
  --nofoldersizesatend \
  --delete2 \
  --delete2folders \
  --delete2duplicates \
  --exclude '(?i)^trash$|^junk$|^spam$|^unwanted$|^&U3CPbg-($|/)'

echo "=========================================="
echo "Migration abgeschlossen"
echo "=========================================="

Ausführen mit:

bash migrate.sh quellip zielip login passwortucs email@adresse.de passwortmailcow

Das Beispiel nimmt keine Papierkörbe oder Spam-Ordner mit. Dies wird über --exclude gesteuert.

Optionale DNS-Einträge für Autokonfiguration

Für Thunderbird, eM Client und weitere Programme können SRV-Records gesetzt werden, damit Mail, Kalender und Kontakte automatisch gefunden werden.

_autodiscover._tcp  IN  SRV  0 0 443 q.deine-domain.de.
_caldavs._tcp       IN  SRV  0 1 443 q.deine-domain.de.
_carddavs._tcp      IN  SRV  0 1 443 q.deine-domain.de.
_imaps._tcp         IN  SRV  0 1 993 q.deine-domain.de.
_matrix._tcp        IN  SRV  0 1 465 matrix.deine-domain.de.
_sieve._tcp         IN  SRV  0 1 4190 mail.deine-domain.de.
_smtps._tcp         IN  SRV  0 1 465 q.deine-domain.de.
_submissions._tcp   IN  SRV  0 1 465 q.deine-domain.de.

Fazit

Mit Zamba Active Directory, Mailcow und Proxmox VE lässt sich eine bestehende Univention-/Kopano-Umgebung vollständig durch moderne Open-Source-Komponenten ersetzen. Für kleine und mittlere Unternehmen entsteht eine schlanke, wartbare und zukunftssichere Infrastruktur.

Passende Schulungen

Wenn Sie die Migration unter Anleitung durchführen möchten, finden Sie passende Live-Schulungen auf cloudistboese.de:

Virtuelle Maschine mit Windows 10 Bios auf Proxmox zu Windows 11 mit UEFI umstellen

Windows 11 Migration Bios zu UEFI

Win11 Upgrade BIOS -> UEFI ist keine einfache Aufgabe
Auch wenn es Workarounds gibt, möchten wir für virtuelle Windows 11 Maschinen die maximale Lebensspanne an Upgrades. Daher passen wir das System im Bereich Partitionstabelle, TPM und virtuelle Hardware an

Systemplatte erweitern

In Proxmox großzügig die Platte, wenn Thin Provisioning aktiviert ist, erweitern.

Danach die Partition in Windows vergrößern, da wir am Ende Platz für eine EFI Partition benötigen!

BCD neu schreiben

bcdboot c:\windows /s c: /f all

Win Part als aktiv markieren

diskpart
select disk 0
select part 2
active

Disk zu GPT konvertieren

mbr2gpt.exe /convert /allowFullOS /disk:0

VM Shutdown und neu konfigurieren

image.png

VM einschalten

Shutdown

VM Starten

Stand der Technik nach DSGVO am Beispiel Kopano - Was sagt ChatGPT?

Auf Nachfrage interessierte mich die Meinung von ChatGPT zum Thema Übergangsfristen für abgelaufene Software, wie z. B. Kopano u. Ä. Nicht immer schafft man rechtzeitig die Migration auf aktuelle Systeme, meist wegen der Absprachen und Termin- und Kostengespräche mit Kunden

Nach der Datenschutz-Grundverordnung (DSGVO) gibt es keine ausdrücklichen Übergangsfristen für die Pflicht, Serversoftware auf dem Stand der Technik zu halten. Die Verordnung trat am 25. Mai 2018 in Kraft und gilt seither unmittelbar in allen EU-Mitgliedstaaten.

Was bedeutet "Stand der Technik" laut DSGVO?

Die DSGVO verlangt in Art. 32 Abs. 1 von Verantwortlichen und Auftragsverarbeitern geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Dabei ist „der Stand der Technik“ ein zentrales Kriterium.

Das bedeutet konkret:

Gibt es trotzdem Spielräume oder Fristen?

Zwar gibt es keine festen Fristen in der DSGVO, aber:

Beispiele:

Software Stand der Technik? Kommentar
Ubuntu 20.04 Ja (bis 2025) Unterstützt, wenn regelmäßig aktualisiert
Windows Server 2012 R2 Nein (EOL) Nicht mehr sicher, nicht DSGVO-konform
Apache 2.2 Nein Veraltet, seit Jahren nicht mehr unterstützt
Nextcloud (aktuelle LTS-Version) Ja Regelmäßige Updates, DSGVO-konform

Fazit:

Wenn du willst, kann ich dir eine Checkliste zur DSGVO-konformen Server-Softwarepflege erstellen.

 

Das Problem mit Kopano Groupware unter Univention Corporate Server (UCS) 5.0 liegt mittelfristig vor allem beim Thema "Stand der Technik" im Sinne der DSGVO – insbesondere in Bezug auf:

🔧 1. Veraltete Softwarebasis von Kopano

➡️ Risiko: Wenn Sicherheitslücken bekannt werden und keine Updates folgen, ist der „Stand der Technik“ nicht mehr gegeben.

📦 2. Eingeschränkte oder fehlende Wartung im UCS App Center

➡️ Risiko: Kein garantierter Support, keine klare Roadmap, und Integration in UCS nur noch teilweise gepflegt.

🔒 3. Unklare Sicherheitsgarantie & Datenschutzfolgeabschätzung

➡️ Risiko: Du trägst die volle Haftung bei Datenpannen – auch wenn die Ursache eine nicht gewartete Drittsoftware ist.

📆 4. Abhängigkeit von veralteten Komponenten

➡️ Risiko: Du bleibst auf alten Softwareständen – was DSGVO-widrig ist.

✅ Fazit: Wo ist mittelfristig das Problem?

Bereich Risiko DSGVO-Auswirkung
Sicherheitspatches fehlen Hoch Kein „Stand der Technik“
Keine Updates über App Center Mittel Wartung erschwert
Keine klare Produkt-Roadmap Hoch Planbarkeit & DSFA unmöglich
Technische Abhängigkeiten Mittel bis hoch Zunehmende Inkompatibilität

🔄 Empfehlung

Wenn du Kopano (noch) nutzt:

Wenn du möchtest, kann ich dir eine Migrations-Checkliste oder Alternativen zu Kopano unter UCS zusammenstellen.

Information zur Sicherung und Wiederherstellung von Windows 10/11-Systemen

Information zur Sicherung und Wiederherstellung von Windows 10/11-Systemen

Bitte nehmt zur Kenntnis, dass die Sicherung und der Ersatz (z. B. Austausch der Hardware) eines Windows 10- oder Windows 11-PCs inzwischen sehr problematisch sein kann.

Hintergrund

Neue Windows 11-Systeme verschlüsseln die Festplatte standardmäßig.
Der Verschlüsselungsschlüssel ist dabei an die Hardware (Trusted Platform Module, TPM) gebunden.

Das bedeutet:

Mögliche Vorgehensweisen

1. Kein Bedarf an Verschlüsselung (z. B. PC steht in verschlossenen Räumen)

2. Bedarf an Verschlüsselung (z. B. bei mobilen Geräten)

3. Zentrale Sicherung der BitLocker-Schlüssel über Gruppenrichtlinie (GPO)

In einer Active-Directory-Umgebung können BitLocker-Wiederherstellungsschlüssel automatisch im AD gespeichert werden.
Dies ermöglicht eine zentrale Verwaltung und Wiederherstellung der Schlüssel, auch wenn ein Benutzer den lokalen Key verliert.

Einrichtung (Kurzfassung):

  1. GPO öffnen →
    Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → BitLocker-Laufwerkverschlüsselung

  2. Unter Betriebssystemlaufwerke Richtlinie aktivieren:
    „Wiederherstellungsinformationen in Active Directory Domain Services speichern“

  3. Optional: Speicherung erzwingen, bevor Verschlüsselung beginnt.

  4. Anwendung prüfen mit gpupdate /force.

Hinweis: In Azure AD-Umgebungen werden die Schlüssel standardmäßig im Benutzerkonto im Azure-Portal hinterlegt.

Hinweise zur Datensicherung


Hier der technische Nachweis

Zugriff auf die frisch mit Windows 11 24H2 installierte Festplatte.

root@PVE250:~# mount /dev/zvol/rpool/data/vm-101-disk-1-part3 /mnt/restore/
mount: /mnt/restore: unknown filesystem type ‚BitLocker‘.

image.png

 

image.png

 

ZFS Grundlagen am Beispiel Proxmox VE(Stand Dezember 2025)

ZFS Grundlagen mit Proxmox VE – Praxiswissen für sichere Server, Backups und Storage-Systeme

Erfahrung aus rund 150 produktiven Proxmox- und ZFS-Systemen

Der Verfasser dieser Dokumentation, Christian-Peter Zengel, verfügt über rund 18 Jahre Praxiserfahrung mit ZFS und Proxmox und betreibt aktuell etwa 150 Systeme mit Proxmox VE und ZFS.

Die hier beschriebenen Erfahrungen stammen aus realen Installationen – von einzelnen Standalone-Servern bis zu Proxmox-Clustern mit bis zu zehn Hosts.

Der Fokus liegt auf ZFS als robuste, sichere und wirtschaftliche Storage-Grundlage für kleine und mittlere IT-Umgebungen.

Warum ZFS für Proxmox, TrueNAS und Linux-Server?

ZFS ist eine ideale Grundlage für Systeme, bei denen Datenintegrität, Snapshots, Replikation und schnelle Wiederherstellung entscheidend sind. Gerade bei Proxmox VE, TrueNAS, Backup-Servern und Fileservern bietet ZFS erhebliche Vorteile gegenüber klassischen RAID-Controllern oder einfachen Dateisystemen.

In der Praxis zeigt sich ZFS für viele kleine und mittlere Systeme einfacher, vielseitiger, schneller und günstiger als Ceph. Eine produktive Ceph-Expertise wird hier bewusst nicht behauptet; intern wird jedoch intensiv an passenden Hauslösungen gearbeitet.

ZFS Onlinekurs und Schulung

Diese Dokumentation basiert auf einem Onlinekurs von cloudistboese.de. Die ZFS-Grundlagenkurse werden regelmäßig angeboten und vermitteln die wichtigsten Konzepte für den sicheren Einsatz von ZFS mit Proxmox VE, TrueNAS und vergleichbaren Systemen.

ZFS Grundlagen Onlinekurs von cloudistboese.de für Proxmox VE, TrueNAS und Linux Storage

Aktuelle ZFS-Kurse und weitere Open-Source-Schulungen auf cloudistboese.de ansehen

Die Wiederholung der Onlinekurse sowie der Zugriff auf Aufzeichnungen sind für Kursteilnehmer kostenlos.

Inhalte des ZFS-Grundlagenkurses

ZFS ist die perfekte Grundlage, um kleine und mittlere Systeme gegen Ausfälle, Fehlbedienung und Verschlüsselungstrojaner besser abzusichern.

Der Kurs vermittelt Grundkenntnisse für den praktischen Einsatz mit:

Themen im Überblick

Nach diesem Kurs sind Sie bei Ausfällen, Bedienfehlern und Datenverlust deutlich besser vorbereitet und können viele Systeme innerhalb weniger Minuten wieder produktiv machen.

ZFS RAID mit zpool erstellen

So erstellt Proxmox VE einen ZFS Mirror

zpool create -f -o cachefile=none -o ashift=12 rpool mirror disk1 disk2

Die wichtigsten Parameter:

Mögliche RAID-Varianten sind unter anderem:

Praxisumgebung im Kurs

Im Kurs wird ein älterer Supermicro-Server mit 24 Einschüben sowie zwei NVMe-Datenträgern verwendet. Damit lassen sich verschiedene ZFS-Szenarien realistisch abbilden.

Die Verwendung gebrauchter und teilweise ungetesteter Datenträger zeigt sehr schnell, warum ZFS in der Praxis so wertvoll ist.

Empfehlung: Für produktive Systeme immer Enterprise-NVMe und ECC-RAM verwenden.

Supermicro Server mit vielen Laufwerkseinschüben für ZFS und Proxmox VE Schulung

Bereits verwendete Datenträger können in Proxmox VE über die Wipe-Funktion bereinigt werden. Bei alten LVM- oder Ceph-Installationen empfiehlt sich jedoch häufig eine vorherige vollständige Löschung, beispielsweise mit nwipe.

Proxmox VE Wipe Funktion zum Löschen alter Datenträger vor ZFS Nutzung

Proxmox VE Bootlayout mit ZFS verstehen

Proxmox VE nutzt bei ZFS-Installationen ein spezielles Bootlayout. Wichtig ist, dass immer ausreichend bootfähige Datenträger mit passendem Partitionslayout vorhanden sind.

Typischerweise gibt es:

Wird später unbedacht mit ganzen Disks gearbeitet, kann es passieren, dass keine geeignete Bootstruktur mehr vorhanden ist.

Proxmox VE ZFS Bootlayout mit proxmox-boot-tool und Partitionen

Laufwerke unter Linux eindeutig ermitteln

Vor dem Erstellen eines ZFS-Pools müssen die Laufwerke eindeutig identifiziert werden. Dafür eignen sich unter Linux mehrere Werkzeuge.

apt install lshw iotop

# Detaillierte Übersicht aller Laufwerke
lshw -class disk

# Liveansicht beim Einschieben von Festplatten
dmesg -Tw

# Eindeutige Laufwerksnamen über by-id anzeigen
ls -althr /dev/disk/by-id

Beispiel: lshw

Linux lshw Ausgabe zur Ermittlung von Festplatten für ZFS

Beispiel: /dev/disk/by-id

Linux Verzeichnis /dev/disk/by-id mit eindeutigen Festplattennamen für ZFS

Wichtige Entscheidungen beim Anlegen eines ZFS-Pools

Die wichtigsten Entscheidungen beim Anlegen eines ZFS-Pools sind:

Fehler an dieser Stelle lassen sich später häufig nur mit erheblichem Aufwand korrigieren.

RAID-Level: Mirror, RAID10 oder RAIDZ?

Mirror und Striped Mirror

Mirror und Striped Mirror sind für Proxmox VE meist die unproblematischste Wahl. Sie kosten zwar 50 % der Rohkapazität, bieten aber hohe Performance, einfache Erweiterbarkeit und sehr gute Wiederherstellbarkeit.

RAIDZ1, RAIDZ2 und RAIDZ3

RAIDZ bietet mehr nutzbare Kapazität, ist aber für VMs und LXCs auf drehenden Festplatten nur eingeschränkt geeignet.

Virtuelle Maschinen sollten im Normalfall nicht auf drehenden Festplatten mit RAIDZ betrieben werden. Als Kompromiss kann RAIDZ mit NVMe Cache und Logdevice eingesetzt werden.

Ashift richtig wählen

Bei ZFS bezeichnet ashift die interne Sektorgröße eines VDEVs. Früher wurde häufig mit ashift=9 für 512-Byte-Sektoren gearbeitet. Für heutige Datenträger ist ashift=12 praktisch immer die richtige Wahl.

Empfehlung: Aktuell immer ashift=12 verwenden.

Eine falsche Einstellung kann zu massiven Leistungseinbußen und erheblicher Platzverschwendung führen.

Technischer Hintergrund zu ZFS ashift

Kompression mit ZFS

ZFS-Kompression kann erheblich Speicherplatz sparen, insbesondere bei Datenbanken, Logs, Textdateien, VM-Images und vielen Serverdaten.

Unsere heutige Empfehlung:

zfs set compression=on poolname/dataset

Früher wurde häufig explizit compression=lz4 gesetzt. In vielen aktuellen Umgebungen ist compression=on sinnvoll und ausreichend.

In der Praxis sparen wir damit häufig ein Drittel oder mehr Speicherplatz – ohne spürbare Geschwindigkeitseinbußen.

ZFS Dataset-Struktur für Proxmox VE

Nach dem Erstellen eines Pools sollte nicht einfach der Pool selbst als Proxmox Storage verwendet werden. Besser ist eine saubere Struktur mit getrennten Datasets.

zfs create mirror500g/data
zfs create mirror500g/clone
zfs create -o com.sun:auto-snapshot=false mirror500g/repl

Danach kann der Storage in Proxmox VE sauber als beispielsweise mirror500g-data eingebunden werden.

Proxmox VE ZFS Storage Dataset Struktur für VMs und Container

Praxisbeispiele: zpool create

Stripe / RAID0

Nur für Testsysteme oder Daten ohne Schutz sinnvoll.

zpool create -f test \
wwn-0x5000cca01a72ded4 \
wwn-0x5000cca01a7b1e2c \
wwn-0x5000cca01a83a61c

Mirror / RAID1

zpool create -f test mirror \
wwn-0x5000cca01a72ded4 \
wwn-0x5000cca01a7b1e2c

Striped Mirror / RAID10

zpool create -f test \
mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c \
mirror wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24 \
mirror wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8

RAIDZ1

zpool create test raidz \
wwn-0x5000cca01a72ded4 \
wwn-0x5000cca01a7b1e2c \
wwn-0x5000cca01a83a61c \
wwn-0x5000cca01a832d24 \
wwn-0x5000cca01a83331c \
wwn-0x5000cca01a7495b8

RAIDZ2

zpool create test raidz2 \
wwn-0x5000cca01a72ded4 \
wwn-0x5000cca01a7b1e2c \
wwn-0x5000cca01a83a61c \
wwn-0x5000cca01a832d24 \
wwn-0x5000cca01a83331c \
wwn-0x5000cca01a7495b8

RAIDZ mit mehreren VDEVs

zpool create test \
raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c \
raidz wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8

Dry-Run vor dem Anlegen

Vor destruktiven Aktionen immer prüfen:

zpool create -n test mirror disk1 disk2

ZFS Cache, ARC, L2ARC und Logdevice

ARC – Cache im RAM

Der ARC ist der First-Level-Cache von ZFS und nutzt RAM. Als grobe Praxisregel kann man etwa 1 GB RAM pro 1 TB Netto-Daten ansetzen. Entscheidend ist jedoch immer der konkrete Einsatzzweck.

arcstat 1

arcstat Ausgabe zur Analyse des ZFS ARC Cache

L2ARC – zusätzlicher Lesecache

Ein L2ARC kann als schneller Lesecache auf SSD oder NVMe eingesetzt werden. Er ist besonders interessant, wenn der Arbeitsspeicher nicht ausreicht und viele wiederkehrende Lesezugriffe auftreten.

zpool add test cache /dev/disk/by-id/nvme-cache-device

SLOG / Logdevice

Ein Logdevice kann synchrone Schreibzugriffe beschleunigen, muss aber zwingend zuverlässig und im produktiven Einsatz gespiegelt sein.

zpool add test log mirror /dev/disk/by-id/nvme-log-1 /dev/disk/by-id/nvme-log-2
zfs set sync=always test

ZFS HDD RAID10 mit Cache und gespiegeltem Logdevice

ZFS Special Device

Ein Special Device kann Metadaten und kleine Blöcke auf schnelle SSDs oder NVMes auslagern. Es muss zwingend redundant, also mindestens gespiegelt, aufgebaut werden.

Sinnvoll wird ein Special Device erst mit einer passenden Definition der Blockgröße, beispielsweise für kleine Blöcke bis etwa 64K.

In unseren Tests zeigte ein Special Device vor allem bei Fileservern und LXC-Workloads Vorteile. Im klassischen VM-Betrieb war der Nutzen deutlich geringer.

ZFS Special Device als Mirror für Metadaten und kleine Blöcke

ZFS Special Small Blocks Konfiguration für Fileserver und LXC

ZFS Pool importieren und entfernen

ZFS-Pools können importiert werden, ohne sie zu löschen. Besonders sinnvoll ist der Import über /dev/disk/by-id, damit später im Status eindeutige Laufwerksnamen angezeigt werden.

zpool import

zpool import poolname

zpool import -d /dev/disk/by-id poolname

ZFS Pool Import über Kommandozeile mit zpool import

Datasets und ZVOLs verstehen

Datasets

Datasets werden wie Dateisysteme gemountet und eignen sich für:

ZVOLs

ZVOLs verhalten sich wie virtuelle Blockgeräte. Sie werden unter /dev/zd... und mit sprechenden Namen unter /dev/zvol/poolname/... bereitgestellt.

Sie eignen sich insbesondere für virtuelle Festplatten von VMs.

Anlage eines ZFS ZVOL für virtuelle Maschinen unter Proxmox VE

ZFS Datasets und ZVOLs unter Linux und Proxmox VE

Thin- und Thick-Provisioning mit ZFS

Proxmox VE erzeugt virtuelle Festplatten auf ZFS typischerweise als ZVOLs. Thin Provisioning spart zunächst Speicherplatz, muss aber sorgfältig überwacht werden.

Beispiel: Thin Provisioning für eine VM

zfs create -s -b 16k -V 33554432k rpool/data/vm-301-disk-4

Beispiel: Dataset für LXC

zfs create -o acltype=posixacl -o xattr=sa -o refquota=33554432k rpool/data/subvol-106-disk-1

Bei LXC-Containern ist die Dimensionierung besonders wichtig, da Snapshots und Aufbewahrungszeiten den effektiv nutzbaren Platz beeinflussen.

Virtuelle Diskimages wie QCOW2, VMDK oder RAW-Dateien sollten normalerweise nicht innerhalb eines ZFS-Datasets abgelegt werden, außer bei speziellen NFS- oder iSCSI-Szenarien.

ZFS Pool Features aktualisieren

Wenn zpool status neue ZFS-Funktionen meldet, können diese grundsätzlich aktualisiert werden:

zpool upgrade -a

Wichtig: Vor einem Upgrade sollte geprüft werden, ob vorhandene Notfall-ISOs, Rettungssysteme und andere Hosts die neuen ZFS-Features bereits unterstützen.

ZFS zpool status Hinweis auf neue Pool Features

ZFS Pool Feature Upgrade mit zpool upgrade

ZFS Parameter auslesen

Für Pools, Datasets, Volumes und Snapshots können Eigenschaften mit zfs get ausgelesen werden.

zfs get all poolname
zfs get compression poolname/dataset
zfs get used,available,referenced poolname/dataset

ZFS get Ausgabe zum Auslesen von Pool und Dataset Eigenschaften

Fazit: ZFS als stabile Basis für Proxmox VE

ZFS ist für viele Proxmox-Umgebungen die beste Grundlage, wenn Datensicherheit, Snapshots, Replikation und Wiederherstellbarkeit im Vordergrund stehen.

Für produktive Systeme sind besonders wichtig:

Diese Dokumentation wird fortlaufend erweitert.

ZFS Schulung oder Beratung anfragen

Sie möchten ZFS mit Proxmox VE produktiv einsetzen, bestehende Systeme prüfen oder ein sicheres Storage- und Backup-Konzept entwickeln?

Die sysops GmbH unterstützt bei Planung, Migration, Betrieb, Monitoring und Schulung rund um Proxmox VE, ZFS, Backup und Open Source Infrastruktur.

📧 info@sysops.de
📞 +49 (0) 6021 2125-0

Das Ende von Hetzner DNS Robot und ACME API - Stand Januar 2026

Hetzner DNS Robot Abschaltung 2026 – wichtige Hinweise zu ACME, OPNsense und Proxmox

Wichtige Information für Kursteilnehmer und Kunden

Hallo liebe Kursteilnehmer,

zunächst wünschen wir euch ein frohes neues Jahr 🎉

Bitte schaut euch ergänzend die Sendung „Welche unnötigen Arbeiten müssen dieses Jahr erledigt werden?“ – Live vom 05.01.2026 an. Dort besprechen wir die anstehenden Änderungen, typische Stolperfallen und mögliche Lösungswege rund um DNS, Zertifikate und Automatisierungen.

Hetzner stellt den alten DNS Robot Service im Mai 2026 ein

Wir nutzen den Hetzner Robot DNS Service seit fast 20 Jahren. Dieser Dienst wird von Hetzner im Mai 2026 eingestellt. Bestehende DNS-Zonen müssen in die neue Verwaltung innerhalb der Hetzner Console migriert werden.

Hetzner nennt als Enddatum den 27.05.2026. Neue DNS-Zonen können in der alten DNS Console bereits nicht mehr angelegt werden. Auch bestehende Automatisierungen müssen rechtzeitig geprüft und angepasst werden.

Offizielle Statusmeldung von Hetzner:
Shutdown of DNS Console (dns.hetzner.com) in May 2026

Neue Hetzner Console:
https://console.hetzner.com/projects

Warum ist die Umstellung wichtig?

Viele Systeme erzeugen und verlängern TLS-Zertifikate automatisch per ACME DNS-01 Challenge. Wird dabei noch die alte Hetzner DNS API verwendet, funktionieren diese Automatisierungen spätestens nach der Abschaltung nicht mehr zuverlässig.

Betroffen sein können unter anderem:

Wichtig: Prüft frühzeitig, ob eure Systeme noch den alten Hetzner DNS-Service verwenden. Ab Mai 2026 kann eine nicht angepasste Konfiguration dazu führen, dass Zertifikate nicht mehr verlängert werden.

ACME und Zertifikate – aktueller Stand

Die technische Situation unterscheidet sich je nach eingesetztem System und Version. Bitte prüft deshalb jedes System einzeln und verlasst euch nicht darauf, dass eine funktionierende Konfiguration automatisch zukunftssicher ist.

OPNsense Community Edition

In der OPNsense Community Edition funktioniert die Umstellung nach aktuellem Stand mit dem ACME-Plugin os-acme-client 4.11 und der neuen Hetzner Cloud Console.

Das grundsätzliche Vorgehen:

OPNsense Business Edition

Bei der OPNsense Business Edition ist besondere Vorsicht geboten. Dort kann je nach Release noch eine ältere Version des ACME-Plugins enthalten sein, die die neue Hetzner API noch nicht korrekt unterstützt.

Wenn eure OPNsense Business Edition noch os-acme-client 4.10 verwendet, sollte die ACME-Funktion vor der Umstellung sorgfältig geprüft werden.

Workaround auf eigenes Risiko

Der folgende Workaround funktionierte bei uns im Test. Bitte nur verwenden, wenn ihr wisst, was ihr tut, vorher ein Backup erstellt habt und das Risiko einschätzen könnt.

pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/All/acme.sh-3.1.2.pkg
pkg add -f https://pkg.opnsense.org/FreeBSD:14:amd64/25.7/latest/All/os-acme-client-4.11.pkg

Nach der Installation sollte die ACME-Konfiguration geprüft, die Challenge neu angelegt und eine Testausstellung durchgeführt werden.

Proxmox VE, Proxmox Backup Server und Proxmox Mail Gateway

Auch bei Proxmox VE, Proxmox Backup Server und Proxmox Mail Gateway müssen ACME-Konfigurationen geprüft werden. Entscheidend ist, ob bereits ein DNS-Plugin für die neue Hetzner Cloud DNS API vorhanden ist oder ob noch die alte Hetzner DNS API genutzt wird.

Mögliche Lösungswege

Hinweis: Proxmox VE und Proxmox Backup Server lassen sich in vielen Szenarien über API oder Zertifikatsupload automatisieren. Beim Proxmox Mail Gateway ist die Situation schwieriger, da hierfür keine vergleichbare API für alle notwendigen Schritte zur Verfügung steht.

PMG: Zwei getrennte Automationen notwendig

Für Proxmox Mail Gateway können zwei getrennte Schritte erforderlich sein:

  1. Zertifikat und Schlüssel auf das PMG übertragen
  2. Zertifikat für API und SMTP aktivieren

Beispiel für die Aktivierung auf einem Proxmox Mail Gateway:

sleep 90
pmgconfig cert set api /root/-.sysopservice.net/fullchain.pem /root/-.sysopservice.net/key.pem --force --restart 1
pmgconfig cert set smtp /root/-.sysopservice.net/fullchain.pem /root/-.sysopservice.net/key.pem --force --restart 1

Die Pfade müssen selbstverständlich an die jeweilige Umgebung angepasst werden.

Empfohlene Vorgehensweise

Wir empfehlen, die Umstellung nicht bis Mai 2026 aufzuschieben. Zertifikatsprobleme fallen häufig erst dann auf, wenn eine Erneuerung fehlschlägt und Dienste bereits Warnungen anzeigen oder ausfallen.

Support durch die sysops GmbH

Die sysops GmbH unterstützt Kunden, Kursteilnehmer und Partner bei der Umstellung von Hetzner DNS, ACME, OPNsense, Proxmox VE, Proxmox Backup Server und Proxmox Mail Gateway.

Wenn ihr Unterstützung benötigt, meldet euch bitte über unser Ticketsystem.

📧 ticket@sysops.de

Neue Kurse und Workshops

Der neue Kursplan wird auf unserem Schulungsportal veröffentlicht. Dort findet ihr aktuelle Workshops zu Proxmox, ZFS, OPNsense, Monitoring, Mailservern, Open Source und modernen IT-Infrastrukturen.

Aktuelle Kurse auf cloudistboese.de ansehen

Liebe Grüße
Chriz

Proxmox Vergleich der Storage-Varianten vs. ZFS zu Fuß

Proxmox VE Storage im Vergleich: Ceph, ZFS, SAN/iSCSI und sichere ZFS-Replikation

Stand: 31. August 2026

Welche Storage-Lösung passt zu Proxmox VE: Ceph RBD, lokales ZFS oder ein SAN mit iSCSI und klassischem LVM? Dieser Praxisvergleich erklärt die wichtigsten Unterschiede bei Hochverfügbarkeit, Snapshots, Live-Migration, Thin Provisioning und Wiederherstellung. Anschließend zeigen wir, wie automatische ZFS-Snapshots, Pull-Replikation mit zsync, GUID-Kontrolle mit checkzfs.py und der Miyagi-Workflow eine mehrstufige Backup- und Replikationsstrategie bilden.

Kurzantwort: Ceph, ZFS oder iSCSI?

  • Lokales ZFS eignet sich besonders für einzelne Proxmox-Server und kleinere Cluster. Es bietet Prüfsummen, Snapshots, Clones und eine einfache Replikation zwischen ZFS-Systemen.
  • Ceph RBD ist für verteilten, hochverfügbaren Shared Storage in größeren Proxmox-Clustern gedacht. Ceph repliziert Daten intern und vermeidet einen einzelnen Storage-Kopf.
  • iSCSI mit LVM thick ist sinnvoll, wenn bereits ein professionelles SAN vorhanden ist. Der Storage ist gemeinsam nutzbar, die eigentliche Redundanz und Hochverfügbarkeit liefert jedoch das SAN.
  • ZFS per Script ersetzt die Proxmox-Oberfläche nicht. Es erweitert sie um feinere Snapshot-Aufbewahrung, Pull-Replikation, unabhängige Kontrolle und automatisierte Wiederherstellungswege.

Inhalt

  1. Ceph, ZFS und iSCSI im Vergleich
  2. Proxmox-Funktionen und Storage-Abhängigkeiten
  3. Proxmox GUI versus ZFS-Kommandozeile
  4. Automatische ZFS-Snapshots
  5. Snapshots, Rollbacks, Clones und Snapdirs
  6. Replace und RAIDZ-Expansion
  7. Spares, L2ARC, SLOG und Special Devices
  8. ZFS Pull-Replikation mit zsync
  9. Replikation mit checkzfs.py kontrollieren
  10. Trojanerresistenter Miyagi-Workflow
  11. Häufige Fragen

Proxmox Storage: Ceph RBD, lokales ZFS und iSCSI/LVM im Vergleich

Funktion oder Eigenschaft Ceph RBD Lokales ZFS iSCSI + LVM thick
Gemeinsamer Cluster-Storage Ja Nein Ja
Verteilte Speicherung Ja Nein Nur wenn das SAN sie bereitstellt
Kein einzelner Storage-Kopf Ja, bei korrektem Clusteraufbau Nein Abhängig vom SAN
Thin Provisioning Ja Optional mit sparse Nein
Feste Platzreservierung Steuerbar Über ZFS-Reservation Standard
Snapshots Ja Ja Für VMs ab Proxmox VE 9 über Volume Chains
Linked Clones Ja Ja Nein
Full Clones Ja Ja Ja
VM- und LXC-Datenträger Ja Ja Ja, über LVM
Live-Migration ohne Kopieren der VM-Disk Ja Nein Ja
Migration mit Storage-Kopie Ja Ja Ja
Storage-Replikation Ceph-intern Asynchron zwischen ZFS-Systemen Üblicherweise SAN-intern
Selbstheilung Verteilt im Ceph-Cluster Lokal innerhalb des ZFS-Pools Aufgabe des SAN
Prüfsummen gegen stille Datenfehler Ceph-intern Nativ durch ZFS Abhängig vom SAN
Typischer Einsatz Größerer HA-Cluster Einzelserver oder kleiner Cluster Vorhandenes zentrales SAN

Ceph RBD ist ein verteilter Block-Storage mit Thin Provisioning, Redundanz, Snapshots und Clones. Lokales ZFS bietet ebenfalls Snapshots und Clones, ist jedoch kein Shared Storage. Reines iSCSI stellt LUNs bereit, definiert aber keine allgemeine Speicherplatzverwaltung. Deshalb wird häufig eine große gemeinsame iSCSI-LUN mit klassischem LVM kombiniert. Weitere Details enthält die offizielle Proxmox-VE-Storage-Dokumentation.

Direktes iSCSI, iSCSI mit LVM und ZFS over iSCSI

  1. Direktes iSCSI: Das SAN stellt fertige LUNs bereit. Der Storage ist shared, bietet über das Proxmox-iSCSI-Backend aber keine nativen Snapshot- oder Clone-Funktionen.
  2. iSCSI + klassisches LVM: Eine große gemeinsame LUN enthält eine von Proxmox verwaltete Volume Group. Speicher wird thick zugeteilt; Proxmox übernimmt das clusterweite Locking.
  3. ZFS over iSCSI: ZFS läuft auf einem entfernten Storage-System. Proxmox erzeugt dort per SSH ZVOLs und exportiert sie als iSCSI-LUNs. Ohne redundanten Storage-Kopf kann dieses System zum Single Point of Failure werden.

Welche Proxmox-Funktionen hängen vom Storage ab?

Proxmox-Funktion Ceph Lokales ZFS iSCSI thick
KVM-VMs und LXC-Container Ja Ja Ja
HA-Neustart auf einem anderen Node Ja Nur mit Replikat oder Storage-Wiederherstellung Ja
Live-Migration Ohne Disk-Kopie Mit Disk-Kopie Ohne Disk-Kopie
VM-Snapshot inklusive RAM-Zustand Ja Ja Versions- und Konfigurationsabhängig
Templates und Linked Clones Ja Ja Keine Linked Clones
Backup mit Proxmox Backup Server Ja Ja Ja
Online-Vergrößerung einer VM-Disk Ja Ja Ja
Automatische Replikation Ceph-intern pvesr oder zfs send/receive SAN-intern

Proxmox GUI versus ZFS-Kommandozeile

Die Proxmox-Oberfläche verwaltet VMs, Container, Cluster-Locks und Storage-Zuordnungen. Die ZFS-Kommandozeile administriert dagegen den darunterliegenden Pool. Beide Ebenen ergänzen sich, dürfen aber nicht miteinander verwechselt werden.

Aufgabe Proxmox VE ZFS-Kommandozeile
Pools anzeigen Node → Disks → ZFS zpool list
Poolzustand prüfen ZFS-Übersicht zpool status -v
Speicherbelegung anzeigen Storage Summary zfs list -o space
I/O beobachten PVE-Metriken zpool iostat -v 2
Dataset anlegen Storage-Konfiguration zfs create tank/vmdata
ZVOL anlegen VM-Disk hinzufügen zfs create -V 100G tank/vmdata/test
Kompression aktivieren Meist CLI zfs set compression=lz4 tank/vmdata
VM-Snapshot erstellen qm snapshot 100 snap1 zfs snapshot tank/vmdata/vm-100-disk-0@snap1
Snapshot zurückrollen PVE-Snapshot-Menü zfs rollback …@snap1
Clone erzeugen qm clone 100 200 zfs clone …@snap1 …
VM-Disk vergrößern qm resize 100 scsi0 +20G zfs set volsize=120G …
Replikation PVE Replication Job zfs send … | ssh … zfs receive …
Datenintegrität prüfen Tasks und Status zpool scrub tank
Defekte Platte ersetzen Disks/ZFS beziehungsweise CLI zpool replace tank alt neu
TRIM starten Zeitplan oder CLI zpool trim tank

Praxisregel für Proxmox-VMs auf ZFS

Proxmox-eigene VM-Datenträger sollten nicht unkontrolliert direkt mit zfs snapshot, zfs clone, zfs rollback, zfs rename oder zfs destroy verändert werden. Proxmox kennt diese Änderungen sonst nicht. Für VM-Operationen sind deshalb Weboberfläche, API, qm, pct und pvesm die erste Wahl. Die ZFS-CLI eignet sich besonders für Poolzustand, Scrubs, Plattentausch, Kompression, Kapazitätsanalyse und geplante externe Replikation.


Automatische ZFS-Snapshots für Proxmox einrichten

Für die relevanten ZFS-Datasets und ZVOLs verwenden wir eine gestaffelte Snapshot-Aufbewahrung. Sie bietet engmaschige Wiederherstellungspunkte für aktuelle Fehler und ein gröberes Raster für ältere Stände.

Intervall Aufbewahrung Maximale Anzahl Zweck
Alle 15 Minuten 3 Stunden 12 Schnelle Hilfe bei aktuellen Fehlern
Stündlich 96 Stunden 96 Vier Tage inklusive langer Wochenenden
Täglich 14 Tage 14 Zwei Wochen Tageshistorie
Wöchentlich 6 Wochen 6 Mittelfristige Wiederherstellung
Monatlich 3 Monate 3 Spät erkannte Fehler

Das ergibt maximal ungefähr 131 automatische Snapshots pro Dataset oder ZVOL. Durch zeitliche Überschneidungen und das Verhalten der verwendeten Snapshot-Engine kann die tatsächliche Zahl abweichen.

Wie viel Speicher benötigen ZFS-Snapshots?

Ein ZFS-Snapshot ist keine vollständige Kopie. Beim Erstellen wird lediglich ein neuer Referenzpunkt im Blockbaum angelegt. Zusätzlicher Platz wird benötigt, sobald Daten im Live-Dataset überschrieben oder gelöscht werden und der Snapshot die alten Blöcke weiterhin referenziert. Der Speicherbedarf hängt deshalb von der Änderungsrate ab, nicht allein von der Anzahl der Snapshots.

zfs list -o name,used,available,usedbysnapshots
zfs list -t snapshot -o name,creation,used
zpool list

Snapshots auf demselben Pool sind kein vollständiges Backup. Fällt der gesamte Pool aus oder wird er zerstört, sind auch seine Snapshots verloren. Für längere Aufbewahrung und getrennte Kopien verwenden wir ZFS-Replikation und Proxmox Backup Server.


ZFS-Snapshots, Rollbacks, Clones und Snapdirs erklärt

ZFS-Snapshot erstellen

zfs snapshot rpool/data@vor-update
zfs snapshot -r rpool/data@vor-update

Snapshots entstehen nahezu sofort. Ein nativer Snapshot außerhalb von Proxmox ist jedoch zunächst nur crash-konsistent. Für Datenbanken oder VMs mit mehreren Disks können QEMU Guest Agent, Freeze/Thaw oder eine anwendungsspezifische Vorbereitung erforderlich sein.

Einzelne Dateien aus einem Snapshot wiederherstellen

cp /daten/.zfs/snapshot/daily-2026-08-31/datei /daten/datei

Eine einzelne Datei zu kopieren ist meist sicherer als ein Rollback des gesamten Datasets, weil alle anderen aktuellen Änderungen erhalten bleiben.

Snapdir sichtbar machen

zfs set snapdir=visible pool/daten
  • hidden: .zfs/snapshot ist vorhanden, erscheint aber nicht im normalen Verzeichnislisting.
  • visible: Benutzer können den Snapshot-Pfad sehen und ältere Dateien lesen.
  • disabled: Zugriff über das Snapshot-Verzeichnis ist deaktiviert.

snapdir gilt für ZFS-Dateisysteme. Proxmox-VM-Disks sind üblicherweise ZVOLs und besitzen kein durchsuchbares Dateiverzeichnis. Für ZVOL-Snapshot-Geräte existiert stattdessen snapdev. Siehe OpenZFS-Dokumentation zu Snapshots, Clones und Snapdir.

ZFS-Rollback

zfs rollback pool/daten@vor-update

Ein Rollback verwirft alle Änderungen nach dem gewählten Snapshot. Standardmäßig ist nur der neueste Snapshot zulässig. zfs rollback -r kann neuere Snapshots löschen; -R kann zusätzlich abhängige Clones betreffen. Vor einem Rollback sollte der aktuelle Zustand deshalb separat gesichert werden.

ZFS-Clone

zfs clone pool/daten@vor-update pool/test

Ein Clone ist eine sofort beschreibbare Kopie eines Snapshots. Anfangs teilen sich Snapshot und Clone die unveränderten Blöcke. Neue Schreibvorgänge benötigen zusätzlichen Platz. Typische Anwendungen sind Tests, Updates, Datenrettung und isolierte Kopien. Der Clone bleibt von seinem Ursprungssnapshot abhängig, bis die Beziehung gegebenenfalls mit zfs promote umgekehrt wird.


ZFS-Platte schnell ersetzen und RAIDZ erweitern

Defekte ZFS-Platte mit Replace austauschen

zpool replace tank alte-platte neue-platte
zpool status tank

ZFS rekonstruiert die benötigten Blöcke aus den verbliebenen Geräten und schreibt sie auf die neue Platte. Ist die alte Platte noch lesbar, sollte die neue möglichst zuerst angeschlossen und der Replace kontrolliert gestartet werden. So bleibt die vorhandene Redundanz länger erhalten. Bei Mirrors kann zpool replace -s eine sequenzielle Rekonstruktion starten; für RAIDZ ist diese Option nicht verfügbar. Details stehen in der OpenZFS-Referenz zu zpool replace.

RAIDZ-Expansion: RAIDZ um eine Platte erweitern

zpool attach tank raidz2-0 neue-platte

Mit aktuellen OpenZFS-Versionen kann ein bestehendes RAIDZ-vdev schrittweise um einzelne Platten verbreitert werden. Die Feature-Flag raidz_expansion muss vorhanden und aktiviert sein. Die neue Platte muss mindestens so groß wie die kleinste vorhandene Platte sein.

  • RAIDZ1, RAIDZ2 oder RAIDZ3 behalten ihr jeweiliges Paritätsniveau.
  • Die Anzahl tolerierbarer Plattenausfälle steigt durch die Expansion nicht.
  • ZFS liest die belegten Daten und verteilt sie über die verbreiterte Gruppe.
  • zpool status zeigt den Fortschritt.
  • Bei einem Plattenfehler pausiert die Expansion, bis das vdev wieder gesund ist.
  • Alte Blöcke behalten ihr ursprüngliches Daten-Paritäts-Verhältnis; neue Blöcke nutzen die breitere Geometrie vollständig.

Weitere technische Hintergründe bietet die OpenZFS-Dokumentation zur Änderung des Pool-Layouts.


ZFS Spares, L2ARC, SLOG und Special Devices richtig einsetzen

Gerätetyp Aufgabe Was passiert bei Verlust?
Hot Spare Ersatzplatte bereithalten Die normale Pool-Redundanz entscheidet
Cache/L2ARC Häufig gelesene Daten zusätzlich cachen Unkritisch, da nur Kopien gespeichert werden
Log/SLOG Synchrone Schreibvorgänge beschleunigen Risiko für die jüngsten noch nicht übernommenen Sync-Schreibvorgänge
Special vdev Metadaten und optional kleine Blöcke dauerhaft speichern Der Verlust kann den gesamten Pool zerstören

Hot Spare

zpool add tank spare /dev/disk/by-id/...

Ein Hot Spare verkürzt die Zeit im degradierten Zustand, erhöht aber nicht die Fehlertoleranz. Ein RAIDZ2 bleibt trotz Spare ein RAIDZ2. Die ausgefallene Platte muss dauerhaft ersetzt werden.

L2ARC als ZFS-Lesecache

zpool add tank cache /dev/nvme0n1

Der primäre ZFS-Cache ist der ARC im RAM. L2ARC auf SSD oder NVMe ist nur die zweite Stufe. Er lohnt sich vor allem bei wiederkehrenden zufälligen Lesezugriffen und einem Arbeitsdatensatz, der nicht vollständig in den RAM passt. L2ARC beschleunigt keine Schreibvorgänge; mehr RAM ist häufig die bessere erste Maßnahme.

SLOG für synchrone Schreibvorgänge

zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1

Ein SLOG ist kein allgemeiner Schreibcache. Es beschleunigt nur synchrone Schreibvorgänge, etwa bei NFS, Datenbanken oder VM-Storage mit häufigem fsync(). Geeignete Geräte benötigen geringe Latenz und Power-Loss-Protection. Wichtige SLOGs sollten gespiegelt werden. sync=disabled ist kein pauschaler Tuningtrick, weil dabei zugesagte Schreibsicherheit verloren geht.

Special vdev für Metadaten und kleine Blöcke

zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1
zfs set special_small_blocks=32K tank/daten

Ein Special vdev speichert Metadaten, indirekte Blöcke, gegebenenfalls Dedup-Tabellen und optional kleine Datenblöcke dauerhaft. Es ist kein Cache. Deshalb muss es mindestens so redundant wie der normale Pool aufgebaut werden. Geht das vollständige Special vdev verloren, kann der gesamte Pool verloren sein. Siehe OpenZFS-Dokumentation zu Special vdevs.


ZFS Pull-Replikation mit bashclub zsync

zsync läuft auf dem Zielserver und holt markierte ZFS-Dateisysteme und ZVOLs über SSH von der Quelle. Das Ziel initiiert also die Replikation:

ZFS-Quelle ── SSH und zfs send ──▶ ZFS-Ziel
                    ▲
                    │
             Ziel startet Pull

Dieses Pull-Modell reduziert die Rechte der Quelle auf dem Sicherungsziel. Ein kompromittierter Proxmox-Server soll weder ältere Replikate löschen noch die Retention auf dem Ziel verändern können.

Datasets mit dem ZFS-Attribut bashclub:zsync markieren

zfs set bashclub:zsync=all rpool/data
  • all: Dataset und untergeordnete Datasets beziehungsweise ZVOLs einbeziehen
  • subvols: nur untergeordnete Datasets und ZVOLs einbeziehen
  • exclude: den markierten Zweig ausschließen

Der Attributname kann geändert werden. Dadurch lassen sich verschiedene Replikationsziele mit unterschiedlichen Tags steuern.

Ablauf der zsync-Replikation

  1. zsync startet auf dem Zielserver.
  2. Das Ziel verbindet sich per SSH mit der ZFS-Quelle.
  3. Die ZFS-Attribute bestimmen die zu replizierenden Datasets und ZVOLs.
  4. Optional wird vor der Replikation ein Snapshot erzeugt.
  5. Quelle und Ziel suchen den neuesten gemeinsamen Snapshot.
  6. Der erste Lauf sendet einen vollständigen Stream; Folgeläufe übertragen nur geänderte Blöcke.
  7. Das Ziel erzeugt den vollständigen Dataset-Pfad automatisch.
  8. com.sun:auto-snapshot=false verhindert ungewollte lokale Auto-Snapshots auf dem Replikationsziel.
  9. Der Mountpoint wird übernommen und canmount=noauto verhindert ein unbeabsichtigtes Mounten.
  10. snapshot_filter bestimmt, welche vorhandenen Snapshots mitgenommen werden.
  11. Raw Replication kann verschlüsselte Blöcke ohne Entschlüsselung auf dem Ziel übertragen.
source=root@pve01
target=backup/repl/pve01
tag=bashclub:zsync
snapshot_filter=hourly|daily|weekly|monthly
min_keep=3
zfs_auto_snapshot_keep=14
zfs_auto_snapshot_label=zsync

Installation, Tags und Snapshot-Filter beschreibt die deutsche bashclub-zsync-Dokumentation. Das frühere GitHub-Repository verweist inzwischen auf das GitLab-Projekt.


ZFS-Replikation per Snapshot-GUID mit checkzfs.py überwachen

Eine erfolgreiche Script-Ausgabe beweist noch nicht, dass ein aktuelles und brauchbares Replikat existiert. checkzfs.py vergleicht deshalb die Snapshots auf Quelle und Ziel anhand ihrer ZFS-GUID. Gleiche Snapshot-Namen reichen als Nachweis nicht aus.

Die Prüfung kann unter anderem folgende Fehler erkennen:

  • kein Replikat gefunden,
  • letzter gemeinsamer Snapshot zu alt,
  • Snapshot auf dem Ziel nicht vorhanden,
  • Rollback auf einen älteren Snapshot,
  • zu viele Snapshots,
  • unerwünschte Auto-Snapshots auf dem Replikationsziel,
  • SSH- oder Abfragefehler.

Wunschalter der Replikation festlegen

threshold: 1500,2000

Im Beispiel wird nach 1.500 Minuten gewarnt und nach 2.000 Minuten ein kritischer Zustand gemeldet. Zusätzlich lassen sich maximale Snapshotzahlen, Dataset-Filter, Snapshot-Filter, SSH-Key und Servicename definieren.

source: pve01
remote: backup01
filter: rpool/data
replicafilter: backup/repl/pve01
snapshotfilter: zsync|daily|weekly|monthly
threshold: 1500,2000
maxsnapshots: 140,160
prefix: REPLICA

Die Ausgabe eignet sich unter anderem für Tabellen, JSON, CSV, E-Mail und lokale Checkmk-Checks. Der Quellcode von checkzfs.py zeigt die verfügbaren Parameter und Prüfungen.

Wichtig: Ein GUID-Vergleich bestätigt die gemeinsame Snapshot-Identität. Er ersetzt weder den regelmäßigen ZFS-Scrub noch einen getesteten Restore.


Trojanerresistentes Proxmox-Backup mit dem Miyagi-Workflow

Der Miyagi-Workflow verbindet zwei unterschiedliche Sicherungsmethoden auf einem getrennten System:

  • Proxmox Backup Server: deduplizierte und längerfristige VM- und LXC-Backups
  • Native ZFS-Replikation: unmittelbar vorhandene Datasets und ZVOLs für einen schnellen Wiederanlauf

Das Ziel sind mindestens drei Datenkopien, zwei Standorte, zwei Sicherungsmethoden, automatische Kontrolle und eine möglichst kurze Netzwerk-Erreichbarkeit des Sicherungsservers.

Typischer Ablauf des Miyagi-Servers

Miyagi-Server startet
        │
        ├─ Updates und Zustandsprüfung
        ├─ ZFS-Replikation per Pull
        ├─ PBS-Backup koordinieren
        ├─ Verify, Wartung und Monitoring
        ├─ GUID und Alter der Replikate prüfen
        └─ Sicherungsserver herunterfahren

Das ZFS-Replikat kann einen schnellen Wiederanlauf ermöglichen, weil Datasets und ZVOLs bereits auf dem Ziel liegen. Das PBS-Backup bietet die längere, deduplizierte Historie, benötigt für die produktive Nutzung aber einen Restore.

Wann ist der Workflow gegen Ransomware und Trojaner widerstandsfähig?

„Trojanersicher“ ist keine einzelne Produkteigenschaft. Die Schutzwirkung entsteht durch technische Trennung und minimale Berechtigungen:

  • Das Ziel startet die Pull-Replikation.
  • Die Quelle besitzt keine administrativen Schreib- oder Löschrechte auf dem Ziel.
  • SSH-Zugriffe werden auf notwendige Befehle und Datasets begrenzt.
  • Der PBS-API-Key erhält nur die erforderlichen Backup- und Restore-Rechte.
  • SSH-Passwortlogin wird deaktiviert und interaktive Konten werden mit 2FA geschützt.
  • Snapshot-Löschung und Retention werden ausschließlich vom Ziel kontrolliert.
  • Der Miyagi-Server hat häufig nur definierte Routen und kein Default Gateway.
  • Außerhalb des Sicherungsfensters ist der Server ausgeschaltet oder wirksam isoliert.
  • Scrubs, Verify-Jobs und Wiederherstellungstests werden regelmäßig durchgeführt.
  • Mindestens eine Kopie befindet sich an einem anderen Standort.

Der dokumentierte Workflow kombiniert Backups, startfähige ZFS-Replikate, Monitoring, Wartung und automatisches Herunterfahren. Die vollständige Einrichtung beschreibt die Anleitung Backup und Replikation für Proxmox VE mit dem Miyagi-Workflow.


Welche Proxmox-Storage-Lösung ist die richtige?

  • Ein bis zwei Nodes: Lokales ZFS ist meist die einfachste und robusteste Lösung.
  • Drei oder mehr geeignete Nodes mit echtem Storage-HA: Ceph RBD ist der typische Ansatz.
  • Vorhandenes professionelles SAN: iSCSI mit klassischem LVM nutzt die bestehende zentrale Infrastruktur.
  • Thin Provisioning und schnelle Linked Clones: Ceph oder ZFS.
  • Vorhersehbare feste Platzbelegung: iSCSI mit LVM thick.
  • Schneller lokaler Restore plus getrennte Kopie: ZFS-Snapshots mit Pull-Replikation und PBS kombinieren.

Häufige Fragen zu Proxmox, ZFS, Ceph und Replikation

Ist ein ZFS-Snapshot bereits ein Backup?

Nein. Ein Snapshot liegt normalerweise auf demselben ZFS-Pool wie die produktiven Daten. Er schützt gut vor versehentlichem Löschen oder unerwünschten Änderungen, aber nicht vor dem vollständigen Verlust oder der Zerstörung des Pools.

Was ist für Proxmox besser: Ceph oder ZFS?

Für einzelne Server und kleine Cluster ist lokales ZFS meist einfacher. Ceph eignet sich für mehrere Nodes, verteilten Shared Storage und hohe Verfügbarkeit ohne einzelnen Storage-Kopf. Ceph benötigt dafür mehr Hardware, Netzwerkleistung und Betriebsaufwand.

Kann Proxmox mit lokalem ZFS live migrieren?

Ja, eine laufende VM kann migriert werden. Da lokales ZFS kein Shared Storage ist, muss der VM-Datenträger dabei jedoch auf den Ziel-Node kopiert werden. Bei Ceph oder gemeinsamem iSCSI-Storage entfällt diese Storage-Kopie in der Regel.

Was ist der Unterschied zwischen ZFS-Replikation und Proxmox Backup Server?

ZFS-Replikation überträgt native Datasets, ZVOLs und Snapshots und ermöglicht dadurch einen schnellen Wiederanlauf. Proxmox Backup Server erstellt deduplizierte Backups mit längerer Historie und integriertem Restore für VMs und Container. Beide Verfahren ergänzen sich.

Warum ist Pull-Replikation sicherer als Push-Replikation?

Bei Pull-Replikation startet das Ziel die Verbindung und holt Daten von der Quelle. Die Quelle benötigt dadurch keine administrativen Rechte auf dem Sicherungsziel. Wird sie kompromittiert, kann sie ältere Ziel-Snapshots nicht ohne Weiteres löschen.

Wozu vergleicht checkzfs.py Snapshot-GUIDs?

Ein Snapshot-Name kann auf zwei Systemen identisch sein, ohne denselben Snapshot zu bezeichnen. Die GUID ermöglicht eine eindeutige Zuordnung und zeigt, ob Quelle und Ziel tatsächlich einen gemeinsamen replizierten Snapshot besitzen.

Beschleunigt ein ZFS-SLOG alle Schreibvorgänge?

Nein. Ein SLOG hilft nur bei synchronen Schreibvorgängen. Asynchrone Writes werden dadurch nicht grundsätzlich schneller. Ein geeignetes SLOG benötigt geringe Latenz und Power-Loss-Protection.

Kann der Verlust eines Special vdev den ZFS-Pool zerstören?

Ja. Ein Special vdev speichert bestimmte Blöcke dauerhaft und nicht nur als Cache. Es muss deshalb mindestens so redundant wie die normalen Daten-vdevs aufgebaut werden.


Fazit: Proxmox-Storage mit überprüfbarer Backup-Strategie

Ceph, lokales ZFS und iSCSI erfüllen unterschiedliche Aufgaben. Entscheidend ist nicht nur die Storage-Technik, sondern der vollständige Wiederherstellungsweg. Automatische ZFS-Snapshots liefern schnelle lokale Zeitpunkte, zsync erzeugt getrennte native Replikate, checkzfs.py kontrolliert deren Aktualität und der Miyagi-Workflow kombiniert ZFS-Replikation mit Proxmox Backup Server, Monitoring und zeitweiser Offline-Sicherung.

So entsteht aus einzelnen Storage-Funktionen eine mehrstufige Strategie gegen Hardwareausfälle, Fehlbedienung, spät erkannte Datenfehler und kompromittierte Produktivsysteme.