Thorsten Geppert – Seite 3 – Thorsten Geppert

Warum viele IT-Infrastrukturen unnötig komplex geworden sind

23. April 202623. April 2026 Thorsten Geppert Schreib einen Kommentar

Es gibt einen Moment, der in fast jeder IT-Abteilung irgendwann kommt. Etwas geht schief — ein Dienst fällt aus, eine Datenbank ist nicht erreichbar, eine Anmeldung funktioniert nicht — und niemand kann erklären, warum. Nicht, weil die Leute inkompetent sind. Sondern weil niemand mehr versteht, wie die Systeme zusammenhängen. Die Infrastruktur ist gewachsen, nicht geplant. Und was gewachsen ist, hat Wurzeln, die niemand kennt.

Das ist kein Einzelfall. Es ist der Normalfall.

Einleitung

Viele IT-Landschaften sind über Jahre gewachsen. Jedes Mal, wenn ein neues Problem auftrat, wurde ein neues System eingeführt. Jedes Mal, wenn ein Dienstleister wechselte, brachte er seine eigenen Tools mit. Jedes Mal, wenn eine Abteilung eine Lösung brauchte, kaufte sie eine — ohne die anderen zu fragen. Das Ergebnis ist eine Infrastruktur, die zwar funktioniert — aber kaum noch jemand vollständig versteht.

Die Komplexität ist nicht das Ergebnis von Dummheit. Sie ist das Ergebnis von Hunderten einzelnen Entscheidungen, die im Moment alle sinnvoll waren. Jedes neue Tool löste ein Problem. Jede neue Integration brachte einen Mehrwert. Jede neue Plattform hatte ihre Berechtigung. Aber die Summe dieser Entscheidungen ist eine Landschaft, in der niemand den Überblick hat.

Und das ist gefährlich. Nicht weil es unordentlich ist — sondern weil es fehleranfällig ist. Jede Abhängigkeit, die niemand kennt, ist eine Fehlermöglichkeit, die niemand testen kann. Jede Konfiguration, die nur eine Person versteht, ist ein Single Point of Failure, der nicht in der Architektur, sondern im Personal liegt.

Wie Infrastruktur langsam unwartbar wird

Komplexität entsteht nicht über Nacht. Sie schleicht sich ein, Entscheidung für Entscheidung, Tool für Tool, Migration für Migration. Es ist ein schleichender Prozess, den man im Moment selten bemerkt — und im Nachhinein kaum noch rekonstruieren kann.

Phase 1: Das grüne Feld

Am Anfang ist alles einfach. Ein Server, eine Anwendung, eine Datenbank. Alles ist überschaubar. Die Admins kennen jedes System, jede Konfiguration, jeden Cron-Job. Änderungen sind trivial, weil die Auswirkungen vorhersehbar sind.

In dieser Phase wird oft der Grundstein für spätere Komplexität gelegt — durch Entscheidungen, die für den Moment passen, aber nicht skalieren. Eine Quick-and-Dirty-Integration hier, ein Workaround dort, ein Skript, das „nur temporär“ ist und dann fünf Jahre läuft.

Phase 2: Das Wachstum

Die Firma wächst. Neue Mitarbeiter, neue Abteilungen, neue Anforderungen. Jede Anforderung bringt ein neues System:

Marketing braucht ein CMS. Also wird eines eingeführt.
Vertrieb braucht ein CRM. Also wird eines gekauft.
Entwicklung braucht CI/CD. Also wird ein Pipeline-System aufgesetzt.
HR braucht ein Onboarding-Tool. Also wird eines abonniert.

Jedes dieser Systeme ist isoliert betrachtet sinnvoll. Aber niemand fragt: Wie integriert es sich in das Bestehende? Wer betreibt es? Wer dokumentiert es? Was passiert, wenn der SaaS-Anbieter seinen Service einstellt?

In dieser Phase verdoppelt sich die Komplexität — nicht weil die Systeme kompliziert sind, sondern weil die Verbindungen zwischen ihnen wachsen. Jedes neue System braucht Authentifizierung, braucht Daten-Synchronisation, braucht Monitoring, braucht Backup. Und jede dieser Verbindungen ist eine neue Abhängigkeit.

Phase 3: Die Ablagerungen

Alte Systeme werden nicht abgeschafft. Sie werden ergänzt. Das alte CMS läuft weiter, weil drei Seiten noch darauf basieren. Das alte CRM läuft weiter, weil der Vertrieb die alten Daten braucht. Das alte Mail-System läuft weiter, weil die Compliance-Abteilung die Archivierung braucht.

Niemand traut sich, etwas abzuschalten, weil niemand weiß, was davon abhängt. Also läuft alles weiter — das Alte und das Neue, nebeneinander, mit Brücken, Workarounds und Cron-Jobs, die Daten zwischen Systemen hin- und herschieben, die niemand mehr versteht.

Phase 4: Die Unwartbarkeit

Irgendwann ist der Punkt erreicht, an dem niemand mehr die Infrastruktur vollständig versteht. Die Dokumentation ist lückenhaft, veraltet oder existiert gar nicht. Das Wissen steckt in den Köpfen von drei Personen — und wenn eine davon in Urlaub ist, kann niemand den Dienst restarten, der seit zwei Jahren nicht mehr neu gestartet wurde und dessen Start-Skript einen Bug hat, der beim Neustart zu einem Datenverlust führt.

In dieser Phase passieren die Dinge, die Karrieren beenden: Produktionsausfälle, die Tage dauern. Datenverluste, die nicht wiederhergestellt werden können. Security-Lücken, die monatelang unentdeckt bleiben, weil niemand das System patchen kann, ohne das Ganze zum Absturz zu bringen.

Typische Symptome

Die Symptome einer überkomplexen Infrastruktur sind universell. Sie zeigen sich in jeder Firma, die diesen Weg gegangen ist — unabhängig von Größe, Branche oder Technologie-Stack.

Systeme hängen voneinander ab — und niemand weiß wie

Das Authentifizierungssystem ist mit dem LDAP verbunden, das LDAP repliziert in die Cloud, die Cloud synchronisiert mit dem HR-System, das HR-System triggert einen Webhook, der einen Workflow in einer Automatisierungs-Plattform startet, die ein Ticket im Ticketsystem erstellt, das eine E-Mail über den Relay-Server verschickt, der auf einem alten Postfix läuft, den niemand angefasst hat, seit 2019.

Wenn der Relay-Server ausfällt, funktioniert das Onboarding nicht mehr. Aber niemand verbindet den Ausfall eines Mail-Servers mit einem Onboarding-Problem, weil die Kette zu lang ist und nicht dokumentiert wurde.

Dokumentation fehlt

Die Dokumentation existiert in drei Zuständen: gar nicht, veraltet oder falsch. Die einzige verlässliche Dokumentation ist die Infrastruktur selbst — und die ist undokumentiert. Wenn jemand wissen will, wie ein System konfiguriert ist, muss er sich auf dem Server anmelden und nachschauen. Und wenn der Server nicht mehr erreichbar ist, ist die Konfiguration auch nicht mehr erreichbar.

Updates machen Angst

Updates sollten Routine sein. In einer komplexen Infrastruktur sind sie ein Risiko. Nicht, weil die Updates selbst gefährlich sind, sondern weil niemand weiß, welche Abhängigkeiten bestehen. Was passiert, wenn ich die Datenbank aktualisiere? Breche ich die Anwendung, die darauf zugreift? Breche ich den Dienst, der die Daten repliziert? Breche ich den Cron-Job, der die Daten jeden Nacht exportiert?

Die Antwort ist oft: „Wir machen die Updates, wenn es nicht mehr anders geht.“ Und das bedeutet: Sicherheitslücken bleiben offen, weil die Angst vor Nebenwirkungen größer ist als die Angst vor der Lücke.

Know-how steckt in Einzelpersonen

Es gibt in jeder Firma die Person, die alles weiß. Die seit 15 Jahren dabei ist. Die weiß, dass Server X nur hochfährt, wenn Service Y manuell gestartet wird, weil das Init-Skript einen Bug hat. Die weiß, dass die Datenbank auf Server Z nie neu gestartet werden darf, weil die Replikation sonst aus dem Takt kommt. Die weiß, dass der Cron-Job um 3 Uhr morgens nicht verschoben werden darf, weil er mit dem Backup auf Server W kollidiert.

Wenn diese Person kündigt, geht das Wissen. Nicht das dokumentierte Wissen — das existiert ja nicht. Das implizite Wissen, das in Jahren der Trial-and-Error-Erfahrung entstanden ist. Und das ist das teuerste Wissen, weil es das einzige ist, das die Infrastruktur am Laufen hält.

Warum das passiert

Die Ursachen für überkomplexe Infrastruktur sind nicht technisch. Sie sind organisatorisch, kulturell und ökonomisch.

Kurzfristige Entscheidungen

Die meisten Systeme wurden eingeführt, weil ein akutes Problem gelöst werden musste. Der Vertrieb brauchte sofort ein CRM — also wurde eines gekauft, schnell, ohne Integrationsplan. Die Entwickler brauchten sofort CI/CD — also wurde ein System aufgesetzt, das funktioniert, aber nicht in die bestehende Infrastruktur passt.

Kurzfristige Entscheidungen sind nicht falsch. Sie werden falsch, wenn sie nicht langfristig korrigiert werden. Wenn das „temporäre“ System drei Jahre später immer noch läuft, ist es nicht mehr temporär — aber die Architektur wurde nie an die neue Realität angepasst.

Tool-getriebene IT

Viele IT-Abteilungen entscheiden nicht über Architektur, sondern über Tools. Ein Problem wird identifiziert, ein Tool wird evaluiert, das Tool wird eingeführt. Die Frage „Wie passt das in unsere Gesamtarchitektur?“ wird selten gestellt — oft, weil es keine Gesamtarchitektur gibt.

Das Ergebnis ist eine Landschaft von Insellösungen, die jeweils ihr eigenes Problem lösen, aber zusammen ein neues Problem schaffen: Komplexität. Jedes Tool hat seine eigene Konfiguration, seine eigenen Abhängigkeiten, seine eigene Update-Politik, seine eigene Art, Dinge zu tun. Die Überschneidungen sind enorm — aber niemand sieht sie, weil jeder nur sein eigenes Tool kennt.

Fehlende Architektur

Architektur ist nicht das, was am Ende dazukommt. Architektur ist das, was am Anfang stehen sollte. Die Frage ist nicht: „Welches Tool löst unser Problem?“ Die Frage ist: „Wie soll unsere Infrastruktur aussehen, damit sie unsere Anforderungen erfüllt — heute und in drei Jahren?“

Fehlende Architektur bedeutet: Jede Entscheidung wird isoliert getroffen. Jede Lösung ist eine Punkt-Lösung. Das Gesamtbild entsteht nicht durch Planung, sondern durch Ablagerung. Wie Sedimentgestein — Schicht auf Schicht, ohne Struktur, ohne Plan.

Externe Dienstleister ohne Gesamtblick

Externe Dienstleister sind nicht per se ein Problem. Sie werden zum Problem, wenn sie keinen Anreiz haben, die Gesamtarchitektur zu verbessern. Ihr Job ist es, ihr Teil zu betreiben — nicht, die Integration mit dem Rest zu verstehen.

Das Ergebnis: Ein Dienstleister betreibt die Mail-Infrastruktur. Ein anderer das Monitoring. Ein dritter die Backup-Lösung. Und wenn etwas zwischen den Systemen schiefgeht, ist es niemandes Verantwortung. Jeder sagt: „Mein Teil funktioniert.“ Und trotzdem funktioniert das Ganze nicht.

Die absurde Vielfalt — Beispiele aus der Praxis

Um zu verstehen, wie Komplexität entsteht, reicht es, sich alltägliche Bereiche anzusehen, in denen die Tool-Vielfalt aus dem Ruder gelaufen ist.

Kommunikation

Unternehmen nutzen gleichzeitig:

E-Mail — weil jeder E-Mail hat und es formell ist
Microsoft Teams — weil der Vertrieb es fordert
Mattermost — weil die Entwickler Slack nicht bezahlen wollen
Signal — weil manche Vertraulichkeit brauchen
Wire — weil der Vorstand Ende-zu-Ende-Verschlüsselung will
Telefon — weil manche Leute einfach anrufen

Sechs Kanäle für Kommunikation. Keiner ist der offizielle. Die Frage „Wo wurde das besprochen?“ hat keine Antwort, weil die Antwort sein kann: In der E-Mail, im Teams-Chat, im Mattermost-Kanal, in der Signal-Gruppe, im Wire-Anruf oder am Telefon. Entscheidungen sind verteilt über sechs Systeme, und niemand hat den Überblick.

Die Lösung wäre: Einen Kanal für Formelles (E-Mail), einen für Kollaboration (ein einziges Chat-System), einen für Vertrauliches (verschlüsselt). Drei Systeme, klar getrennt, klar dokumentiert. Stattdessen: Sechs Systeme, überlappend, niemand zuständig.

Datenablage

Unternehmen nutzen gleichzeitig:

SMB/NFS-Share — weil es schon immer da war
OneDrive — weil Microsoft 365 es mitbringt
Nextcloud — weil Datenschutz wichtig ist
SharePoint — weil der Vertrieb Dokumenten-Workflows braucht
Git-Repositories — weil Entwickler Konfigurationen versionieren
S3-Buckets — weil die Cloud-Anwendungen Speicher brauchen

Sechs Speicherorte für Daten. Keiner ist der offizielle. Die Frage „Wo ist das Dokument?“ hat keine Antwort, weil die Antwort sein kann: Auf dem Share, in OneDrive, in Nextcloud, in SharePoint, im Git-Repo oder im S3-Bucket. Versionen sind verteilt, Zugriffsrechte sind inkonsistent, Backups sind fragmentiert.

Die Lösung wäre: Einen primären Speicher für Dokumente, einen für Konfigurationen, einen für Objekte. Drei Systeme, klar getrennt, klar dokumentiert.

Identitätsmanagement

Unternehmen nutzen gleichzeitig:

Active Directory — weil Windows
LDAP — weil Linux
Keycloak — weil OAuth
Azure AD — weil Cloud
GitHub Organizations — weil Entwicklung
SaaS-eigene Benutzerdatenbanken — weil jedes Tool seine eigene Auth hat

Sechs Identitätsquellen. Keine ist die autoritative. Wenn ein Mitarbeiter geht, muss er in sechs Systemen deaktiviert werden — und wenn eines vergessen wird, hat er weiterhin Zugriff. Wenn ein Passwort geändert werden muss, muss es in sechs Systemen geändert werden — und wenn eines vergessen wird, ist es ein Sicherheitsrisiko.

Die Lösung wäre: Ein Identitäts-Provider. EINE Quelle der Wahrheit. Alle anderen Systeme delegieren an diesen Provider. Aber das erfordert Architektur, und Architektur erfordert, dass jemand die Entscheidung trifft und sie durchsetzt.

Monitoring

Unternehmen nutzen gleichzeitig:

Nagios — weil es schon immer lief
Prometheus + Grafana — weil die Entwickler es eingeführt haben
Datadog — weil der Cloud-Migration-Berater es empfohlen hat
Zabbix — weil der Linux-Admin damit angefangen hat
CloudWatch — weil die AWS-Services es mitbringen

Fünf Monitoring-Systeme. Fünf Dashboards. Fünf Alerting-Ketten. Wenn etwas ausfällt, gehen die Alerts in fünf verschiedene Richtungen, und niemand weiß, welches Dashboard die Wahrheit zeigt. Das Monitoring ist so komplex wie die Infrastruktur, die es überwachen soll — und deshalb überwacht es sie nicht mehr effektiv.

Warum „noch ein Tool“ selten hilft

Die häufigste Reaktion auf ein Infrastruktur-Problem ist: ein neues Tool. Das Ticket-System ist zu kompliziert? Wir führen ein neues ein. Das Monitoring zeigt nicht die richtigen Metriken? Wir installieren ein neues. Die Kommunikation ist chaotisch? Wir evaluieren eine neue Plattform.

Das Problem ist nicht das Tool. Das Problem ist die Komplexität. Und ein neues Tool erhöht die Komplexität, es reduziert sie nicht.

Das Werkzeug-Fetischismus-Problem

Die IT-Branche hat ein instrumentelles Verhältnis zu Werkzeugen. Jedes Problem hat ein Tool, das es löst. Jedes Tool hat eine Evaluierung, eine Einführung, eine Lernkurve. Und jedes Tool fügt eine weitere Abhängigkeit hinzu, eine weitere Konfiguration, eine weitere Update-Pflicht, eine weitere Schnittstelle.

Was fehlt, ist nicht ein weiteres Tool. Was fehlt, ist die Entscheidung, welche Tools man nicht braucht. Die Reduktion der Komplexität beginnt nicht mit einer neuen Lösung — sie beginnt mit dem Abbau der alten.

Der Sunk-Cost-Fehler

„Wir haben so viel Geld in System X investiert, wir können es nicht abschaffen.“ Das ist der Sunk-Cost-Fehler. Das Geld ist ausgegeben. Die Frage ist nicht, ob die Investition sich lohnt — sie ist weg. Die Frage ist, ob das System heute einen Mehrwert bietet, der die Komplexität rechtfertigt, die es verursacht. Wenn die Antwort nein ist, muss es weg. Unabhängig davon, wie viel es gekostet hat.

Das Integrations-Paradoxon

Jedes neue Tool verspricht Integration. „Verbindet sich mit allem!“ steht auf der Website. Und das stimmt — es verbindet sich mit allem. Aber jede Integration ist eine neue Abhängigkeit. Jede Schnittstelle ist eine neue Fehlermöglichkeit. Das Tool, das alle Probleme löst, indem es sich mit allem verbindet, löst sein eigenes Problem — und schafft zehn neue.

Warum einfache Systeme stabiler sind

Weniger bewegliche Teile

Jedes System, jeder Dienst, jede Integration, jede Konfiguration ist ein bewegliches Teil. Und bewegliche Teile können kaputtgehen. Die Wahrscheinlichkeit eines Ausfalls steigt mit der Anzahl der Komponenten — nicht linear, sondern exponentiell, weil die Wechselwirkungen zwischen den Komponenten schneller wachsen als die Komponenten selbst.

Zehn Server, die voneinander abhängen, haben nicht zehn Fehlermöglichkeiten. Sie haben bis zu 45 möglichen Paar-Abhängigkeiten und hunderte von Kaskaden-Effekten. Wenn Server A ausfällt, kann das Server B beeinträchtigen, was Server C zum Stillstand bringt, der die Datenbank D zum Timeout bringt, die den Cache E zum Überlaufen bringt, der den Load Balancer F zum Ausfall bringt, der den gesamten Traffic auf Server G leitet, der nicht für diese Last dimensioniert ist.

Einfache Systeme haben weniger bewegliche Teile. Weniger Abhängigkeiten. Weniger Fehlermöglichkeiten. Das ist keine Philosophie — es ist Mathematik.

Verständlichkeit als Stabilitätsfaktor

Ein System, das jemand versteht, kann repariert werden. Ein System, das niemand versteht, kann nur neu gestartet werden. Und neu starten ist keine Reparatur — es ist eine Vertagung des Problems.

Einfache Systeme sind verständlich. Jeder Administrator kann erklären, wie sie funktionieren. Jeder Administrator kann abschätzen, was passiert, wenn eine Komponente ausfällt. Jeder Administrator kann das System dokumentieren, weil die Komplexität der Dokumentation proportional zur Komplexität des Systems ist.

Komplexe Systeme sind unverständlich — nicht weil die Admins nicht schlau genug sind, sondern weil die kognitive Kapazität des Menschen begrenzt ist.

Der Beweis: Einfache Systeme in der Praxis

Die stabilsten Systeme, die die IT-Geschichte hervorgebracht hat, sind einfache Systeme:

SMTP — ein einfaches Protokoll, das seit über 40 Jahren funktioniert
DNS — ein hierarchisches Namenssystem, das das Internet trägt
HTTP — ein zustandsloses Request-Response-Protokoll, das das Web ermöglicht hat
Unix-Philosophie — ein Programm, eine Aufgabe, gut gemacht
ZFS — ein Storage-System, das Datenintegrität, Snapshots und Replikation vereint, ohne dass man 15 separate Tools braucht

Diese Systeme sind nicht einfach, weil sie primitiv sind. Sie sind einfach, weil sie das Richtige abstrahieren und das Falsche weglassen. Ihre Stabilität resultiert nicht aus Komplexität — sie resultiert trotz fehlender Komplexität.

Wie man Infrastruktur wieder stabil bekommt

Systeme reduzieren

Der erste Schritt ist nicht, etwas hinzuzufügen. Der erste Schritt ist, etwas wegzunehmen.

Inventar erstellen. Jedes System, jeder Dienst, jede Integration dokumentieren. Wer betreibt es? Wer nutzt es? Wann wurde es zuletzt angefasst? Gibt es eine Dokumentation? Gibt es einen Verantwortlichen?

Kategorisieren. Welche Systeme sind kritisch? Welche sind wichtig? Welche sind nice-to-have? Welche laufen, weil sie schon immer laufen?

Abschaffen. Jedes System, das nicht mehr genutzt wird oder dessen Funktion von einem anderen System erfüllt wird, wird abgeschaltet. Nicht in einem Jahr. Nicht nach der nächsten Release. Jetzt.

Konsolidieren. Drei Chat-Systeme werden eins. Fünf Monitoring-Lösungen werden eine. Vier Speicherorte werden zwei. Das bedeutet Kompromisse. Nicht jeder bekommt sein Lieblings-Tool. Aber jeder bekommt eine Infrastruktur, die funktioniert.

Klare Verantwortlichkeiten

Jedes System hat genau einen Verantwortlichen. Nicht zwei. Nicht eine Gruppe. Einen. Der Verantwortliche ist nicht derjenige, der alles macht — er ist derjenige, der weiß, wer was macht und ob es gemacht wird.

Ohne klare Verantwortlichkeiten passiert das, was immer passiert: Jeder denkt, der andere ist zuständig. Und am Ende ist niemand zuständig. Die Verantwortlichkeit muss benannt sein, nicht implizit. Wenn der Verantwortliche Urlaub hat, muss es eine Vertretung geben — eine Person, nicht ein Team.

Saubere Dokumentation

Dokumentation ist kein Afterthought. Sie ist Teil des Setups. Jedes System wird mit Dokumentation eingeführt, nicht danach. Die Dokumentation umfasst:

Was ist das? Name, Zweck, Abhängigkeiten
Wie hängt es zusammen? Architektur-Diagramm, Datenflüsse, Schnittstellen
Wie wird es betrieben? Update-Prozedur, Backup-Prozedur, Restore-Prozedur
Was passiert bei Ausfall? Failover, Recovery-Time-Objective, Verantwortlicher
Wie wird es ersetzt? Migrationsszenario, Alternativen, Daten-Export

Die Dokumentation wird versioniert, gepflegt und regelmäßig überprüft. Veraltete Dokumentation ist schlimmer als keine Dokumentation — weil sie falsches Vertrauen erzeugt.

Robuste Plattformen statt Fragmente

Die Wahl der Plattform ist eine der wichtigsten Architektur-Entscheidungen. Und die Entscheidung sollte auf Stabilität, Einfachheit und Langfristigkeit fallen — nicht auf Hype, Feature-Liste oder Marketing-Budget.

FreeBSD + ZFS ist ein Beispiel für eine Plattform, die Komplexität reduziert, statt sie zu addieren:

ZFS vereint Dateisystem, Volume-Manager, RAID, Snapshot-Management, Replikation, Kompression und Caching in einem System. Statt separate Tools für RAID (mdadm), LVM, Snapshot (LVM-snapshot), Backup (Bacula/Borg) und Caching (bcache) zu betreiben, hat man alles in einem. Weniger Systeme. Weniger Komplexität. Mehr Stabilität.
FreeBSD bietet ein kohärentes Betriebssystem — nicht eine Sammlung von Paketen, die jemand zusammengebaut hat. Das Basis-System und die Ports sind getrennt. Updates sind vorhersehbar. Das System ist auf Stabilität ausgelegt, nicht auf das neueste Feature.
pkgbase (seit FreeBSD 15) aktualisiert das Basis-System wie ein Paket-Manager. Kein freebsd-update mehr, keine manuellen Patches. Das System ist einheitlich, konsistent und automatisierbar.
jails bieten Isolation ohne den Overhead von Containern. Ein Jail ist eine leichtgewichtige, sichere Isolation, die keine eigene Kernel-Instanz braucht und in Sekunden erstellt oder geklont werden kann.

Robuste Plattformen sind nicht die mit den meisten Features. Sie sind die mit den wenigsten Überraschungen.

Der Weg zurück zur Einfachheit

Einfachheit ist kein Zustand. Einfachheit ist eine Entscheidung, die man jeden Tag treffen muss. Bei jedem Tool, das evaluiert wird. Bei jedem System, das eingeführt wird. Bei jeder Integration, die gebaut wird. Die Frage ist nicht: „Können wir das machen?“ Die Frage ist: „Müssen wir das machen? Und wenn ja: Was nehmen wir dafür weg?“

Die Rückkehr zur Einfachheit ist kein Sprint. Es ist ein Marathon. Es dauert Monate oder Jahre, eine überkomplexe Infrastruktur zu reduzieren. Aber jeder Schritt zählt. Jedes System, das abgeschafft wird, reduziert die Angriffsfläche. Jede Integration, die vereinfacht wird, reduziert die Fehlermöglichkeiten. Jede Dokumentation, die geschrieben wird, reduziert das Single-Point-of-Failure-Risiko im Personal.

Der erste Schritt ist die Inventur. Der zweite ist die Entscheidung. Der dritte ist die Konsequenz.

Und die Konsequenz lautet: Weniger ist mehr. Nicht als Buzzword, sondern als Architekturprinzip.

Fazit

IT muss nicht kompliziert sein. Sie wird kompliziert, wenn Architektur fehlt. Wenn jede Entscheidung isoliert getroffen wird. Wenn jedes Problem mit einem neuen Tool gelöst wird, statt die Ursache zu adressieren. Wenn kurzfristige Lösungen zu langfristigen Belastungen werden.

Die Infrastruktur ist das Fundament. Wenn das Fundament instabil ist, stürzt alles ein, was darauf aufbaut — egal wie modern die Werkzeuge sind, die man darauf installiert hat. Die stabilsten Systeme der Welt sind nicht die mit den meisten Features. Sie sind die mit der klarsten Architektur. Die mit den wenigsten Abhängigkeiten. Die, die man erklären kann, ohne ein Whiteboard voll zu zeichnen.

Die Wahl der Plattform entscheidet mit darüber, ob Komplexität entsteht oder vermieden wird. FreeBSD mit ZFS ist eine Entscheidung für Einfachheit: ein Betriebssystem, das auf Stabilität designed ist, ein Dateisystem, das Storage-Management integriert statt zu fragmentieren, eine Infrastruktur, die man verstehen kann, weil sie nicht aus hundert Einzelteilen besteht, die niemand mehr überschaut.

Die Frage ist nicht, ob man die Komplexität reduzieren kann. Die Frage ist, ob man es tut, bevor die Komplexität die Infrastruktur reduziert — auf einen Haufen Systeme, die niemand mehr versteht, niemand mehr betreibt und niemand mehr reparieren kann.

Es ist Zeit, Einfachheit ernst zu nehmen. Nicht als Buzzword. Als Architekturprinzip.

Digitale Souveränität: Warum On-Premise wieder relevant wird

22. April 202619. April 2026 Thorsten Geppert Schreib einen Kommentar

Zehn Jahre lang war die Antwort auf fast jede IT-Frage dieselbe: Cloud. Neue Applikation? Cloud. Altes System migrieren? Cloud. Storage wächst? Cloud. Skalierung nötig? Cloud. Die Cloud war nicht nur eine Technologie — sie war eine Ideologie. „Cloud-first“ stand in den Strategiepapieren von Unternehmen, die nicht einmal verstanden hatten, was „first“ in diesem Kontext bedeutet.

Jetzt, zehn Jahre später, kommt die Ernüchterung. Nicht bei allen, aber bei vielen. Die Rechnungen sind da. Die Abhängigkeiten sind da. Die Fragen, die man hätte stellen sollen, bevor man migriert hat, sind immer noch da — nur dass sie jetzt teurer zu beantworten sind.

Einleitung

Die Migration in die Cloud war die dominierende IT-Strategie der letzten Dekade. Getrieben von Versprechen wie „unbegrenzter Skalierung“, „pay-as-you-go“ und „Zero Administration“ haben Unternehmen aller Größen Systeme, Daten und Prozesse in die Cloud verlagert — oft ohne die langfristigen Konsequenzen zu verstehen.

Heute beginnt eine Gegenbewegung. Nicht weil die Cloud gescheitert ist — sie hat ihre Vorteile —, sondern weil die Unternehmen, die in den letzten Jahren massiv in die Cloud gewandert sind, feststellen, dass die versprochene Einfachheit mit einem Preis kommt, der nicht nur finanziell ist.

Die Frage ist nicht mehr: „Cloud oder nicht?“ Die Frage ist: „Wofür Cloud, wofür On-Premise, und wie beides so kombinieren, dass die Souveränität über die eigenen Daten und Prozesse erhalten bleibt?“

Die Cloud-Revolution — und was sie wirklich verändert hat

Was die Cloud versprach

Die Argumente für die Cloud waren — und sind — attraktiv:

Skalierung. Mehr Last? Ein paar Klicks, und die Ressourcen sind da. Keine neue Hardware bestellen, kein Rack einbauen, kein Kabel ziehen. Die Cloud skaliert theoretisch unbegrenzt, und diese Skalierung ist innerhalb von Minuten verfügbar, nicht Wochen oder Monaten.

Geschwindigkeit. Eine neue Instanz starten, ein neues Deployment ausrollen, einen neuen Service aufsetzen — in der Cloud geht das in Minuten. On-Premise brauchte früher Tage oder Wochen für Hardware-Beschaffung und Einrichtung. In der Cloud ist alles sofort verfügbar.

Weniger Betriebsaufwand. Keine Server, die man warten muss. Keine Klimaanlage im Serverraum. Keine Hardware-Reparaturen am Freitagabend. Keine Ersatzteil-Lieferketten. Der Cloud-Provider kümmert sich um alles — Strom, Kühlung, Hardware, Netzwerk, physische Sicherheit.

Kapex vs. Opex. Statt hoher Investitionskosten (Capital Expenditure) für Hardware gibt es monatliche Betriebskosten (Operational Expenditure). Das ist für die Finanzabteilung attraktiv: planbare Kosten, keine Abschreibungen, keine Restwerte.

Managed Services. Datenbanken, Message Queues, Container-Orchestrierung, Authentication — alles als Service verfügbar. Kein Betrieb, keine Patches, keine Skalierungssorgen. Der Provider macht das.

Was die Cloud wirklich verändert hat

Die Cloud hat die Einstiegshürde massiv gesenkt. Das ist ihr größter Verdienst. Startups können heute innerhalb von Stunden eine Produktionsinfrastruktur aufbauen, die früher Wochen gedauert hätte. Kleine Unternehmen können auf Enterprise-Grade-Services zugreifen, ohne Enterprise-Grade-Personal zu brauchen.

Aber die Cloud hat auch die Wahrnehmung von IT-Kosten verzerrt. Die monatliche Rechnung fühlt sich anders an als eine einmalige Hardware-Investition — aber über drei bis fünf Jahre gerechnet ist sie oft teurer. Viel teurer. Und das ist nicht die einzige Überraschung.

Die Nachteile — die Rechnung kommt

Kostenentwicklung

Die Cloud ist billig, wenn man klein anfängt. Und sie wird teuer, wenn man wächst. Nicht linear teuer — exponentiell teuer.

Daten-Egress. Daten in die Cloud zu schicken ist kostenlos. Daten aus der Cloud herauszuholen kostet Geld. Das ist kein Zufall — es ist das Geschäftsmodell. AWS berechnet $0.09 pro GB für Daten-Transfer nach draußen. Bei einem Terabyte sind das $90. Bei zehn Terabyte $900. Und das ist nicht die einmalige Migration — das ist jede Replikation, jeder Backup-Restore, jeder Datenabgleich.

Storage-Kosten. S3-Storage kostet $0.023 pro GB und Monat (Standard-Tier). Das klingt wenig. Bei 50 TB sind das $1.150 pro Monat. Bei 500 TB — und das ist für mittelständische Unternehmen keine ungewöhnliche Größenordnung — sind es $11.500 pro Monat. $138.000 pro Jahr. Für Storage. Ohne Compute, ohne Netzwerk, ohne Managed Services.

Compute-Kosten. Eine m5.xlarge-Instanz bei AWS kostet ca. $0,192 pro Stunde. Das sind $1.682 pro Jahr. Eine vergleichbare Dedizierte-Server-Miete kostet ca. $200–400 pro Jahr. Faktor 4–8. Und bei Dediziert-Servern ist die Rechenleistung garantiert, nicht geteilt mit anderen Instanzen auf derselben Hardware.

Lizenz-Kosten. Microsoft-Lizenzen in der Cloud sind oft teurer als on-prem. Oracle-Lizenzen in der Cloud sind ein Albtraum. Red Hat Subscriptions in der Cloud kosten mehr als on-prem. Die Cloud macht Softwarelizenzen nicht billiger — sie macht sie teurer, weil die Cloud-Provider ihre Margen draufschlagen.

Der Faktor 3–10. Studien von 451 Research, IDC und mehreren Cloud-Financial-Management-Firmen zeigen konsistent: Über einen Zeitraum von 3–5 Jahren sind Cloud-Kosten für dauerhaft laufende Workloads 3- bis 10-mal höher als vergleichbare On-Premise-Kosten. Das gilt nicht für kurzlebige Workloads, nicht für Burst-Szenarien, nicht für Startups in der Wachstumsphase — aber für den typischen Dauerbetrieb mittelständischer und großer Unternehmen.

Vendor Lock-in

Die Cloud ist wie ein Hotel: Check-in ist einfach. Check-out ist das Problem.

Proprietäre Services. Wer AWS Lambda, DynamoDB, S3 Event Notifications, SQS, SNS und CloudFormation einsetzt, hat eine Architektur gebaut, die auf AWS funktioniert — und nur auf AWS. Die Migration weg davon ist nicht nur technisch aufwendig, sie ist organisatorisch eine Katastrophe, weil jede Komponente berührt werden muss.

Datenformate. Selbst wenn die Daten theoretisch portabel sind — SQL ist SQL, oder? —, sind die Unterschiede zwischen AWS Aurora, Google Cloud SQL und Azure Database für PostgreSQL substanziell genug, dass eine Migration kein einfacher Dump/Restore ist.

Operational Lock-in. Wer CloudFormation, Terraform-Provider-spezifische Module oder AWS CDK einsetzt, hat Infrastruktur-Code, der nicht portabel ist. Die IaC-Abstraktion, die eigentlich Unabhängigkeit schaffen sollte, ist selbst abhängig vom Provider.

Vertragsstrukturen. Reserved Instances, Savings Plans, Enterprise Agreements — die Vertragsstrukturen der Cloud-Provider sind darauf ausgelegt, Kunden langfristig zu binden. Der Rabatt für ein 3-Jahres-Commitment ist attraktiv, aber er bedeutet: Drei Jahre lang bezahlt man für Ressourcen, unabhängig davon, ob man sie noch braucht.

Datenhoheit

Wer seine Daten in der Cloud hat, hat sie nicht. Der Cloud-Provider hat sie. Und der Cloud-Provider hat eine Rechtsordnung, der er unterliegt.

Cloud Act. Der US-Cloud-Act von 2018 ermächtigt US-Behörden, Daten von US-Unternehmen auch dann einzufordern, wenn die Daten in einem Rechenzentrum außerhalb der USA liegen. AWS, Azure und Google sind US-Unternehmen. Das bedeutet: Daten, die bei diesen Providern liegen — egal ob in Frankfurt, Tokio oder Sydney — können von US-Behörden angefordert werden, ohne dass der Kunde davon erfährt.

GDPR. Die DSGVO verlangt, dass personenbezogene Daten in der EU verarbeitet werden oder ein angemessenes Schutzniveau besteht. Der EU-US Data Privacy Framework ist die aktuelle Lösung — aber er ist ein politisches Abkommen, kein technisches. Und er kann, wie sein Vorgänger (Privacy Shield), jederzeit für ungültig erklärt werden.

Datenzugriff durch Provider. Die AGB der großen Cloud-Provider erlauben ihnen Zugang zu Kunden-Daten in bestimmten Fällen — etwa bei Verdacht auf Missbrauch oder auf Anordnung eines Gerichts. Die Verschlüsselung der Daten ändert daran nichts, wenn der Provider die Schlüssel verwaltet.

Souveränität ist kein theoretisches Konzept. Für Unternehmen im öffentlichen Sektor, im Gesundheitswesen, in der Finanzindustrie und in kritischen Infrastrukturen ist Datenhoheit keine Frage der Präferenz, sondern der regulatorischen Pflicht. Wer Patientendaten, Finanzdaten oder Regierungsdaten in einer US-Cloud speichert, riskiert nicht nur Bußgelder — er riskiert den Entzug der Betriebserlaubnis.

Datenschutz

Datenschutz ist nicht dasselbe wie Datenhoheit. Datenhoheit fragt: Wer kann rechtlich auf meine Daten zugreifen? Datenschutz fragt: Wie schütze ich meine Daten vor unbefugtem Zugriff?

In der Cloud teilt man die Verantwortung mit dem Provider. Das „Shared Responsibility Model“ von AWS, Azure und Google ist klar definiert: Der Provider sichert die Infrastruktur, der Kunde sichert die Daten. Aber in der Praxis bedeutet das:

Der Provider hat physischen Zugriff auf die Hardware.
Der Provider kontrolliert das Hypervisor-Management.
Der Provider kann Memory-Dumps erstellen.
Der Provider hat Zugriff auf verschlüsselte Daten, wenn die Entschlüsselung in der Cloud stattfindet.

Das ist kein Misstrauen gegen die Provider. Es ist die Anerkennung einer Tatsache: Wer die Schlüssel nicht selbst verwaltet, hat keine volle Kontrolle über den Zugriff. Und „volle Kontrolle“ ist genau das, was Datenschutz in vielen Szenarien verlangt.

On-Premise ist nicht tot

Die Proklamation „On-Premise ist tot“ war die am häufigsten wiederholte Unwahrheit der letzten zehn Jahre. On-Premise war nie tot. On-Premise war nur nicht mehr sexy.

Was sich geändert hat

On-Premise bedeutet nicht mehr: Ein kalter Keller, ein Rack, ein überlasteter Administrator. Moderne On-Premise-Infrastruktur sieht anders aus:

Infrastructure as Code. Ansible, Terraform, Salt, Puppet — die gleichen Tools, die in der Cloud verwendet werden, funktionieren on-prem. Die Konfiguration ist versioniert, reproduzierbar, automatisiert. Der Unterschied zwischen Cloud und On-Premise ist nicht mehr die Automatisierung — es ist nur noch der Ort, wo die Hardware steht.

Virtualisierung ist gereift. Proxmox, bhyve, KVM — moderne Virtualisierungslösungen bieten Snapshots, Live-Migration, Resource-Pooling und Hochverfügbarkeit. Der Funktionsumfang ist mit Cloud-Virtualisierung vergleichbar, nur dass man die Hardware selbst kontrolliert.

ZFS. ZFS als Storage-Grundlage bietet Datenintegrität, Snapshots, inkrementelle Replikation, Kompression und Caching — alles, was man für robusten On-Premise-Storage braucht. ZFS macht den Unterschied zwischen „ein Filesystem“ und „ein Storage-Management-System“.

Container. Docker, Podman, Kubernetes on-prem — Container laufen nicht nur in der Cloud. Ein On-Premise-Kubernetes-Cluster mit Terraform-Provisioning und Ansible-Konfiguration ist kein Hexenwerk mehr.

Automatisches Patching. FreeBSD mit pkgbase, Ubuntu mit unattended-upgrades, Red Hat mit auto-updates — die Automatisierung von Security-Patches ist on-prem genauso möglich wie in der Cloud.

Stabilität

On-Premise-Infrastruktur ist stabil, wenn sie richtig gebaut ist. „Richtig gebaut“ heißt:

ZFS mit Redundanz. Mirror oder RAID-Z vdevs, reguläre Scrubs, Snapshots, Replikation auf einen zweiten Server.
CARP oder keepalived für Hochverfügbarkeit. Automatisches Failover bei Server-Ausfall.
Monitoring. Prometheus, Grafana, Alertmanager — die gleichen Tools wie in der Cloud.
Proaktive Wartung. ZFS-Scrubs wöchentlich, Smart-Monitoring für Disk-Failures, Firmware-Updates planvoll, nicht panisch.

Die Unterscheidung ist wichtig: Instabile On-Premise-Infrastruktur ist kein Argument gegen On-Premise. Es ist ein Argument gegen instabile Infrastruktur.

Sicherheit

On-Premise ist sicherer als die Cloud — wenn man die Security-Kontrolle nutzt, die man hat. In der Cloud gibt man physische Sicherheit und Netzwerk-Sicherheit an den Provider ab. On-Premise behält man beides:

Physische Kontrolle. Der Server steht im eigenen Rack. Kein fremder Administrator hat Zugriff. Kein Cloud-Provider-Mitarbeiter kann ein Image erstellen.
Netzwerk-Kontrolle. Die Firewall ist die eigene Firewall. Die Netzwerkstruktur ist die eigene Netzwerkstruktur. Es gibt keinen Shared-Tenant-Netzwerk-Pfad, über den ein anderer Cloud-Kunde Angriffe durchführen kann.
Verschlüsselung. Daten können on-prem verschlüsselt werden, mit eigenen Schlüsseln, eigener Verwaltung, eigenem KMS. Die Entschlüsselung findet auf der eigenen Hardware statt, nicht auf einem Server, der einem US-Konzern gehört.

Kosteneffizienz

Die Rechnung ist einfach, wenn man sie ehrlich macht:

Hardware-Anschaffung. Ein Server mit 256 GB RAM, 2x 1 TB NVMe und 4x 8 TB HDD kostet ca. 8.000–15.000 € — je nach Spezifikation. Geschrieben über 5 Jahre: 1.600–3.000 € pro Jahr.
Strom und Kühlung. Ca. 500–1.500 € pro Jahr pro Server, je nach Effizienz.
Netzwerk und Housing. Wenn man nicht selbst hostet: Colocation kostet ca. 100–300 € pro Monat pro HE. 1.200–3.600 € pro Jahr.
Personal. Das ist der größte Kostenfaktor — aber das Personal braucht man in der Cloud auch. Cloud-Infrastruktur managt sich nicht selbst.

Vergleich: Dieselbe Rechenleistung und denselben Storage in der Cloud kosten — konservativ geschätzt — 30.000–80.000 € pro Jahr. Bei wachsendem Storage-Volumen wird der Unterschied größer, nicht kleiner.

Der Break-Even liegt typischerweise bei 18–24 Monaten. Danach ist On-Premise günstiger. Und der Kostenvorteil wächst, weil die Hardware bezahlt ist, während die Cloud-Rechnung jeden Monat kommt.

Wann Cloud sinnvoll ist

Die Cloud ist nicht schlecht. Sie ist das falsche Default.

Cloud ist sinnvoll, wenn:

Burst-Workloads. Lastspitzen, die unvorhersehbar sind und kurzfristig viel Ressourcen brauchen. Black Friday, eine virale Kampagne, ein einmaliger Daten-Processing-Job. Die Cloud kann in Minuten skalieren und danach wieder schrumpfen. On-Premise muss die Hardware für den Worst Case vorhalten.

Prototyping und MVPs. Wenn man nicht weiß, ob ein Produkt funktioniert, ist die Cloud der richtige Ort. Keine Hardware-Investition, keine Verpflichtung. Wenn das Produkt funktioniert und die Last stabil wird, kann man migrieren.

Globale Verteilung. Wenn man Server in Singapur, São Paulo und Frankfurt braucht — in der nächsten Woche —, ist die Cloud die einzige Option. On-Premise braucht Zeit für Standortsuche, Hardware-Lieferung und Einrichtung.

Managed Services, die man selbst nicht betreiben will. Wenn man kein Elasticsearch-Expertise hat und nicht aufbauen will, dann ist AWS OpenSearch eine vernünftige Wahl. Wenn man kein Kafka-Cluster betreiben kann, dann ist Confluent Cloud eine Lösung. Der Schlüssel ist: Man wählt den Service bewusst, nicht als Default.

Kurzlebige Umgebungen. Test, Staging, CI/CD-Runner — Umgebungen, die man hochfährt, benutzt und wieder abschaltet. Die Cloud ist ideal für Ressourcen, die nicht 24/7 laufen müssen.

Wann On-Premise besser ist

On-Premise ist besser, wenn:

Dauerhafte Workloads. Workloads, die 24/7/365 laufen und deren Ressourcenbedarf vorhersehbar ist. Webserver, Datenbanken, Dateispeicher, interne Anwendungen — das ist das Kerngeschäft, und das gehört on-prem.

Große Datenmengen. Storage ist in der Cloud teuer. Bei 100+ TB wird die Rechnung absurd. On-Premise mit ZFS und großen Platten ist wirtschaftlich, und die Daten liegen dort, wo man sie kontrolliert.

Regulatorische Anforderungen. DSGVO, B3S, Kritis, Medizinprodukte-Verordnung — wenn der Gesetzgeber Datenhoheit verlangt, ist On-Premise keine Option, sondern eine Pflicht.

Langfristige Kosteneffizienz. Wenn man die Last für die nächsten 3–5 Jahre abschätzen kann, ist On-Premise günstiger. Deutlich günstiger.

Latenz-empfindliche Anwendungen. Die Netzwerk-Latenz zwischen Rechenzentrum und Nutzer ist on-prem minimiert. In der Cloud gibt es die Latenz zum nächsten Cloud-Region-Endpoint — und die ist für Echtzeit-Anwendungen nicht immer akzeptabel.

Daten, die nicht die Firma verlassen dürfen. Geheimnisse, Patente, Forschungsdaten, Kunden-Personas — es gibt Daten, die aus rechtlichen, ethischen oder strategischen Gründen nicht auf fremder Infrastruktur liegen dürfen.

Hybridmodelle — oft die beste Lösung

Die falsche Debatte ist „Cloud oder On-Premise“. Die richtige Debatte ist: „Was gehört wo hin?“

Das Prinzip der minimalen Cloud

Nutze die Cloud für das, was sie besser kann als On-Premise. Nutze On-Premise für alles andere. Das klingt banal, ist aber die Konsequenz einer ehrlichen Bewertung:

Stabile Kern-Workloads → On-Premise. Datenbanken, Dateispeicher, interne Anwendungen, Identity Management.
Burst- und Spitzenlast → Cloud. Zusätzliche Compute-Kapazität bei Lastspitzen, CI/CD-Runner, temporäre Testumgebungen.
Datenhoheit-kritische Daten → On-Premise. Alles, was regulatorisch oder strategisch geschützt werden muss.
Globale Services → Cloud. CDN, Edge-Computing, globale API-Endpunkte.
Managed Spezial-Services → Cloud. ML-Training, spezialisierte Datenbanken, Services, die man selbst nicht betreiben kann oder will.

Praktisches Hybrid-Setup

Ein konkretes Beispiel für ein mittelständisches Unternehmen:

On-Premise:

ZFS-Storage-Server mit 200 TB (Datenbanken, Dateispeicher, Backups)
Proxmox- oder bhyve-Cluster für interne Anwendungen
Git-Server (Gitea oder GitLab)
Identity Management (FreeIPA, Keycloak)
Monitoring (Prometheus, Grafana)
E-Mail-Server

Cloud:

CDN für die Website und statische Assets
Cloud-Runner für CI/CD (nur bei Bedarf)
Disaster Recovery: Replikation der kritischsten Daten in einen Cloud-Object-Store (verschlüsselt, mit eigenen Schlüsseln)
Burst-Compute für Lastspitzen (z.B. Quartalsende-Reporting)

Die monatliche Cloud-Rechnung für dieses Setup: vielleicht 500–2.000 €. Nicht 20.000 €. Nicht 50.000 €. Weil das Kerngeschäft on-prem läuft, und die Cloud nur das macht, was sie gut kann.

Die Rückkehr-Strategie

Für Unternehmen, die bereits massiv in der Cloud sind und die Kostenstruktur hinterfragen:

1. Inventur. Welche Workloads laufen in der Cloud? Welche davon laufen dauerhaft? Welche kosten am meisten?

2. Klassifikation. Welche Workloads sind Cloud-native (Lambda, DynamoDB, SQS)? Welche sind portabel (Docker-Container, Standard-Datenbanken, Webserver)?

3. Identifikation der Migrationskandidaten. Portable, dauerhafte Workloads mit hohem Daten-Volumen sind die besten Kandidaten für eine Rückkehr on-prem.

4. Pilot-Migration. Eine Workload auswählen, migrieren, Kosten vergleichen. Nicht alles auf einmal — iterativ vorgehen.

5. Optimierung. Nach der Migration: Cloud-Kosten für die verbleibenden Workloads optimieren. Reserved Instances, Spot-Instances, Right-Sizing.

Digitale Souveränität — mehr als ein Buzzword

Digitale Souveränität bedeutet: Die Fähigkeit, über die eigenen Daten, Prozesse und Infrastruktur selbst zu bestimmen. Nicht abhängig zu sein von einem einzelnen Provider, einem einzelnen Land, einer einzelnen Rechtsordnung.

Das ist kein nationalistisches Konzept. Es ist ein pragmatisches. Wer seine Infrastruktur nicht kontrolliert, kontrolliert sein Geschäft nicht. Wer seine Daten nicht kontrolliert, kontrolliert seine Zukunft nicht.

Die Cloud hat die Illusion erzeugt, dass Infrastruktur kein Problem mehr ist — man mietet sie ja einfach. Aber Infrastruktur war nie das Problem. Das Problem ist die Abhängigkeit. Und die Abhängigkeit ist in den letzten zehn Jahren größer geworden, nicht kleiner.

On-Premise ist die Antwort auf diese Abhängigkeit. Nicht als Absolutum — „alles on-prem“ ist genauso dogmatisch wie „alles Cloud“ —, sondern als bewusste Entscheidung: Was muss ich selbst kontrollieren? Was kann ich auslagern? Und wie stelle ich sicher, dass ich das Ausgelagerte bei Bedarf zurückholen kann?

Fazit

Die Cloud hat die IT-Landschaft verändert. Sie hat den Einstieg erleichtert, die Skalierung beschleunigt und die Betriebsmodelle transformiert. Aber sie hat auch Abhängigkeiten geschaffen, Kosten getrieben und Datenhoheit aufgeweicht.

On-Premise ist die Rückbesinnung auf das, was wirklich zählt: Kontrolle über die eigenen Daten, Kosteneffizienz für dauerhafte Workloads und Unabhängigkeit von einzelnen Providern.

Die beste Lösung ist Hybrid: Cloud für das, was die Cloud besser kann. On-Premise für alles andere. Und eine Architektur, die beides verbindet, ohne die Souveränität aufzugeben.

Die Unternehmen, die das verstehen, werden die nächsten zehn Jahre dominieren. Die anderen werden weiter monatliche Cloud-Rechnungen bezahlen — und sich fragen, warum ihre IT so teuer ist.

FreeBSD Wochenrückblick – 14. bis 20. April 2026

20. April 202620. April 2026 Thorsten Geppert Schreib einen Kommentar

Eine Übersicht der wichtigsten Entwicklungen, Sicherheitsmeldungen und Diskussionen rund um FreeBSD in der vergangenen Woche.

Release Engineering: 15.1 nähert sich der Slush-Phase

Am 17. April begann die stable/15-Slush-Phase im Vorfeld von FreeBSD 15.1. Der Zeitplan, den Release Engineering Lead Colin Percival bereits im Januar veröffentlicht hat, sieht wie folgt aus:

Meilenstein	Datum
Ports Quarterly Branch	1. April 2026
stable/15 Slush	17. April 2026
doc/ Tree Slush	24. April 2026
releng/15.1 Branch	1. Mai 2026
BETA1	1. Mai 2026
BETA2	8. Mai 2026
BETA3	15. Mai 2026
RC1	22. Mai 2026
RELEASE Build	29. Mai 2026
RELEASE Ankündigung	2. Juni 2026

Percival hatte bereits im Januar angemerkt, dass 15.1 angesichts der Erfahrungen mit 15.0 ein „relativ holpriges“ Minor Release werden könnte, insbesondere wegen weiterer pkgbase-Änderungen. Zeitgleich erreicht stable/13 Ende April sein End-of-Life – die wöchentlichen Snapshot-Builds für diesen Branch werden dann eingestellt.

Sicherheit: SA-26:08 – Kritischer Stack-Overflow in rpcsec_gss

Die wohl bemerkenswerteste sicherheitsrelevante Meldung der letzten Wochen betrifft FreeBSD Security Advisory SA-26:08, das einen Stack-Overflow in svc_rpc_gss_validate() beschreibt. Die Schwachstelle ermöglicht Remote Code Execution und betrifft alle unterstützten FreeBSD-Versionen. Patches sind verfügbar für 15.0-RELEASE-p5 und die 14.x-Serie.

Das besondere an diesem Advisory: Die Schwachstelle wurde von Nicholas Carlini mithilfe von Claude AI (Anthropic) entdeckt und exploitbar gemacht – ein frühes Beispiel dafür, wie KI-gestützte Sicherheitsforschung reale Kernel-Schwachstellen aufdeckt. Der Fix-Commit von Mark Johnston (143293c) behebt den Pufferüberlauf in der GSS-Validierungsroutine.

Q1-2026 Statusbericht veröffentlicht

Die FreeBSD Statusberichte für das erste Quartal 2026 sind nun online, darunter ein Update der Release Engineering Team, das die erfolgreiche Veröffentlichung von 14.4-RELEASE im März und die Planung für 15.1 dokumentiert.

Laptop-Projekt: Community-Testing aufgerufen

Die FreeBSD Foundation hat am 6. April einen Call for Testing für das Laptop Integration Testing Project veröffentlicht. Nach dem Year-One-Update im Februar wurde seit Januar an der Test-Infrastruktur gearbeitet. Nun können Community-Mitglieder ihre Laptops testen:

pkg install python hw-probe
git clone https://github.com/FreeBSDFoundation/freebsd-laptop-testing
cd freebsd-laptop-testing
make

Das Test-Tool erfasst automatisch Hardware-Funktionen und erstellt anonymisierte Berichte, die per Pull Request eingereicht werden. Die Ergebnisse fließen in eine öffentliche Kompatibilitätsmatrix unter freebsdfoundation.github.io/freebsd-laptop-testing.

OpenZFS: Native relatime-Eigenschaft

Am 1. April wurde in OpenZFS die native relatime-Eigenschaft implementiert (Commit 1685849 von @amotin). Relatime (relative atime) aktualisiert die Zugriffszeit einer Datei nur, wenn sie älter ist als die Änderungs- oder Statusänderungszeit. Das reduziert unnötige Schreibzugriffe erheblich – besonders auf SSDs und in Caches – und war bisher nur über Mount-Optionen konfigurierbar. Mit der neuen Eigenschaft kann relatime nun nativ pro Dataset gesetzt werden.

Ports: GNU-ld-Checks entfernt

Brooks Davis hat am 13. April einen umfangreichen Cleanup-Commit (d87609e) in die Ports eingebracht, der alle Überprüfungen entfernt, ob der Basis-Linker GNU ld ist oder nicht. Hintergrund: Seit FreeBSD den LLVM-Linker lld als Standard verwendet, sind diese Checks obsolet geworden. Der Commit betrifft Ports tree-weit zahlreiche Makefiles.

Mailinglisten

IPv6-Only-RA: Wechsel zu RFC 8925 vorgeschlagen

Pouria Mousavizadeh Tehrani hat auf freebsd-current einen Vorschlag eingereicht, die experimentelle Implementierung des IETF-Drafts DRAFT_IETF_6MAN_IPV6ONLY_FLAG zu entfernen und stattdessen RFC 8925 (IPv6-Only-Präferenz über DHCP-Option) zu übernehmen. Die Geschichte dahinter ist interessant: Bjoern Zeeb hatte ursprünglich die Idee, Netzwerke über ein RA-Flag als IPv6-Only zu markieren. Der Draft wurde jedoch verworfen, weil RAs trivial gefälscht werden können – ein Angreifer könnte IPv4-Netzwerke böswillig abschalten. Später reichte Google die gleiche Idee als DHCP-Option ein, was zu RFC 8925 wurde. Pouria bittet um Feedback zur Entfernung der Draft-spezifischen Codepfade aus Kernel und Userland.

Kqueue-Panic: knlist-Assertionen nachgerüstet

Auf freebsd-current wurde ein Kernel-Panic gemeldet: „knote was already on knlist“ nach dem Build main-n284826. Kyle Evans (kevans91) hat daraufhin Assertionen in knlist_add() und knlist_remove_kq() nachgerüstet (Commit 306c904), um solche Fehlerzustände früher und zuverlässiger zu erkennen. Der zugehörige Bugreport (Bug 293382) beschreibt Deadlocks und Abstürze rund um closefp_impl – ein Hinweis darauf, dass das Problem mit dem Schließen von File Descriptoren und der kqueue-Registrierung zusammenhängt.

Warum robuste Infrastruktur wichtiger ist als moderne Tools

19. April 202619. April 2026 Thorsten Geppert Schreib einen Kommentar

Jedes Jahr erscheinen hunderte neue Frameworks, Plattformen und Tools. Jedes verspricht mehr Produktivität, schnellere Entwicklung, bessere Zusammenarbeit. Und jedes Jahr investieren Firmen Zeit und Geld in die Evaluierung, Einführung und Migration auf das nächste große Ding — während die Grundlagen ihrer Infrastruktur vor sich hin rotten.

Das ist kein rhetorisches Bild. Das ist Beobachtung.

Die Versuchung des Neuen

Es ist verständlich. Ein neues CI/CD-Tool verspricht, Deployments von 45 Minuten auf 3 Minuten zu reduzieren. Ein neues Monitoring-Tool verspricht bessere Dashboards. Ein neues Container-Orchestrierungstool verspricht Skalierbarkeit auf Knopfdruck. Das sind attraktive Versprechen, und sie sind oft sogar echt.

Das Problem ist nicht, dass neue Tools schlecht sind. Das Problem ist, dass sie von den Grundlagen ablenken. Denn die Frage, ob ein Deployment 3 Minuten oder 45 Minuten dauert, ist irrelevant, wenn die Datenbank bei einem Disk-Ausfall weg ist und kein Backup existiert.

Die Frage, ob man Kubernetes oder Nomad oder Docker Swarm einsetzt, ist zweitrangig, wenn der Storage darunter mit einem Filesystem läuft, das keine Prüfsummen bildet, keine Snapshots kann und bei einem Bit-Flip einfach korrupte Daten durchreicht.

Die Frage, welches Monitoring-Tool das schönste Dashboard hat, ist nachrangig, wenn es niemanden gibt, der die Alerts versteht und weiß, was zu tun ist, wenn sie auslösen.

Was Firmen ignorieren

Storage-Architektur

Storage ist das Fundament. Alles, was eine IT-Infrastruktur leistet, landet irgendwann auf Storage. Datenbanken, Konfigurationen, Logs, Benutzerdaten, Backups — alles. Und trotzdem wird Storage oft behandelt wie Strom aus der Steckdose: Man geht davon aus, dass es da ist, und denkt nicht weiter darüber nach.

Die Realität sieht anders aus. In vielen Firmen läuft der Storage auf Hardware-RAID-Controllern, die niemand überwacht. Auf Filesystemen, die keine Datenintegrität garantieren. Auf LVM-Volumes, die bequem zu verwalten sind, aber bei einem Ausfall keine Recovery-Option bieten. Auf NFS-Shares, deren Performance bei Concurrent Access zusammenbricht, aber niemand hat je getestet, was passiert, wenn 50 Entwickler gleichzeitig bauen.

Und dann passiert das Unvermeidliche: Ein Disk-Set fällt aus. Ein RAID-5 verliert eine zweite Platte während des Rebuilds. Ein Controller-Firmware-Bug korruptiert den Write-Cache. Und plötzlich ist die Frage nicht mehr, wie schnell das Deployment ist, sondern ob die Daten noch existieren.

Backup

Backup ist der am häufigsten ignorierte Bestandteil einer Infrastruktur. Nicht, weil niemand weiß, dass man Backups braucht — sondern weil Backup langweilig ist. Es gibt keine Konferenz-Talks über Backup-Strategien. Es gibt keine Hacker News-Diskussionen über inkrementelle Sicherung. Es gibt keine X-Threads über den Unterschied zwischen Voll-, Differenzial- und Inkrementell-Backup.

Was es gibt: Firmen, die nach einem Ausfall feststellen, dass ihre Backups seit Monaten nicht mehr liefen. Firmen, die ihre Backups nie getestet haben und beim Restore feststellen, dass die Bänder leer sind. Firmen, die ihre Backups auf demselben Storage liegen haben wie die Produktionsdaten und bei einem Ransomware-Angriff alles verlieren.

Die drei unbequemen Wahrheiten über Backup:

Ein Backup, das nicht getestet wurde, ist kein Backup. Es ist ein Hoffnungsspeicher.
Ein Backup auf demselben System wie die Quelldaten ist kein Backup. Es ist eine Kopie, die denselben Risiken ausgesetzt ist.
Ein Backup ohne definierte Retention-Policy ist kein Backup. Es ist ein wachsender Haufen von Daten, den irgendwann niemand mehr versteht.

Filesystem-Konfiguration

Das Filesystem ist die Schicht zwischen der Hardware und allem, was darauf läuft. Es entscheidet, ob Daten sicher geschrieben werden, ob sie nach einem Crash noch lesbar sind, ob sie vor stiller Korruption geschützt sind.

Die meisten Server laufen auf ext4 oder XFS. Das sind solide Filesysteme, aber sie haben eine entscheidende Einschränkung: Sie haben keine eingebaute Datenintegritätsprüfung. Wenn ein Bit auf der Platte kippt — und das passiert häufiger, als man denkt — dann liest ext4 einfach das falsche Datum und reicht es durch. Kein Fehler. Keine Warnung. Nur stille Korruption.

ZFS löst dieses Problem. ZFS bildet Prüfsummen über alle Datenblöcke und verifiziert sie bei jedem Lesezugriff. Wenn ein Bit kippt, bemerkt ZFS es — und repariert es automatisch, wenn Redundanz vorhanden ist. Das ist kein theoretisches Risiko: Studien von CERN und NetApp zeigen Bit-Error-Raten von 10^-16 bis 10^-17 pro Bit gelesener Daten. Bei einem Petabyte an Daten bedeutet das: Es passiert. Regelmäßig.

Aber ZFS ist mehr als Prüfsummen. Es ist Snapshots, die in Sekunden erstellt werden und null Space kosten. Es ist Send und Recv für inkrementelle Replikation. Es ist Compression, die Storage spart und Lese-Performance verbessert. Es ist Copy-on-Write, das bei einem Crash nie ein inkonsistentes Filesystem hinterlässt.

Wer ZFS nicht nutzt, nutzt meist kein Filesystem mit Datenintegritätsgarantie. Das ist eine bewusste Entscheidung gegen Datenintegrität.

Systemarchitektur

Architektur ist nicht dasselbe wie Design. Design ist: Welche Technologie setze ich ein? Architektur ist: Wie hängen die Dinge zusammen? Was passiert, wenn etwas ausfällt? Wer ist für was verantwortlich? Wie kommunizieren die Komponenten?

Viele Firmen haben keine Architektur. Sie haben eine historisch gewachsene Ansammlung von Servern, Services und Abhängigkeiten, die niemand vollständig überblickt. Dokumentation existiert nicht oder ist veraltet. Abhängigkeiten sind implizit: Service A braucht Service B, aber das steht nirgends, und wenn Service B ausfällt, fragt sich Service A, warum es nicht mehr funktioniert.

Die Konsequenz: Jeder Ausfall wird zum Abenteuer. Nicht, weil das Problem schwer wäre, sondern weil niemand weiß, wie die Systeme zusammenhängen und wo man ansetzen muss.

Was robuste Infrastruktur ausmacht

ZFS — Das Fundament

ZFS ist nicht nur ein Filesystem. Es ist ein Storage-Manager, der Datenintegrität, Snapshots, Replikation, Kompression und Caching in einem System vereint. Wer ZFS einsetzt, hat eine Antwort auf die Fragen, die andere nicht einmal stellen:

Sind meine Daten noch intakt? Ja, weil ZFS Prüfsummen bildet und bei jedem Lesen verifiziert.
Kann ich einen Snapshot machen? Ja, in Sekunden, ohne Downtime, ohne Space-Kosten für unveränderte Blöcke.
Kann ich replizieren? Ja, inkrementell, mit zfs send und zfs recv, lokal oder remote.
Was passiert bei einem Crash? Das Filesystem ist immer konsistent, weil Copy-on-Write atomar schreibt.

ZFS ist die Grundlage, auf der alles andere aufbaut. Backup-Strategien werden mit Snapshots trivial. Disaster Recovery wird mit Replikation planbar. Storage-Performance wird mit ARC und L2ARC vorhersehbar.

Saubere Backup-Strategien

Backup ist keine Technologie, es ist eine Strategie. Die Technologie — ob Bacula, Borg, Restic, Amanda, oder einfach zfs send — ist der einfache Teil. Die Strategie ist die Entscheidung:

Was wird gesichert? Nicht alles ist gleich wichtig. Datenbanken sind kritischer als Log-Dateien. Konfigurationen sind kritischer als temporäre Dateien. Die Klassifikation entscheidet über Häufigkeit und Aufbewahrungsdauer.
Wie oft? Stündlich, täglich, wöchentlich — je nach Änderungsrate und Kritikalität. Eine Datenbank, die sich jede Sekunde ändert, braucht andere Backup-Frequenzen als eine Konfigurationsdatei, die sich einmal im Monat ändert.
Wohin? Die 3-2-1-Regel gilt: 3 Kopien, auf 2 verschiedenen Medien, 1 Offsite. Wer diese Regel nicht einhält, hat keine Backup-Strategie — er hat Datenkopien.
Wird getestet? Restore-Tests müssen regelmäßig stattfinden. Nicht einmal im Jahr. Mindestens einmal im Quartal, besser öfter. Denn ein ungetestetes Backup ist kein Backup.

Klare Systemarchitektur

Eine klare Architektur beantwortet drei Fragen:

Was hängt wovon ab? Abhängigkeitsgraphen müssen dokumentiert sein. Wenn Service A Service B braucht, muss das explizit sein — nicht implizit durch einen irgendwo konfigurierten Connection String.
Was passiert bei Ausfall? Für jede Komponente muss klar sein, was passiert, wenn sie ausfällt: Failover-Mechanismus, Graceful Degradation, oder Totalausfall. Und wer zuständig ist, wenn es passiert.
Wie wird deployt? Deployment muss reproduzierbar sein. Ob via Ansible, Puppet, Salt, oder ein Shell-Skript — wichtig ist, dass der Zustand eines Servers aus der Konfiguration abgeleitet werden kann, nicht aus der Erinnerung des Administrators.

Die Praxis

Ausfälle verkraften

Robuste Infrastruktur ist nicht Infrastruktur, die nie ausfällt. Das gibt es nicht. Robuste Infrastruktur ist Infrastruktur, die Ausfälle verkraftet — ohne Datenverlust, ohne langwierige Recovery, ohne Panik.

Was das konkret heißt:

Storage-Redundanz. ZFS mit Mirror oder RAID-Z vdevs. Kein Single-Point-of-Failure auf Plattendenebene.
Service-Redundanz. CARP, keepalived, oder DNS-Failover für kritische Services. Kein Single-Server-Setup für etwas, das immer verfügbar sein muss.
Netzwerk-Redundanz. Mindestens zwei Uplinks, zwei Switches, zwei Pfad. LACP für Link-Aggregation. OSPF oder BGP für Routing-Failover, wenn die Infrastruktur groß genug ist.
Power-Redundanz. Zwei Stromkreise, USV, Generator — je nach kritikalität. Wer seinen Serverraum an eine einzige Phase anschließt, hat kein Power-Konzept.

Reproduzierbar sein

Wenn ein Server ausfällt und ein neuer aufgesetzt werden muss, darf die Frage nicht sein: „Wie war das konfiguriert?“ Die Antwort muss sein: „Konfiguration aus dem Repository ziehen und anwenden.“

Infrastructure as Code ist kein Buzzword, es ist eine Notwendigkeit. Wer Server manuell konfiguriert, hat eine Infrastruktur, die nicht reproduzierbar ist. Und eine Infrastruktur, die nicht reproduzierbar ist, ist eine Infrastruktur, die bei Ausfall nicht wiederhergestellt werden kann — nicht innerhalb eines vertretbaren Zeitrahmens.

Die Tools dafür existieren: Ansible für Konfigurationsmanagement, Terraform für Infrastruktur-Provisioning, Packer für Image-Erstellung. Aber das Wichtigste ist nicht das Tool — es ist die Disziplin, jedes Change durch die Pipeline zu schicken, nicht direkt auf dem Server.

Verständlich bleiben

Die wichtigste Eigenschaft einer Infrastruktur ist nicht ihre Eleganz, sondern ihre Verständlichkeit. Wenn ein neuer Administrator die Infrastruktur erklärt bekommt und innerhalb einer Woche produktiv arbeiten kann, ist die Architektur gut. Wenn er nach drei Monaten noch nicht versteht, wie die Systeme zusammenhängen, ist die Architektur schlecht.

Verständlichkeit entsteht durch:

Dokumentation. Nicht als Afterthought, sondern als Teil des Setups. Jeder Service bekommt eine Dokumentation: Was ist das? Wie hängt es zusammen? Wie wird es deployt? Was passiert bei Ausfall?
Konsistenz. Gleiche Konventionen überall. Gleiche Verzeichnisstrukturen, gleiche Benennungsschemata, gleiche Prozesse. Wer bei jedem Server nachdenken muss, wo die Konfiguration liegt, verschwendet Zeit.
Einfachheit. Kein Kubernetes-Cluster für drei Container. Kein Service-Mesh für eine interne Anwendung. Kein verteiltes System, wo ein einzelner Server reicht. Komplexität ist der Feind von Verständlichkeit.

Die unbequeme Wahrheit

Moderne Tools sind attraktiv, weil sie sichtbare Ergebnisse liefern. Ein neues Deployment-Tool zeigt sofort: Das Deployment ist schneller. Ein neues Monitoring-Tool zeigt sofort: Die Dashboards sind schöner. Ein neues Framework zeigt sofort: Die Features sind da.

Infrastruktur-Grundlagen sind unsichtbar. ZFS-Prüfsummen zeigen keinen Unterschied, solange alles funktioniert. Backup-Strategien zeigen keinen Unterschied, solange kein Ausfall passiert. Architektur-Dokumentation zeigt keinen Unterschied, solange dieselben Leute arbeiten.

Der Unterschied zeigt sich erst, wenn etwas schiefgeht. Und dann ist es zu spät, die Grundlagen nachzuholen.

Die unbequeme Wahrheit ist: Die Zeit, die man in Storage, Backup, Filesystem und Architektur investiert, zahlt sich nicht in Sprint-Demos aus. Sie zahlt sich nicht in Quarterly Business Reviews aus. Sie zahlt sich nicht in Twitter-Threads aus.

Sie zahlt sich aus, wenn der Storage ausfällt und die Daten noch da sind. Sie zahlt sich aus, wenn Ransomware zuschlägt und das Restore in Stunden statt Wochen läuft. Sie zahlt sich aus, wenn der Hauptadministrator kündigt und der neue innerhalb einer Woche produktiv ist.

Das ist nichts, was man in einem Slide-Deck zeigen kann. Aber es ist alles, was zählt.

Fazit

Investiert in die Grundlagen. Nicht als Ersatz für moderne Tools — sondern als Voraussetzung. Ein neues CI/CD-System auf einer Infrastruktur ohne Backup ist wie ein Rennmotor in einem Auto ohne Bremsen. Schnell, solange alles funktioniert. Tödlich, wenn nicht.

Die Reihenfolge ist:

Storage — ZFS, Redundanz, Datenintegrität
Backup — 3-2-1-Regel, Restore-Tests, Offsite-Kopie
Architektur — Abhängigkeiten, Failover, Dokumentation
Reproduzierbarkeit — Infrastructure as Code, kein manuelles Konfigurieren
Verständlichkeit — Konsistenz, Einfachheit, Dokumentation

Und dann, wenn das Fundament steht: Die modernen Tools. Aber auf einem Fundament, das hält.

Automatisierung als Geschäftsmodell: Warum IT-Dienstleister ohne Automatisierung untergehen

13. April 202613. April 2026 Thorsten Geppert Schreib einen Kommentar

Wer IT-Dienstleistungen verkauft, hat ein Problem: Seine Zeit ist begrenzt. Jede Stunde, die er an einem Kundensystem verbringt, ist eine Stunde, die er nicht für einen anderen Kunden aufwenden kann. Das Geschäftsmodell des klassischen IT-Dienstleisters — Stunden abrechnen, Probleme manuell lösen, individuell betreuen — hat eine harte Decke.

Automatisierung ist der Weg durch diese Decke. Und wer als Softwareentwickler und Administrator die Werkzeuge beherrscht, hat einen entscheidenden Vorteil: Er kann Automatisierung nicht nur anwenden, sondern bauen.

Das Problem mit dem Stundensatz

Ein klassischer IT-Dienstleister verrechnet vielleicht 80 bis 120 Euro pro Stunde. Wenn er 40 Stunden in der Woche arbeitet (realistisch sind es weniger, weil Akquise, Verwaltung und Reisezeit abgehen), ergibt das eine Umsatzdecke von etwa 160.000 bis 240.000 Euro im Jahr. Davon gehen Steuern, Versicherungen, Fortbildung, Arbeitsplatzkosten ab.

Skalierung ist in diesem Modell nur möglich, indem man Mitarbeiter einstellt. Aber jeder Mitarbeiter bringt neuen Verwaltungsaufwand, Schulungsbedarf, Qualitätskontrolle. Der Gewinn pro Kopf sinkt, wenn man nicht gleichzeitig die Effizienz steigert.

Was Automatisierung ändert

Automatisierung verändert die Mathematik. Statt eine Aufgabe einmal pro Kunde manuell zu erledigen, baut man sie einmal — und deployt sie x-mal.

Beispiel: Ein Kunde braucht einen Webserver mit Nginx, PHP-FPM, SSL-Zertifikaten und einer Monitoring-Lösung. Manuell dauert das — wenn man ehrlich ist — einen halben Tag. Mit Automatisierung dauert es beim ersten Kunden auch einen halben Tag (zuzüglich der Zeit für das Skript/Playbook). Bei jedem weiteren Kunden dauert es fünf Minuten.

Der Effekt: Die Kosten pro Deployment sinken drastisch, während die Qualität steigt. Automatisierte Deployments sind reproduzierbar, testbar, dokumentiert. Manuelle Deployments sind — wie oben beschrieben — Schneemänner.

Konkrete Automatisierungsfelder

Systemadministration

Alles, was auf einem Server konfiguriert wird, kann automatisiert werden:

Server-Setup — Basiskonfiguration, Benutzer, SSH-Keys, Firewall-Regeln
Dienst-Konfiguration — Webserver, Datenbanken, Mailserver, Monitoring
Updates und Patching — Automatisierte Aktualisierungen mit Rollback-Möglichkeit
Backup und Recovery — ZFS-Snapshots, Replikation, automatisierte Restore-Tests

Kundenschnittstelle

Onboarding — Neukunden bekommen automatisch ihre Infrastruktur
Reporting — Wöchentliche Statusberichte automatisch generiert und versendet
Abrechnung — Nutzungsbasierte Abrechnung direkt aus Monitoring-Daten
Ticket-Routing — Automatische Zuordnung von Support-Anfragen

Compliance und Dokumentation

Audit-Logs — Jede Änderung an der Infrastruktur ist in Git dokumentiert
Compliance-Checks — Automatisierte Überprüfung von Sicherheitsstandards
Disaster-Recovery-Tests — Regelmäßige, automatisierte Tests der Wiederherstellungsprozesse

Der Preis der Automatisierung

Automatisierung ist nicht kostenlos. Sie erfordert:

Zeit. Die Erstellung eines robusten Ansible-Playbooks dauert länger als die manuelle Konfiguration eines einzelnen Servers. Die Investition amortisiert sich erst ab dem zweiten oder dritten Deployment.

Kompetenz. Wer automatisiert, muss programmieren können. Nicht auf dem Niveau eines Software-Entwicklers, aber ausreichend, um Skripte zu schreiben, Datenstrukturen zu verstehen und Fehler zu diagnostizieren.

Wartung. Automatisierte Prozesse müssen gepflegt werden. Wenn sich Upstream-Software ändert, müssen die Playbooks angepasst werden. Wenn neue Anforderungen dazukommen, müssen sie integriert werden.

Aber — und das ist der entscheidende Punkt — diese Kosten fallen einmal an. Die manuellen Kosten fallen jedes Mal an.

Vom Dienstleister zum Produkt

Die konsequente Automatisierung öffnet einen Weg, der über das Dienstleistungsgeschäft hinausgeht: den Übergang zum Produkt.

Wenn die Infrastruktur-Einrichtung automatisiert ist, kann man sie als Self-Service anbieten. Der Kunde wählt seine Konfiguration über ein Web-Interface, das System richtet alles automatisch ein, und der Dienstleister muss nur noch überwachen und bei Problemen eingreifen.

Das ist der Weg, den erfolgreiche IT-Unternehmen gegangen sind: Hetzner mit der Robot-Weboberfläche, GitLab mit seinem CI/CD-Produkt, HashiCorp mit Terraform Cloud. Alle haben begonnen, Dienstleistungen manuell zu erbringen, und sie dann in Produkte verwandelt.

Für kleine IT-Dienstleister bedeutet das nicht, dass man ein SaaS-Startup werden muss. Aber es bedeutet, dass man seine wiederkehrenden Aufgaben identifizieren, automatisieren und als Paket anbieten kann — zu einem Preis, der manuell nicht erreichbar ist.

Der erste Schritt

Wer mit Automatisierung anfangen will, sollte nicht versuchen, alles auf einmal umzustellen. Der beste erste Schritt ist:

Den häufigsten wiederkehrenden Prozess identifizieren
Ihn einmal vollständig automatisieren
Die Zeitersparnis messen
Den nächsten Prozess angehen

Bei mir war das die ZFS-Replikation mit Syncoid. Ein Prozess, der vorher jeden Abend manuell überprüft werden musste und regelmäßig Probleme verursacht hat. Nach der Automatisierung läuft er im Hintergrund — zuverlässig, reproduzierbar, fehlerfrei.

Die Zeit, die ich dadurch gewonnen habe, habe ich in die nächste Automatisierung investiert. Und die nächste. Irgendwann war der Punkt erreicht, an dem ich mehr Zeit für echte Problemlösung hatte als für wiederkehrende Aufgaben.

Das ist das Versprechen der Automatisierung. Und es hält, was es verspricht — wenn man den anfänglichen Aufwand investiert.

FreeBSD-Wochenrückblick: 6.–13. April 2026

13. April 202613. April 2026 Thorsten Geppert Schreib einen Kommentar

Die Kalenderwoche 15 bringt Bewegung in mehrere Baustellen: Der 15.1-Zeitplan ist offiziell, das Laptop-Projekt ruft zum Community-Test auf, OpenZFS bekommt endlich eine native relatime-Property, und auf freebsd-current wird hitzig über IPv6-only-RA-Flags und einen knote-Panic diskutiert.

FreeBSD 15.1: Zeitplan veröffentlicht, Code Slush am 17. April

Am 3. April verschickten die Release Engineers die offizielle Zeitplan-Erinnerung für FreeBSD 15.1. Die wichtigsten Termine:

Meilenstein	Geplant
Code Slush beginnt	17. April 2026
releng/15.1-Branch	1. Mai
BETA1	1. Mai
RC1	22. Mai
RELEASE	2. Juni

Der Code Slush startet also noch diese Woche: Ab dem 17. April sollten keine neuen Features mehr in den stable/15-Branch eingefügt werden. Commits sind weiterhin möglich, aber der Fokus verlagert sich auf Stabilität und Bugfixes.

Die Release Notes-Seite existiert bereits und listet die geplanten Neuerungen: KDE-Plasma-6-Installer-Option, verbesserte Realtek-WiFi-Unterstützung (RTW88/RTW89), aktualisierte Grafiktreiber und erweiterte Power-Management-Features.

Was das heißt: Wer noch Änderungen für 15.1 einbringen will, hat noch wenige Tage. Danach geht es in die Beta-Phase.

Laptop-Integration-Testing-Projekt: Aufruf an die Community

Die FreeBSD Foundation hat ein neues Community-Test-Programm ins Leben gerufen: das Laptop Integration Testing Project. LWN berichtete am 6. April darüber.

Die Idee: Die Foundation hat begrenzten Zugang zu Test-Hardware und will die Community einbinden. Freiwillige können FreeBSD auf ihrem Laptop testen und Ergebnisse über ein GitHub-Repository einreichen — ohne sich um Umgebungssetup, Formatierung oder Repo-Details kümmern zu müssen.

Besonders wertvoll: Nicht nur automatisierte Hardware-Erkennung, sondern auch manuelle Kommentare zur persönlichen Erfahrung mit FreeBSD auf dem jeweiligen Gerät. Die Ergebnisse werden in einer öffentlichen Kompatibilitäts-Matrix dargestellt.

Was das heißt: Endlich ein strukturierter Weg, Laptop-Kompatibilität zu dokumentieren. Wer FreeBSD auf einem Laptop nutzt, sollte das Repository besuchen und Ergebnisse einreichen — jeder Eintrag zählt.

Repository: github.com/FreeBSDFoundation/freebsd-laptop-testing

OpenZFS: Native `relatime`-Property für FreeBSD

Alexander Motin (amotin) hat am 1. April einen lang erwarteten Commit in OpenZFS gemerged: relatime als native ZFS-Property auf FreeBSD.

Bisher mussten FreeBSD-Nutzer, die relatime (relative Access-Time-Updates — atime wird nur geschrieben, wenn sie älter als mtime/ctime ist oder älter als 24 Stunden) nutzen wollten, auf den Mount-Option-Workaround zurückgreifen. Mit dem neuen Commit wird relatime zu einer echten ZFS-Dataset-Eigenschaft, die sich per zfs set relatime=on pool/dataset setzen lässt.

Die Implementierung folgt der Linux-Kernel-Logik: atime wird nur aktualisiert, wenn mindestens eine der Bedingungen erfüllt ist:

atime < mtime
atime < ctime
atime älter als 24 Stunden

Was das heißt: Weniger unnötige ZFS-Writes bei Lesezugriffen, besonders auf SSDs und Laptops. Wer atime=on braucht (z.B. für Maildir oder Backup-Tools), kann jetzt relatime=on setzen und bekommt das Beste aus beiden Welten.

Mailinglisten: IPv6-only-RA-Flag soll weichen

Pouria Mousavizadeh Tehrani hat am 2. April auf freebsd-current einen Vorschlag zur Diskussion gestellt: Die Entfernung der IPv6-only-RA-Draft-Implementierung zugunsten von RFC 8925 (DHCP-basierter Ansatz).

Hintergrund: Bjoern Zeeb hatte eine IPv6-only-Flag-Implementierung als IETF-Draft eingereicht, die auch im FreeBSD-Kernel und Userland vorhanden ist (standardmäßig nicht kompiliert, hinter DRAFT_IETF_6MAN_IPV6ONLY_FLAG). Das Draft wurde jedoch vom IETF aufgegeben, weil RA-Flags trivial fälschbar sind und für Malicious-Disabling von IPv4-Netzwerken missbraucht werden könnten. RFC 8925 verwendet stattdessen eine DHCP-Option, die in der Praxis durch DHCP Snooping besser geschützt ist.

Pouria bittet um Zustimmung, die Draft-spezifischen Codepfade zu entfernen und auf RFC 8925 zu migrieren. Bjoern ist cc’d, und die Diskussion läuft.

Was das heißt: Wer die experimentelle IPv6-only-RA-Flag nutzt, sollte auf RFC 8925 umsteigen. Die Code-Bereinigung ist ein guter Schritt — weniger tote Pfade im Kernel.

Mailinglisten: knote-Panic und etcupdate-Verlangsamung

Zwei aktuelle Probleme auf freebsd-current:

knote-Panic: Nach Commit d9d7b5948649 (main-n284826) tritt bei einigen Nutzern ein Panic auf: "knote ... was already on knlist...". Konstantin Belousov und Kyle Evans arbeiten an der Diagnose. Der Bug (Bugzilla #293382) betrifft closefp_impl und kann zu Deadlocks und Kernel-Crashes führen. Betroffen sind -CURRENT-Nutzer nach dem 2. April.

etcupdate doppelt so langsam: Bob Prohaska berichtet, dass etcupdate auf armv7 (Raspberry Pi 2) mittlerweile doppelt so lange dauert wie früher. Die Diskussion mit Dimitry Andric und Mark Millard legt nahe, dass die Ursache in der pkgbase-Umstellung und der veränderten Dateistruktur liegt — etcupdate muss mehr Dateien prozessieren.

Was das heißt: -CURRENT-Nutzer sollten den knote-Bug im Blick behalten. Auf armv7-Systemen lohnt es sich, etcupdate-Alternativen wie mergemaster zu evaluieren, bis das Problem behoben ist.

Ports: Chromium 146 und Security-Updates

Die Ports-Collection hat in dieser Woche mehrere Updates erhalten:

Chromium 146.0.7680.177 (1. April, René Nagy) — aktuelles Major-Release
Zuvor: Chromium 146.0.7680.164 mit VuXML-Eintrag für Sicherheitslücken in Versionen < 146.0.7680.164
Chromium 30. März: Revert eines Upstream-Commits, der das Datei-Dialog-Verhalten auf FreeBSD kaputtgemacht hatte

Die kontinuierlichen Chromium-Updates zeigen, dass die FreeBSD-Ports-Maintainer aktiv sind — aber auch, dass Upstream-Commits regelmäßig FreeBSD-spezifische Regressionen verursachen.

Neuer Committer: Kenneth Raplee

Am 4. April wurde Kenneth Raplee (kenrap@FreeBSD.org) als neuer Ports-Committer angekündigt. Willkommen im Projekt!

Ausblick auf die kommende Woche

17. April: Code Slush für 15.1 beginnt — letzte Chance für Feature-Commits
Der knote-Bug in -CURRENT braucht einen Fix
Die IPv6-only-RA-Diskussion könnte zu einem Commit führen
Das Laptop-Testing-Projekt hofft auf erste Community-Ergebnisse

Syncoid: ZFS-Replikation ohne Umwege

9. April 20269. April 2026 Thorsten Geppert Schreib einen Kommentar

Wer ZFS nutzt, kennt das Gefühl: Man hat Snapshots, man hat zfs send und zfs recv, und theoretisch ist alles möglich. Praktisch steht man dann vor einer Pipe aus drei Befehlen, fragt sich, ob --verbose vor oder hinter -R gehört, und stellt fest, dass der inkrementelle Sendevorgang um Mitternacht abgebrochen hat, weil irgendein Snapshot auf der Zielseite fehlte.

Genau hier setzt Syncoid an.

Was ist Syncoid?

Syncoid ist Teil des Sanoid-Projekts von Jim Salter und beschreibt sich selbst schlicht als Replikationstool für ZFS. Das klingt bescheidener, als es ist. Tatsächlich löst Syncoid genau die Probleme, die jeden treffen, der ernsthaft ZFS-Daten zwischen Maschinen bewegen will:

Es findet selbst heraus, welcher Snapshot der letzte gemeinsame ist.
Es erzeugt bei Bedarf einen neuen Snapshot auf der Quelle.
Es überträgt inkrementell — nur die Differenz.
Es funktioniert lokal und remote, als Push und als Pull.
Es macht das alles mit einem einzigen Befehl.

Wer schon einmal versucht hat, eine ZFS-Replikation mit reinen Shell-Mitteln fehlerresistent aufzuziehen, weiß, dass das keine Kleinigkeit ist. Syncoid nimmt genau diesen Aufwand weg, ohne dabei die Kontrolle zu verlieren.

Die Grundlage: ZFS send und recv

Um zu verstehen, was Syncoid leistet, hilft ein Blick auf das, was es vereinfacht. ZFS bringt mit zfs send und zfs recv bereits ein mächtiges Werkzeug für die Replikation mit. Das Prinzip ist einfach: Ein Snapshot wird serialisiert und auf der anderen Seite wieder eingespielt. Inkrementell geht das auch — man sendet nur die Differenz zwischen zwei Snapshots.

In der Praxis sieht das dann so aus:

zfs send -R data/images/vm@syncoid_2026-04-07:12:00:00 | ssh remotehost "zfs recv backup/images/vm"

Das funktioniert. Bis es nicht mehr funktioniert. Weil ein Snapshot auf der Zielseite gelöscht wurde. Weil die SSH-Verbindung abbricht. Weil man vergessen hat, -I statt -i zu verwenden. Weil die Quellseite keine Snapshots hat, die die Zielseite erwartet.

Syncoid kümmert sich um all diese Fälle. Und das ist der eigentliche Mehrwert: nicht dass es zfs send aufruft — das kann jeder —, sondern dass es die Fehlerfälle abfängt, die im Alltag regelmäßig auftreten.

Loslegen: Einfacher geht es nicht

Die grundlegende Syntax ist so simpel, dass man sie sich kaum merken muss, weil sie offensichtlich ist:

syncoid data/images/vm backup/images/vm

Das repliziert den Dataset data/images/vm nach backup/images/vm — lokal, auf derselben Maschine. Beim ersten Lauf wird alles übertragen, bei jedem weiteren nur die Differenz.

Remote geht es genauso, nur mit dem üblichen SSH-Präfix:

syncoid data/images/vm root@remotehost:backup/images/vm

Das ist Push-Replikation: Die lokale Maschine sendet zum Remote. Pull geht auch:

syncoid root@remotehost:data/images/vm backup/images/vm

Hier zieht die lokale Maschine die Daten vom Remote. Der Unterschied mag marginal wirken, ist aber in der Praxis relevant: Pull bedeutet, dass die Backup-Maschine die Kontrolle hat und keinen SSH-Zugang zur Produktionsmaschine benötigt.

Rekursiv geht es mit -r:

syncoid -r rpool remotehost:tank/backup/rpool

Damit werden alle Child-Datasets unter rpool mit übertragen. Für ein vollständiges Backup ist das genau das, was man braucht.

Ohne Root: ZFS-Rechte delegieren

Einer der häufigsten Fehler bei ZFS-Backups ist, sie als root laufen zu lassen. Es funktioniert, aber es bedeutet, dass man root-SSH-Zugang zwischen Maschinen erlaubt. Das ist ein Sicherheitsrisiko, das sich vermeiden lässt.

Syncoid unterstützt den Betrieb ohne Root über --no-privilege-elevation. Dafür müssen auf beiden Seiten die entsprechenden ZFS-Berechtigungen delegiert werden:

Auf der Quellmaschine:

zfs allow -u syncuser send,hold,mount,snapshot,destroy rpool

Auf der Zielmaschine:

zfs allow -u syncuser compression,mountpoint,create,mount,receive,rollback,destroy tank/backup/rpool

Und dann:

syncoid --no-privilege-elevation -r rpool syncuser@remotehost:tank/backup/rpool

Das ist mehr Aufwand bei der Einrichtung, aber es ist der richtige Weg. Kein root-SSH, keine unnötigen Privilegien. Wenn man mit --use-hold arbeitet, kommt noch die release-Berechtigung dazu. Wer --create-bookmark nutzt, braucht bookmark auf der Quellseite.

Die Optionen, die man tatsächlich braucht

Syncoid hat eine überschaubare, aber nützliche Anzahl an Optionen. Die wichtigsten:

--compress: Kompression während der Übertragung. Unterstützt werden gzip, pigz-fast, pigz-slow, zstd-fast, zstd-slow, lz4, xz, lzo (Standard) und none. Wer über ein LAN synchronisiert, kann none wählen; über WAN ist zstd-fast eine gute Wahl.

--no-sync-snap: Standardmäßig erzeugt Syncoid bei jedem Lauf einen eigenen Snapshot. Wer das nicht möchte — etwa weil Sanoid die Snapshot-Verwaltung übernimmt oder weil man in ein Multi-Target-Setup repliziert —, der schaltet das mit --no-sync-snap ab. Verhindert die Anhäufung von Syncoid-Snapshots auf der Zielseite.

--create-bookmark: Setzt auf der Quelle ein Lesezeichen für den letzten erfolgreich replizierten Snapshot. Das ist besonders nützlich bei unregelmäßiger Replikation: Wenn der letzte gemeinsame Snapshot auf der Quelle bereits gelöscht wurde, kann das Bookmark den Zugriff auf den benötigten Punkt trotzdem ermöglichen. Funktioniert nur zusammen mit --no-sync-snap.

--use-hold: Setzt einen Hold auf den neuesten Snapshot auf Quell- und Zielseite und entfernt ihn erst nach dem nächsten erfolgreichen Lauf. Das verhindert, dass ein Snapshot gelöscht wird, bevor er repliziert wurde. Bei Multi-Target-Setups (A→B, A→C) kann man mit --identifier unterschiedliche Holds pro Ziel setzen.

--no-stream: Statt -I (alle Zwischensnapshots) wird -i (nur der neueste Snapshot) verwendet. Spart Bandbreite, wenn man die Zwischenschritte nicht braucht.

--exclude-datasets=REGEX: Schließt bestimmte Datasets von der Replikation aus. Kann mehrfach angegeben werden.

--source-bwlimit und --target-bwlimit: Bandbreitenlimitierung, falls mbuffer nicht verfügbar ist. Nützlich, wenn man die Übertragung nicht die ganze Leitung blockieren lassen möchte.

Snapshots und Pruning

Ein wichtiger Punkt: Syncoid ist agnostisch gegenüber der Snapshot-Verwaltung. Es löscht keine Snapshots auf der Zielseite, nur weil sie auf der Quelle gelöscht wurden. Das ist kein Fehler, sondern ein Feature — es schützt vor Datenverlust.

Für das Aufräumen alter Snapshots auf der Zielseite empfiehlt sich Sanoid mit einer Konfiguration wie dieser:

[backup/images/vm]
autoprune = yes
autosnap = no
frequently = 0
hourly = 36
daily = 30
monthly = 6
yearly = 0

autosnap = no, weil die Snapshots von Syncoid kommen und nicht von Sanoid erzeugt werden sollen. autoprune = yes, um alte Snapshots nach den definierten Regeln aufzuräumen. Das lässt sich mit Templates auch für viele Datasets gleichzeitig konfigurieren.

Oder, kürzer, mit einem Template:

[template_backup]
autoprune = yes
autosnap = no
hourly = 36
daily = 30
monthly = 6

[backup/images]
use_template = backup
recursive = yes

Die Kombination aus Syncoid für die Replikation und Sanoid für das Pruning ist das, was die meisten produktiven Setups verwenden. Und sie funktioniert genau deshalb gut, weil beide Werkzeuge ihre Zuständigkeit klar abgrenzen.

Praktisches Setup: Ein vollständiges Beispiel

Angenommen, man hat einen Server prod mit dem Pool zdata und einen Backup-Server backup mit dem Pool tank. Ziel: Tägliches inkrementelles Backup aller Datasets.

1. Sanoid auf prod einrichten (für die Snapshot-Erstellung):

/etc/sanoid/sanoid.conf

[zdata]
use_template = production

[template_production]
frequently = 0
hourly = 36
daily = 30
monthly = 3
yearly = 0
autosnap = yes
autoprune = yes

2. Cron-Job auf backup (Pull-Replikation):

0 2 * * * syncoid --no-sync-snap --compress=zstd-fast -r syncuser@prod:zdata tank/backup/zdata

3. Sanoid auf backup (für das Pruning):

[tank/backup/zdata]
use_template = backup

[template_backup]
autoprune = yes
autosnap = no
hourly = 36
daily = 30
monthly = 6
yearly = 0

Das ist im Grunde das komplette Setup. Drei Konfigurationsschritte, ein Cron-Job, und man hat eine robuste, inkrementelle ZFS-Replikation, die im Hintergrund läuft, ohne dass man sich darum kümmern muss.

Was man beachten sollte

Ein paar Dinge, die in der Dokumentation eher am Rande stehen, aber im Alltag relevant werden:

SSH-Konfiguration: Syncoid baut für jeden Lauf eine neue SSH-Verbindung auf. Bei häufiger Replikation lohnt sich ein Connection Multiplexing in der ~/.ssh/config:

Host backupserver
  HostName 192.168.1.50
  User syncuser
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 600

Das spart den Verbindungsaufbau bei jedem Lauf.

mbuffer: Wenn auf beiden Seiten mbuffer verfügbar ist, nutzt Syncoid es automatisch. Das kann die Übertragungsrate deutlich verbessern, weil es die Pipeline puffert und verhindert, dass zfs send auf zfs recv warten muss.

Erstlauf dauert: Der erste Syncoid-Lauf überträgt den kompletten Dataset. Bei mehreren Terabyte bedeutet das: Zeit einplanen. Alle folgenden Läufe sind inkrementell und entsprechend schneller.

Kein Konfigurationsfile: Im Gegensatz zu Sanoid hat Syncoid keine Konfigurationsdatei. Alles wird über Kommandozeilen-Flags gesteuert. Das ist konsistent, bedeutet aber auch, dass man bei komplexeren Setups die Aufrufe entsprechend dokumentieren sollte.

Warum Syncoid und nicht rsync?

Die Frage ist naheliegend. rsync ist etabliert, gut dokumentiert und funktioniert auf jedem System. Aber rsync kennt ZFS nicht. Es kann nicht inkrementell auf Snapshot-Ebene arbeiten, es kann keine Block-Differenzierung nutzen, und es kann nicht garantieren, dass der Zielzustand konsistent ist.

ZFS-Snapshots sind atomar. Ein Snapshot repräsentiert den exakten Zustand eines Datasets zu einem bestimmten Zeitpunkt. Wenn man den repliziert, erhält man auf der Zielseite exakt diesen Zustand — nicht einen Zustand, bei dem einige Dateien schon aus dem Snapshot stammen und andere gerade im Flux sind.

Das ist kein akademischer Unterschied. Wer schon einmal ein Datenbank-Backup mit rsync gemacht hat und feststellen musste, dass die Dateien während der Übertragung verändert wurden, weiß, wovon die Rede ist.

Fazit

Syncoid ist eines dieser Werkzeuge, die man sich früher wünscht. Es nimmt einen wiederkehrenden, fehleranfälligen Prozess — ZFS-Replikation per Hand — und macht ihn zu einem einzelnen Befehl, der funktioniert. Nicht weil er Magie einsetzt, sondern weil er die Randfälle abdeckt, die man selbst immer vergisst: fehlende Snapshots, abgebrochene Verbindungen, falsche Flags.

Wer ZFS einsetzt und nicht bereits ein etabliertes Replikations-Setup hat, sollte Syncoid ausprobieren. Die Einstiegshürde ist minimal, der Nutzen ist sofort spürbar, und falls man doch mehr Kontrolle braucht: Die Optionen sind da, man muss sie nur nutzen.

Und wer Sanoid für die Snapshot-Verwaltung ohnehin schon im Einsatz hat — der hat Syncoid bereits installiert. Es ist Teil desselben Pakets. Man muss es nur nutzen.

Quellen

Sanoid/Syncoid auf GitHub: https://github.com/jimsalterjrs/sanoid
Syncoid-Wiki: https://github.com/jimsalterjrs/sanoid/wiki/Syncoid
Syncoid ohne Root: https://riazarbi.github.io/dev/2022-09-16-syncid-without-root/
ZFS-Replikation in 5 Minuten: https://unicolet.blogspot.com/2016/05/from-0-to-zfs-replication-in-5m-with.html

FreeBSD Änderungen der letzten Woche – 4. April 2026

4. April 20264. April 2026 Thorsten Geppert Schreib einen Kommentar

Übersicht

Diese Woche gab es wichtige Security Updates und interessante Entwicklungen im FreeBSD-Ökosystem. Hier sind die Highlights der letzten 7 Tage.

Wichtige Security Advisories

FreeBSD-SA-26:09.pf – PF Firewall Regelproblem

Datum: 26. März 2026
Betroffen: FreeBSD 14.x, 15.0
Schweregrad: Hoch

Problem: Die pf Firewall ignoriert bestimmte Regeln stillschweigend, was zu unbeabsichtigten Netzwerkzugriffen führen kann.

Lösung:

Patches für stable und release branches verfügbar
Upgrade via pkg upgrade oder freebsd-update
Workaround: Regeln mit Tables oder Labels umschreiben

CVE: CVE-2026-4652

FreeBSD-SA-26:07.nvmf – NVMe over Fabrics Problem

Datum: 25. März 2026
Betroffen: FreeBSD 15.0
Schweregrad: Mittel

Problem: Sicherheitslücke im NVMe over Fabrics Subsystem.

Behoben:

1. März 2026 01:29 UTC (stable/15)
1. März 2026 01:11 UTC (releng/15.0)

FreeBSD 14.4-RELEASE – Aktueller Status

FreeBSD 14.4 wurde am 10. März 2026 veröffentlicht und ist die fünfte Version des stable/14 Branch. Wichtige Neuerungen:

Hauptfeatures

OpenSSH 10.0p2 mit hybridem Post-Quantum-Algorithmus mlkem768x25519-sha256
OpenZFS 2.2.9 mit verbesserter Performance und Stabilität
Bessere cloud-init und nuageinit Kompatibilität
Neues p9fs(4) für Dateisystem-Sharing zwischen Host und bhyve-Gästen
Verbesserte Manpages und Dokumentationswerkzeuge

Support Zeitraum

FreeBSD 14.4 wird bis zum 31. Dezember 2026 unterstützt.

Ports und Packages Updates

pkgsrc-2026Q1 Branch

Der neue Quarterly Branch für pkgsrc wurde am 27. März angekündigt:

Aktualisierte Software-Pakete
Sicherheitsupdates
Verbesserte Abhängigkeitsauflösung

Wichtige Package-Updates

OpenSSL 3.5: Mehrere Security-Fixes
PostgreSQL 17: Performance-Verbesserungen
Python 3.12: Neue Features und Optimierungen
pkg 2.6.2_1: Verbesserte Package-Verwaltung

Entwicklung und Community

Google Summer of Code 2026

FreeBSD und NetBSD wurden für Google Summer of Code 2026 ausgewählt. Studenten können an verschiedenen Projekten arbeiten:

Kernel-Entwicklung
Tooling-Verbesserungen
Dokumentation

Release Schedule Änderungen

FreeBSD hat den Release-Zyklus angepasst:

Quarterly Releases: Alle 3 Monate
Biennial Releases: Alle 2 Jahre (Langzeit-Support)
Ziel: Bessere Sicherheit und einfachere Wartung

Systemadministration

Wichtige Befehle diese Woche

# PF Fix anwenden
freebsd-update fetch
freebsd-update install

# Oder via pkg
pkg upgrade

# ZFS Performance Monitoring
zpool iostat -v 1
zfs get all tank

Monitoring Empfehlungen

PF Rules überprüfen: pfctl -s rules
NVMe Status: nvmecontrol devlist
Security Updates: Regelmäßig freebsd-update ausführen

Sicherheitshinweise

BSI Warnungen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat Updates zu folgenden FreeBSD-Sicherheitslücken veröffentlicht:

Lokale Schwachstellen in Jail-Implementierung
PF Firewall Regelumgehung
NVMe over Fabrics Probleme

Internationale Warnungen

Canadian Centre for Cyber Security: AV26-179 Advisory
DFN-CERT-2026-0689: Zwei lokale Schwachstellen

Ausblick nächste Woche

Weitere Updates für FreeBSD 15.0
Mögliche neue Security Advisories
Vorbereitungen für Google Summer of Code
Weitere Anpassungen am Release Schedule

Ressourcen

FreeBSD Security Advisories: https://www.freebsd.org/security/advisories/
FreeBSD Mailing Lists: https://lists.freebsd.org/
BSDSec Security Announcements: https://bsdsec.net/
FreeBSD Release Notes: https://www.freebsd.org/releases/14.4R/relnotes/

Ausführlicher Vergleich der BSD-Familie: FreeBSD, OpenBSD, NetBSD und DragonFlyBSD

31. März 202631. März 2026 Thorsten Geppert Schreib einen Kommentar

Inhaltsverzeichnis

Einleitung und Geschichte
Philosophie, Entwicklungsmodell und Lizenzierung
Typische Einsatzszenarien – Wo welches BSD am besten passt
Kernarchitektur im Detail

4.1 Dateisysteme und Speicherverwaltung
4.2 Netzwerk‑Stack und Sicherheitsfeatures
4.3 Virtualisierung, Container und Isolationstechniken

Derivate, Spezialdistributionen und Ökosystem
Pro‑ und Contra‑Tabellen – Schnellvergleich
Entscheidungshilfe – Welches BSD ist das Richtige für mein Projekt?
Zukünftige Entwicklungen und Roadmaps
Quellen, weiterführende Literatur und Community‑Links

Einleitung und Geschichte

Die BSD‑Familie hat ihre Wurzeln in der Berkeley Software Distribution (BSD), die 1977 von der University of California, Berkeley, als Weiterentwicklung des frühen UNIX‑Systems veröffentlicht wurde. Die ersten öffentlichen BSD‑Versionen (1.0 – 4.3) legten das Fundament für den heute bekannten TCP/IP‑Protokoll‑Stack, der damals noch ein Forschungsexperiment war, heute aber das Rückgrat des Internets bildet.

Im Laufe der 1990er‑Jahre spaltete sich das Projekt in mehrere unabhängige Richtungen:

FreeBSD (gegründet 1993) fokussierte sich schnell auf Performance, Stabilität und eine umfangreiche Ports‑Sammlung für Drittsoftware.
OpenBSD (ab 1995) verfolgte das Ziel, ein so sicher wie möglich zu sein. Der Name selbst stammt von der Kombination aus „Open“ und „BSD“ und betont Transparenz.
NetBSD (1993) wählte den Pfad der Portabilität – das berühmte Motto „runs on anything“ stammt von NetBSD und spiegelt die Unterstützung von über 50 Prozessorarchitekturen wider.
DragonFlyBSD (2003) entstand aus einem Fork von FreeBSD 4.8, weil einige Entwickler mit der Entwicklungsgeschwindigkeit und den SMP‑Architekturen unzufrieden waren. Das Ergebnis: ein System, das stark auf Multi‑Core‑Skalierung und ein eigenes Dateisystem HAMMER2 setzt.

Diese unterschiedlichen Wurzeln bestimmen bis heute die Design‑Entscheidungen, das Community‑Verhalten und die Einsatzbereiche der einzelnen Betriebssysteme.

Philosophie, Entwicklungsmodell und Lizenzierung

Projekt	Zielsetzung	Entwicklungsmodell	Lizenzierung
FreeBSD	Hoch‑performante Server‑ und Desktop‑Plattform	Zentralisiertes Kernteam, Commit‑Access über Core‑Team; offene Ports‑Tree-Pflege durch freiwillige Maintainer	BSD‑Lizenz (2‑Clause) + CDDL für ZFS (Kompatibilitäts‑Ausnahme)
OpenBSD	Sicherheit über alles, Code‑Qualität, Audits	Kleine, sehr konservative Entwicklergemeinschaft; Ein‑Person‑Commit‑Policy; jede Änderung wird auditiert	BSD‑Lizenz (ähnlich der 2‑Clause); kein CDDL, alles rein Open‑Source
NetBSD	Portabilität, Sauberkeit des Codes, Unterstützung exotischer HW	Dezentralisiert, Git‑basiertes Repository; pkgsrc (Quellpaket‑System) wird separat gepflegt	BSD‑Lizenz (2‑Clause) – keine zusätzlichen Einschränkungen
DragonFlyBSD	Skalierbare SMP‑Leistung, moderne Dateisysteme	Kleines, fokussiertes Kernteam, schnelle Release‑Zyklen (alle 6‑8 Wochen)	BSD‑Lizenz (2‑Clause)

Die Lizenzierung ist ein wichtiger Faktor für Unternehmen. FreeBSD enthält den CDDL‑Teil für ZFS, was in manchen Unternehmens‑Compliance‑Szenarien zu Diskussionen führt. OpenBSD, NetBSD und DragonFlyBSD verwenden ausschließlich die klassische BSD‑Lizenz, was ihre Nutzung in proprietären Projekten vereinfacht.

Typische Einsatzszenarien – Wo welches BSD am besten passt

Web‑ und Datenbank‑Server

FreeBSD ist dank ZFS‑Integration, Jails und einer ausgereiften TCP‑Stack‑Optimierung (z. B. TCP‑Fast‑Open, RACK‑Algorithmus) die erste Wahl für große Web‑Farmen. Unternehmen wie Netflix, Yahoo! und GitHub betreiben Teile ihrer Infrastruktur auf FreeBSD. OpenBSD wird eher für sicherheitskritische Front‑Ends eingesetzt, wo die Angriffsfläche minimal sein soll – beispielsweise als Reverse‑Proxy mit pf und httpd.

NetBSD wird selten in klassischen Web‑Umgebungen eingesetzt, findet aber in Embedded‑Gateways (Router, IoT‑Edge‑Devices) Verwendung, weil es auf ARM‑ und MIPS‑Boards läuft. DragonFlyBSD ist besonders attraktiv für Rechenzentren, die hohe Kernzahlen nutzen – das HAMMER2‑Dateisystem bietet native Deduplizierung, was Speicher‑Kosten senkt.

Firewall‑ und Router‑Appliance

pf wurde ursprünglich von OpenBSD entwickelt und später nach FreeBSD portiert. Heute ist pfSense (FreeBSD) und OPNsense (FreeBSD) die führenden Open‑Source‑Firewalls – sie bauen auf pf auf, bieten eine Web‑UI, Plugins für VPN, Captive‑Portal und IDS/IPS. OpenBSD selbst kann dank pf und spamd ebenfalls als reine Firewall dienen, wird aber seltener als eigenständige Appliance eingesetzt, weil es kein integriertes Web‑Frontend hat.

Embedded / IoT

NetBSD ist das klar dominante BSD‑Projekt für Embedded‑Systeme: Es läuft auf Raspberry Pi, BeagleBoard, MIPS‑Router, PowerPC‑Systemen und sogar auf Spielkonsolen. Die Clean‑room‑Entwicklung sorgt für stabile, deterministische Builds, die in der Industrie geschätzt werden. FreeBSD hat ebenfalls ARM‑Support, aber das Footprint ist größer, weshalb es primär in NAS‑Geräten (z. B. TrueNAS) verwendet wird.

Desktop / Workstation

FreeBSD selbst ist nicht primär für Desktop‑Nutzer gedacht, aber Projekte wie GhostBSD und MidnightBSD bieten fertig vorkonfigurierte Desktop‑Umgebungen (GNOME/KDE) mit ein‑Klick‑Installern. NetBSDs NomadBSD ist ein Live‑USB‑System, das persistent bleiben kann. DragonFlyBSD nutzt ebenfalls einen Desktop‑Installer, ist aber stärker auf Server‑Anwendungen ausgerichtet.

Storage‑Appliances und NAS

ZFS‑Integration macht FreeBSD zum bevorzugten Kernel für TrueNAS CORE (ehemals FreeNAS). Dort werden Snapshots, Replikation und RAID‑Z professionell verwaltet. DragonFlyBSD bietet HAMMER2, das ebenfalls Copy‑on‑Write, Snapshots und Deduplizierung unterstützt – ideal für Backup‑Server, die große Datenmengen deduplizieren wollen.

Kernarchitektur im Detail

Dateisysteme und Speicherverwaltung

FreeBSD – ZFS

ZFS ist ein Copy‑on‑Write‑Dateisystem, das Datenintegrität durch Checksummen gewährleistet. Es unterstützt Kompression, Deduplizierung, scrubbing und end‑to‑end‑Encryption. In FreeBSD ist ZFS seit Version 9.0 integral und kann als Root‑Dateisystem verwendet werden. Das Zpool‑Modell erlaubt das Kombinieren unterschiedlicher physischer Laufwerke zu einem logischen Speicher‑Pool.
Lizenz: ZFS stammt aus dem CDDL‑Open‑Source‑Projekt von Sun/Oracle, das mit der BSD‑Lizenz nicht kompatibel ist – deshalb existiert eine separate Lizenz‑Ausnahme in FreeBSD.

OpenBSD – FFS + Soft‑crypto

Das Fast File System (FFS), auch als UFS bekannt, ist das traditionelle BSD‑Dateisystem. OpenBSD hat keine native ZFS‑Unterstützung, jedoch gibt es experimentelle Ports. Für Verschlüsselung nutzt OpenBSD soft‑crypto, ein Kernel‑Framework, das Block‑Device‑Verschlüsselung auf Ebene des Dateisystems ermöglicht (z. B. bioctl -c C für GELI‑Verschlüsselung).

NetBSD – WAPBL und FFS

NetBSD verwendet ebenfalls FFS. Das WAPBL (Write‑Ahead‑Physical‑Logging) ist ein leichtgewichtiges Journal, das nur Metadaten‑Updates protokolliert, wodurch ein gutes Gleichgewicht zwischen Performance und Datenintegrität entsteht.

DragonFlyBSD – HAMMER2

HAMMER2 ist ein eigens entwickeltes Dateisystem, das Copy‑on‑Write, Snapshots, Deduplizierung und Cluster‑Level‑Mirroring (via hammer2 cluster) unterstützt. Es ist hoch skalierbar und besonders gut für Systeme mit vielen CPU‑Kernen und großen Datenmengen geeignet. Im Vergleich zu ZFS fehlt jedoch die breite Dritt‑Tool‑Unterstützung (z. B. zpool‑Utility).

Netzwerk‑Stack und Sicherheitsfeatures

FreeBSD: Der Netzwerk‑Stack ist für hohe Durchsatzraten optimiert (TCP‑Fast‑Open, RACK‑Congestion‑Control). ipfw ist das traditionelle Firewall‑Framework, aber seit FreeBSD 12 gibt es auch pf, das aus OpenBSD stammt. Das bpf-Subsystem (Berkeley Packet Filter) ermöglicht sehr effizientes Packet‑Capturing, das in Intrusion‑Detection‑Systemen genutzt wird.
OpenBSD: Der pf‑Firewall‑Engine ist das Herzstück. OpenBSD legt extremen Wert auf Code‑Reviews, Memory‑Safety (z. B. ProPolice, Stack‑Canaries) und Standard‑Hardenings (z. B. sysctl‑Defaults, disable_ipv6, login.conf). OpenBSD ist das Referenzsystem für PF, OpenSSH und LibreSSL, die in vielen anderen Projekten wiederverwendet werden.
NetBSD: Unterstützt sowohl ipfilter, ipfw als auch pf (via Port). Der Netzwerk‑Stack ist sehr portabel – das macht NetBSD attraktiv für kleine Router‑Boards.
DragonFlyBSD: Hat ebenfalls pf integriert, nutzt aber zusätzlich das Vimage/-Vkernel‑Framework für leichte Isolation von Netzwerk‑Namespaces. Der Netzwerk‑Stack ist nicht ganz so umfangreich wie bei FreeBSD, dafür aber sehr sauber implementiert.

Virtualisierung, Container und Isolationstechniken

System	Container‑Lösung	Hypervisor	Besonderheiten
FreeBSD	Jails – OS‑Level‑Container mit eigenen IP‑Stacks, Dateisystem‑Views und Ressourcengrenzen (via `rctl`).	bhyve – moderner Hypervisor, unterstützt VirtIO‑Devices, UEFI‑Boot und KVM‑Kompatibilität.	`runjail` ermöglicht Docker‑Kompatibilität; `vmm`-Modul für KVM‑Beschleunigung.
OpenBSD	Keines (kein `jails`‑Äquivalent)	vmm – leichtgewichtiger Hypervisor, unterstützt KVM‑Kompatibilität.	Fokus liegt auf Sicherheit, daher kein Container‑Framework eingebaut.
NetBSD	Keines (kein `jails`‑Äquivalent)	Xen, bhyve, hyper‑v (via `hv`‑Modul).	Sehr breite Unterstützung, jedoch weniger gebündelte Tools.
DragonFlyBSD	Vkernel – leichtgewichtige, eigenständige Kernel‑Instanz für Isolation (ähnlich zu `jails` aber mit weniger Overhead).	–	Vkernel ist ideal für Micro‑VMs und Container‑ähnliche Workloads.

Durch die Kombination aus Jails (FreeBSD) und pf (OpenBSD) können Administratoren sehr feinkörnige Sicherheits‑ und Isolation‑Modelle bauen, die sowohl Performance als auch Härtung liefern.

Derivate, Spezialdistributionen und Ökosystem

Derivat	Basis‑BSD	Zielgruppe	Besondere Merkmale
GhostBSD	FreeBSD	Desktop‑Nutzer (GNOME/KDE)	Ein‑Klick‑Installer, automatische ZFS‑Root‑Einrichtung, verschlüsselte Benutzer‑Home.
MidnightBSD	FreeBSD	Desktop & Server‑Einsteiger	`midnightbsd-install`, grafischer Installer, eigene Paketverwaltung (`pkgsrc`‑basiert).
TrueNAS CORE	FreeBSD	NAS‑Appliance	Vollwertige ZFS‑Verwaltung, Web‑UI, VM‑Support, Replikation, Lizenz: CDDL (ZFS) + BSD.
pfSense	FreeBSD	Firewall / Router	Umfangreiche Plugins (OpenVPN, IPsec, Captive‑Portal), Web‑UI, kommerzielle Support‑Optionen.
OPNsense	FreeBSD	Moderne Firewall‑Appliance	Moderne Angular‑UI, IDS/IPS (`Suricata`), Let’s Encrypt‑Integration, regelmäßige Security‑Updates.
NomadBSD	NetBSD	Live‑USB + Persistent Storage	Einfaches Live‑System, persistente Änderungen, kleine Image‑Größe.
OpenBSD‑based Tools	OpenBSD	Sicherheitstools	OpenSSH, OpenBGPD, OpenNTPD, LibreSSL, häufig in anderen Distributionen eingebettet.
DragonFlyBSD‑Bob	DragonFlyBSD	Server‑Skalierung	Minimalistisches System, fokussiert auf HAMMER2‑Performance, geringer Overhead.

Durch das breite Derivat‑Ökosystem kann ein Unternehmen das für den jeweiligen Anwendungsfall passende Betriebssystem wählen, ohne tief in die Grund‑BSD‑Distribution einsteigen zu müssen.

Pro‑ und Contra‑Tabellen – Schnellvergleich

FreeBSD

Pro	Contra
Riesige Ports‑Datenbank (≈30 k Pakete)	Größerer Footprint – weniger geeignet für ressourcenarme Embedded‑Geräte
Native ZFS‑Integration (Snapshots, Dedupl., Verschlüsselung)	Lizenz‑Komplexität (BSD + CDDL) kann in Unternehmen zu Compliance‑Fragen führen
Jails – leichte OS‑Container + Ressourcen‑Limits	Jails bieten nicht die gleiche Flexibilität wie Docker‑Container (z. B. keine Overlay‑FS)
Sehr gute Netzwerk‑Performance, `pf` und `ipfw` verfügbar	Teilweise veraltete Netzwerk‑Features im Vergleich zu Linux‑eigenen Technologien

OpenBSD

Pro	Contra
Höchste Sicherheit (Code‑Audits, `securebydefault`, minimaler Attack‑Surface)	Eingeschränkte Treiberunterstützung, besonders bei neuer Hardware
`pf`‑Firewall‑Engine, die als Referenz gilt	Kein nativer ZFS‑Support (experimentell)
Kleine, kohärente Code‑Basis – einfach zu auditieren	Kleine Ports‑Sammlung, selteneres Software‑Portfolio
Integrierte Sicherheits‑Tools (OpenSSH, LibreSSL, OpenBGPD)	Fokus auf Sicherheit kann zu Lasten von Performance‑Optimierungen führen

NetBSD

Pro	Contra
Laufzeit auf über 50 Architekturen – ideal für Embedded & Forschungsprojekte	Kleinere Community, weniger kommerzielle Unterstützung
WAPBL‑Journal für geringes Overhead‑Logging	Kein nativer ZFS (nur via Ports)
Saubere, modulare Kernel‑Architektur (leicht zu patchen)	Fehlende vorgefertigte Server‑Features (z. B. Jails, `pf` als Standard)
Starke `pkgsrc`‑Paketverwaltung – plattformübergreifend	Dokumentation teils lückenhaft, besonders für Anfänger

DragonFlyBSD

Pro	Contra
HAMMER2 – modernes Copy‑on‑Write‑Dateisystem mit Dedupl. und Snapshots
Vkernel – leichtgewichtige Isolation, ideal für Micro‑VMs
Fokus auf SMP‑Skalierung – gut für Server mit vielen Kernen
Schnelle Release‑Zyklen, aktive Entwicklung
Kleinere Community, weniger kommerzielle Unterstützung
HAMMER2 ist weniger verbreitet als ZFS – geringere Tool‑Unterstützung

Entscheidungshilfe – Welches BSD ist das Richtige für mein Projekt?

Anforderung	Empfohlenes BSD	Begründung
Maximale Sicherheit (Firewall, Kryptographie, Audits)	OpenBSD	`pf`‑Engine, `LibreSSL`, `OpenSSH`‑Audits, `securebydefault`‑Einstellungen
Enterprise‑Storage (ZFS, Snapshots, Replikation)	FreeBSD (bzw. TrueNAS CORE)	Native ZFS‑Integration, ausgereifte Verwaltungstools, breite Community
Breite Hardware‑Unterstützung (IoT, ARM, MIPS, SPARC)	NetBSD	Unterstützt über 50 Architekturen, Clean‑room‑Entwicklung, geringes Footprint
Skalierbare SMP‑Server (viele Kerne, Dedupl.)	DragonFlyBSD	HAMMER2‑Dedupl., Vkernel‑Isolation, exzellente SMP‑Performance
Desktop‑Erlebnis (Desktop‑Environment, Plug‑and‑Play)	GhostBSD (FreeBSD) oder MidnightBSD	Fertige Installer, vorinstallierte GNOME/KDE, einfacher Paket‑Manager
Firewall‑Appliance	pfSense / OPNsense (beide FreeBSD‑basiert)	Web‑UI, umfangreiche Plugin‑Bibliothek, kommerzieller Support
NAS / Speicher‑Appliance	TrueNAS CORE (FreeBSD)	ZFS‑Management, Web‑Interface, Replikation, VM‑Support
Entwicklung / Forschung	NetBSD	Portabilität, `pkgsrc` für plattformübergreifende Pakete

Berücksichtigen Sie zusätzlich Community‑Aktivität, Verfügbarkeit von Paketen (Ports vs. pkg), Lizenz‑Konformität und Unterstützungsoptionen (Mailing‑Liste, Issue‑Tracker, kommerzielle Anbieter).

Zukünftige Entwicklungen und Roadmaps

FreeBSD 15.x – Weiterentwicklung des ZFS‑Stacks (z. B. ZFS 2.2 mit Verbesserungen bei Scrubbing und Compression), Unterstützung von GPU‑Pass‑Through für bhyve, engere Integration in Kubernetes via csi‑freebsd.
OpenBSD 7.9 – Verbesserungen am pf‑Engine (z. B. stateful‑inspection Optimierungen), Einführung von Trusted Execution Environments (TEE), erweiterte Hardware‑Root‑of‑Trust‑Mechanismen.
NetBSD 10 – Fokus auf RISC‑V‑Unterstützung (neue Toolchains, Device‑Tree‑Support), pkgsrc‑Erweiterungen für Container‑Orchestrierung (Docker‑Kompatibilität), Modernisierung der Netz‑Stack‑Bibliotheken.
DragonFlyBSD 6 – Finalisierung und Stabilisierung von HAMMER2, neue Vkernel‑Features (z. B. Namespace‑Isolation, cgroups‑ähnliche Ressourcen‑Limits), Integration von ZFS‑Ports für Hybrid‑Lösungen.
Derivate: TrueNAS SCALE (Debian‑basiert) entsteht als Konkurrenz zum FreeBSD‑basierten CORE, während pfSense 2.8 führt eBPF‑Unterstützung ein, um modernere Packet‑Processing‑Pipelines zu ermöglichen.

Quellen, weiterführende Literatur und Community‑Links

FreeBSD Project – Offizielle Dokumentation: https://www.freebsd.org/docs/
OpenBSD Project – Ziele & Sicherheit: https://www.openbsd.org/faq/faq4.html
NetBSD Project – Plattform‑Übersicht: https://www.netbsd.org/ports/
DragonFlyBSD – HAMMER2‑Dokumentation: https://www.dragonflybsd.org/docs/hammer2/
pfSense – Dokumentation & Release‑Notes: https://docs.pfsense.org/
OPNsense – Features & Roadmap: https://opnsense.org/
TrueNAS – ZFS‑Management: https://www.truenas.com/
GhostBSD – Desktop‑Projekt: https://ghostbsd.org/
MidnightBSD – Release‑Notes: https://midnightbsd.org/
NomadBSD – Live‑USB System: https://nomadbsd.org/
NetBSD – WAPBL & FFS: https://netbsd.org/docs/technical/
OpenBSD – pf‑Manpage: https://man.openbsd.org/pf.conf
FreeBSD – Jails‑Handbuch: https://docs.freebsd.org/en/books/handbook/jails/
DragonFlyBSD – Vkernel‑Übersicht: https://www.dragonflybsd.org/docs/vkernel/

Was ist neu in Qt 6.10? Ein Überblick für Entwickler

25. März 202623. März 2026 Thorsten Geppert Schreib einen Kommentar

Qt 6.10 ist ein klassisches „Framework‑Release“, das an vielen Stellen nachzieht, wo sich in den letzten Jahren Anforderungen und Best Practices geändert haben: moderneres UI‑Layouten mit Flexbox, stärkere Unterstützung für Vektoranimationen (SVG/Lottie), vereinfachte Datenanbindung zwischen C++ und QML, neue Hilfstypen für Modelle und Bindungen – und dazu ein spürbares Update bei Accessibility und Plattformintegration.

Im Folgenden ein Überblick über die wichtigsten Änderungen von Qt 6.10, auf Basis der offiziellen Release‑Informationen.

Accessibility: High Contrast und Screenreader werden ernster genommen

Qt 6.10 legt sichtbar mehr Wert auf Barrierefreiheit:

High‑Contrast‑Mode auf allen Plattformen:
Die eingebauten Styles orientieren sich stärker an den jeweiligen System‑Einstellungen für hohen Kontrast.
Ziel: Qt‑Apps sollen sich optisch nahtlos in die restliche Oberfläche einfügen und dabei besser lesbar sein.
Für dich als Entwickler bedeutet das: Ohne Codeänderung profitierst du von verbessertem Kontrast, wenn Nutzer das systemweit aktivieren.
Bessere Integration mit Assistive Technologies:
Qt Widgets und Qt Quick Controls wurden überarbeitet, damit Screenreader und andere Hilfsmittel sauberer angesprochen werden.
Besonders für WebAssembly gab es Verbesserungen in der Accessibility‑Implementierung.
Viele Änderungen fließen auch in LTS‑Branches zurück (Patch‑Releases), sofern du dort aktuell bleibst.

Unterm Strich: Qt 6.10 hilft dir bei der Einhaltung von Accessibility‑Vorgaben, ohne dass du an jeder Ecke Speziallogik schreiben musst.

Qt Quick: FlexboxLayout und moderne UI‑Bausteine

Qt Quick bleibt die Speerspitze für neue UI‑Konzepte. Mit Qt 6.10 kommen unter anderem:

FlexboxLayout (Tech Preview)

Neues Layout‑Element FlexboxLayout für Qt Quick, das sich an CSS Flexbox anlehnt.
Vorteile:
Besseres Verhalten bei unterschiedlich großen Screens und Aspect Ratios.
Weniger Custom‑Layoutcode für „responsive“ UIs.
Vertraut für alle, die bereits mit Web/CSS arbeiten.
Integration:
Bindet sich in das bestehende Layout‑System von Qt Quick ein (attached properties etc.).
Ist als Technologievorschau gekennzeichnet – API kann sich bis zum nächsten LTS noch ändern.

Animierte Vektorgrafiken (SVG & Lottie)

Qt 6.10 baut konsequent auf den SVG/Vektor‑Verbesserungen der vorherigen Versionen auf:

VectorImage (aus 6.8 bekannt) wird erweitert:
Unterstützung für animierte Vektorgrafiken in
- SVG‑Format und
- Lottie‑Format.
Qt Lottie‑Modul:
Deutlich verbesserte Unterstützung moderner Lottie‑Dateien.
Lottie‑Assets können jetzt als skalierbare, hardwarebeschleunigte Vektorgrafiken direkt im Qt‑Quick‑Scenegraph gerendert werden.

Für UI‑Designer bedeutet das: Aufwendige, aber leichtgewichtige Animationswelten lassen sich direkt aus Design‑Tools (Figma/After Effects → Lottie) in Qt übernehmen.

Neuer Quick Control: SearchField

Spezialisierter Eingabebaustein für Suchfelder.
Bringt:
nativen Look & Feel auf allen Plattformen (wie andere Qt Quick Controls),
integrierte Vorschlagsliste mit Modellanbindung.
Integration:
suggestionModel kann über die üblichen Mechanismen (QAbstractItemModel, Kontextobjekte, QML‑Modelle) befüllt werden.
Besonders interessant in Kombination mit den neuen Modell‑/Bindungswerkzeugen (siehe unten).

Einfachere Verbindung zwischen C++‑Daten und QML‑UIs

Ein klassischer Schmerzpunkt in Qt‑Projekten war die Verbindung zwischen C++‑Backend und QML‑UI. Qt 6.10 nimmt sich genau dieser Nähte an.

QRangeModel: C++‑Container direkt als Modell

QRangeModel ist eine schlanke QAbstractItemModel‑Implementierung, die C++‑Ranges (z.B. std::vector, std::array, beliebige iterierbare Container) direkt als Modell zur Verfügung stellt.
Eigenschaften:
Kann einfache Typen (int, QString, …) wie auch komplexe Typen (GADGETs, std::tuple) abbilden.
Modellrollen werden automatisch erzeugt.
Funktioniert gleichermaßen in Qt Widgets (Views) und in QML/Qt Quick.
Beispiel‑Anwendung:
std::vector<int> als Liste in einer QML‑ListView,
std::vector<MyGadget> als typ‑sicheres Modell in Delegates mit required property.

Damit entfällt für viele Anwendungsfälle das Schreiben eigener QAbstractItemModel‑Subklassen.

delegateModelAccess: Zurückschreiben in das Modell vereinfachen

Bisher war das Schreiben aus einem Delegate zurück in das Modell oft umständlich:

Entweder über model‑Objekte im Delegate
oder über Kontextproperties und eigene Signal‑Handler.

Mit Qt 6.10 kann eine View über delegateModelAccess: DelegateModel.ReadWrite explizit erlauben, dass required‑Properties im Delegate direkt zurück ins Modell schreiben. Das reduziert Boilerplate deutlich, insbesondere in größeren QML‑UIs.

Synchronizer: Zwei‑ und Mehrwege‑Bindungen

Neues Element Synchronizer (Tech Preview, Modul Qt.labs.synchronizer).
Zweck:
Mehrere Properties so synchron halten, dass sie (so weit möglich) denselben Wert haben, ohne klassische Bindungen zu „brechen“.
Funktioniert für Kombinationen von C++‑ und QML‑Eigenschaften.
Praxisnutzen:
Typische „Slider ↔ Modell‑Wert“‑Szenarien lassen sich deklarativ und ohne zusätzliche Signal‑Handler abbilden.

TreeModel für QML

Neues QML‑TreeModel, mit dem sich Baumdaten direkt in QML deklarieren lassen.
Zielgruppe:
Prototyping,
kleinere Datenmengen,
Szenarien, in denen ein kompletter C++‑Baummodell‑Layer Overkill wäre.

Zusammen genommen macht Qt 6.10 die Kante zwischen C++‑Backend und QML‑Frontend deutlich angenehmer.

Qt Graphs: FilledSurface und mehr

Qt Graphs wird auch in 6.10 weiter ausgebaut:

Neue Diagrammtypen und Anpassungen:
u.a. ein neuer „FilledSurface“‑Graph zur besseren Darstellung gefüllter Flächen.
Bessere Integration in Qt Quick und die neuen Layout‑/Vektorfeatures.

Wenn du bereits mit Qt Graphs arbeitest, lohnt sich ein Blick in die konkreten Release Notes für dieses Modul.

Sonstige Verbesserungen und Plattform‑Updates

Wie bei jedem Qt‑Release gibt es eine Reihe weiterer Verbesserungen:

Plattformintegration:
Qt 6.10 richtet sich nach den jeweils aktuellen Versionen der großen Desktop‑, Mobile‑ und Embedded‑Plattformen (siehe Release Note und Wiki‑Seite).
Bugfixes und Feinschliff:
Dutzende Fehlerkorrekturen in den Untermodulen (Widgets, Quick, Network, etc.).
Viele Details lassen sich in den detaillierten Release Notes (6.10.0–6.10.2) nachlesen.

Fazit

Qt 6.10 ist kein „großer Sprung“ im Sinne völlig neuer Konzepte, sondern ein Release, das viele typischen Alltagsbaustellen adressiert:

Accessibility wird ernst genommen (High Contrast, Screenreader‑Integration).
Qt Quick bekommt mit FlexboxLayout, animierten Vektorgrafiken und SearchField Werkzeuge, die aktuelle UI‑Designs besser abbilden.
Die Verbindung zwischen C++‑Daten und QML‑UIs wird durch QRangeModel, delegateModelAccess, Synchronizer und TreeModel deutlich entschärft.

Wer bereits auf Qt 6.x unterwegs ist, sollte Qt 6.10 vor allem dann in Betracht ziehen, wenn:

Accessibility und regulatorische Vorgaben eine Rolle spielen,
moderne, animierte UIs (Vektor/Lottie) benötigt werden,
oder die Brücke zwischen C++‑Backend und QML‑Frontend bislang viel Handarbeit erfordert.

Quellen

Qt Blog: Qt 6.10 Released! – https://www.qt.io/blog/qt-6.10-released
Qt Wiki: Qt 6.10 Release – https://wiki.qt.io/Qt_6.10_Release
Qt Doku: New Features in Qt 6.10 – https://doc.qt.io/qt-6.10/whatsnew610.html