TrueNAS 27 Upgrade 2026: RC.1, WebSocket API und HA prüfen

TrueNAS 27 Upgrade: Das nächste große TrueNAS-Release ist für Speicheradministratoren besonders relevant: Die bisher als TrueNAS 26 getestete Version heißt seit Oktober 2026 TrueNAS 27. Am 6. Oktober erschien RC.1, während der Hersteller die stabile Version 27.0 für Anfang Dezember 2026 plant. Neben neuen Speicher- und Webfunktionen gibt es eine kritische technische Änderung: Die bisherige REST API entfällt, und Integrationen müssen auf die versionierte WebSocket-API umgestellt werden. Ein TrueNAS 27 Upgrade ist deshalb mehr als ein gewöhnlicher Neustart mit neuem Versionsnamen. Dieser Praxisleitfaden zeigt, was sich ändert, wie produktive ZFS-Systeme und Hochverfügbarkeitsumgebungen vorbereitet werden und welche Tests vor der Freigabe erforderlich sind.

GORTNET Fachredaktion · Redaktionsstand: 29. Oktober 2026 · Technischer Praxisleitfaden

Das Wichtigste: TrueNAS 27-RC.1 ist für Testumgebungen gedacht. Die entfernte REST API, HA-Abhängigkeiten und die Wiederherstellbarkeit müssen vor dem Produktiv-Upgrade geprüft werden.

TrueNAS 27 Upgrade: Versionsstand am 29. Oktober 2026

TrueNAS hat die Release-Reihe umbenannt, um die Hauptversion am geplanten Einsatzjahr auszurichten. Die früheren 26-BETA-Releases bleiben unter ihren bisherigen Bezeichnungen dokumentiert; die Entwicklung wird mit TrueNAS 27-RC.1 fortgesetzt. Nach den offiziellen Release-Informationen ist RC.1 eine frühe Version für Testumgebungen. Der Hersteller rät ausdrücklich davon ab, Early-Release-Software für kritische Aufgaben einzusetzen. Ein Produktiv-Upgrade sollte nicht allein wegen neuer Funktionen vorgenommen werden.

Die neue Versionsnummer bedeutet außerdem nicht, dass alle Installationen sofort dieselbe Update-Empfehlung erhalten. TrueNAS veröffentlicht getrennte Softwareprofile für Early Adopter, General und Mission Critical. Ein Administrator sollte zuerst den aktuellen Stable-Status und den für die jeweilige Plattform empfohlenen Upgrade-Pfad prüfen. Für Unternehmen mit wichtigen SQL-, File- oder Application-Workloads sind geprüfte Wiederherstellbarkeit und Supportfähigkeit wichtiger als die schnellstmögliche Aktivierung einer neuen Version.

REST API wird entfernt: Warum das der wichtigste Vorbereitungspunkt ist

Die bisherige TrueNAS-REST-API war bereits mit TrueNAS 25.04 als veraltet gekennzeichnet. In TrueNAS 27 ist sie entfernt und durch eine versionierte JSON-RPC-2.0-WebSocket-API ersetzt. Skripte, Monitoring-Integrationen oder Automatisierungswerkzeuge, die HTTP-REST-Endpunkte verwenden, können nach der Aktualisierung scheitern. Für Unternehmen betrifft dies möglicherweise Backup-Orchestrierung, Benutzerverwaltung, Dataset-Aktionen, Snapshot-Jobs und eigene Administrationsportale.

Listen Sie alle API-Verbraucher auf, bevor Sie den Update-Kanal verändern. Dazu zählen geplante Tasks auf Windows-Systemen, Shell-Skripte, Ansible-Rollen, Monitoring-Server und Tools externer Dienstleister. Suchen Sie in technischen Dokumentationen nach konkreten REST-Aufrufen und hinterlegten Credentials. Ersetzen Sie jeden betroffenen Aufruf durch eine dokumentierte WebSocket-Methode. Eine einmalige erfolgreiche Anmeldung reicht nicht: Jede benötigte Lese- und Schreibfunktion muss separat unter realistischen Bedingungen geprüft werden.

WebSocket-Migration und API-Schlüssel korrekt umstellen

Die neue API unterstützt eine dauerhafte Verbindung für JSON-RPC-Anfragen. Dabei ändern sich nicht nur URL und Transport, sondern auch die Methodenstruktur und die Behandlung von Authentifizierung und Berechtigungen. TrueNAS weist darauf hin, dass bestimmte ältere API-Schlüssel migriert werden, während über die API erzeugte Schlüssel mit Methoden-Allowlist beim Upgrade widerrufen werden können. Eine vermeintlich funktionslose Integration kann deshalb sowohl an einer entfernten Methode als auch an einem ungültigen Schlüssel scheitern.

Erstellen Sie für Automatisierung nach Möglichkeit einen dedizierten Servicebenutzer mit den tatsächlich benötigten Rollen. Erzeugen Sie dazu einen passenden benutzergebundenen API-Schlüssel und verteilen Sie ihn über einen geschützten Secret-Prozess. Testen Sie WebSocket-Authentifizierung, Timeouts, Fehlerantworten und Reconnect-Verhalten. Halten Sie ein Rollback-Konzept für die Anwendung bereit und stellen Sie die neue Integration möglichst vor dem Upgrade auf den produktiven Storage bereit. Vermeiden Sie gemeinsame Root-Tokens für alltägliche Automatisierung.

S3 Object Interface: Neue Funktionen richtig einordnen

TrueNAS 27-RC.1 führt ein natives Object Interface mit S3-kompatiblem API-Zugriff als Early-Access-Funktion ein. Buckets werden als ZFS-Datasets verwaltet und können dadurch in die bestehenden ZFS-Mechanismen für Snapshots, Quotas und Replikation einbezogen werden. Für Entwickler und Administratoren ist die gemeinsame Verwaltung von Dateidiensten und Objektspeicher auf derselben Plattform interessant. Die Funktion befindet sich allerdings noch in einer Testphase und sollte nicht ohne umfangreiche Prüfung eine produktive bestehende Object-Storage-Lösung ersetzen.

Der Hersteller nennt zudem Lizenzunterschiede: Bestimmte Features wie Versioning und Object Lock setzen TrueNAS Connect Plus oder TrueNAS Enterprise voraus. Eine native S3-Schnittstelle bedeutet nicht, dass jede S3-Anwendung vollständig identisch funktioniert. Testen Sie Uploads, Multipart-Operationen, Berechtigungsmodelle, Fehlerfälle und die vom Hersteller unterstützten API-Teile mit Ihrer tatsächlichen Software. Wer Object Lock als Compliance- oder Ransomware-Kontrolle einplant, muss die benötigte Edition und die konkrete Implementierung vor der Investition verbindlich verifizieren.

SMB, NFS, iSCSI und Fibre Channel nach dem Upgrade testen

Storage-Systeme stellen produktiven Servern Daten über unterschiedliche Protokolle bereit. Selbst wenn ein Pool während eines Upgrades gesund bleibt, können Änderungen an Dienstkonfiguration, Authentifizierung oder Performance Anwendungen beeinträchtigen. Für SMB sollten Unternehmen Freigaben, ACLs, Anmeldung mit AD-Konten und das Verhalten von Windows-Clients testen. Für NFS sind Exportregeln, Eigentümerzuordnung und Mount-Verhalten relevant. iSCSI- und Fibre-Channel-Umgebungen benötigen gesonderte Prüfungen auf Multipathing, Target-Verfügbarkeit und SCSI-Fehler.

Erstellen Sie eine Matrix der wichtigsten Clients, Protokolle, Datensätze und Abhängigkeiten. Ein kleiner Testtransfer beweist noch nicht, dass ein Datenbankdienst seine virtuellen Disks nach einem Reboot korrekt erkennt. Prüfen Sie deshalb Anwendungskonsistenz, Bootfähigkeit von VMs und Wiederverbindung nach Netzwerkunterbrechungen. Führen Sie Lasttests nur in kontrollierten Zeitfenstern durch. Dokumentieren Sie die vor dem Upgrade gemessenen Werte, um nachher tatsächliche Regressionen feststellen zu können.

Hochverfügbarkeit und Split-Brain-Risiken bewusst prüfen

Bei TrueNAS-Enterprise-Hochverfügbarkeit arbeiten zwei Controller zusammen. Updates und Failover sind hier besonders sensibel, weil Protokollverbindungen und Storage-Verfügbarkeit zwischen den Controllern koordiniert werden müssen. Die RC.1-Release-Hinweise nennen Verbesserungen im HA-Bereich einschließlich einer Korrektur für ein Split-Brain-Risiko. Eine entsprechende Fehlerbehebung in einer Vorabversion ist dennoch kein Grund, ungeprüft ein produktives HA-System umzustellen.

Vor der Migration sind die tatsächliche Controller-Gesundheit, Firmwarestände, Netzwerkpfade, gemeinsam genutzte Storage-Komponenten und Hersteller-Supportbedingungen zu prüfen. Führen Sie Failover-Tests nach einem abgestimmten Verfahren aus und validieren Sie die Verbindungen der Applikationsserver. Ein abgeschalteter Standby-Controller ist nicht automatisch ein vollständiges Backup. Hochverfügbarkeit reduziert bestimmte Ausfallzeiten, schützt aber nicht vor versehentlich gelöschten oder durch einen Angriff veränderten Daten.

ZFS-Pools, RAIDZ2 und Kapazität richtig berücksichtigen

ZFS verwendet Pools, VDEVs und Datasets für Datenhaltung. Vor einem größeren Versionssprung sollten Administratoren den Zustand sämtlicher Datenträger, Fehlerraten, Scrub-Ergebnisse und den verfügbaren Platz prüfen. RAIDZ2 toleriert den Ausfall von zwei Laufwerken innerhalb des betreffenden VDEV, ersetzt aber keine unabhängige Datensicherung. Wer einen Pool gleichzeitig erweitert und die Systemsoftware aktualisiert, erhöht den technischen Änderungsumfang unnötig.

Planen Sie Storage-Erweiterungen daher getrennt von Major-Upgrades. Dokumentieren Sie die gewünschte nutzbare Kapazität unter Berücksichtigung von Parität, Metadaten, Snapshots und freien Reserven. Prüfen Sie Kompatibilität und verfügbare Einschübe, insbesondere bei NVMe-Systemen und HA-Hardware. Aktivieren Sie neue ZFS-Feature-Flags nicht unbedacht: Bestimmte Pool-Upgrades können das Zurückkehren auf ältere Versionen beschränken. Entscheiden Sie darüber erst nach der eigenen Freigabe.

Config-Backup und Boot Environments: Zwei verschiedene Schutzebenen

TrueNAS erstellt bei Updates Boot Environments für das Betriebssystem. Sie helfen, unter bestimmten Voraussetzungen eine frühere Startumgebung zu aktivieren. Ein Boot Environment enthält jedoch nicht automatisch vollständige externe Backups aller Datenpools oder Anwendungen. Die offizielle Dokumentation empfiehlt ausdrücklich, Konfigurationsdateien außerhalb der Appliance zu sichern und die aktuelle Startumgebung vor Änderungen zu bewahren.

Exportieren Sie die TrueNAS-Konfiguration mit geeignetem Schutz für enthaltene Geheimnisse. Dokumentieren Sie außerdem IP-Adressen, Netzkonfiguration, Freigaben, Zertifikate, Dienste, Dataset-Struktur und gegebenenfalls VM-Konfigurationen. Testen Sie die Wiederherstellung in einer dafür vorgesehenen Umgebung. Ein Boot-Rollback kann Unterschiede zur inzwischen veränderten Konfiguration verursachen und ist daher kein allgemeiner Ersatz für einen getesteten Disaster-Recovery-Prozess. Halten Sie den letzten stabilen Betriebszustand nachvollziehbar fest.

Legacy-VMs und Apps beim Upgrade nicht vergessen

Die Release-Dokumentation nennt Einschränkungen für ältere virtuelle Maschinen aus der früheren Instances-Verwaltung. In betroffenen Upgrade-Pfaden werden nicht alle VM-Konfigurationen automatisch übernommen. Dies kann auch UEFI-Variablen oder TPM-Zustände betreffen. Der VM-Datenträger kann erhalten bleiben, während die virtuelle Maschine mit ihren Parametern neu eingerichtet werden muss. Für geschäftskritische virtuelle Maschinen ist das ein wesentlicher Planungspunkt.

Inventarisieren Sie die Virtualisierungskomponenten und prüfen Sie genau, von welcher TrueNAS-Version Sie migrieren. Halten Sie Bootmodus, CPU, RAM, Disk-Zuordnung, virtuelle Netzwerkkarten und verbundene Geräte fest. Anwendungen und Container haben wiederum eigene Upgrade- und Rollback-Mechanismen. Prüfen Sie benötigte Images, Volumes, Secrets und USB- beziehungsweise PCIe-Passthrough vor der Migration. Eine Storage-Aktualisierung darf nicht ohne abgestimmte Anwendungstests abgeschlossen werden.

Monitoring und Alarmierung für das Update-Fenster

Ein Major-Upgrade benötigt mehr als einen Administrator mit geöffnetem Webbrowser. Überwachen Sie Poolzustand, Datenträgerfehler, freies Volumen, Netzwerkinterfaces, Dienste, Replikation und verfügbare Backupstände. Legen Sie fest, wer im Wartungsfenster die wichtigsten Fachanwendungen testet und welche Warnungen während eines planmäßigen Failovers erwartbar sind. Unabhängige Monitoring-Werkzeuge sollten auch dann erreichbar bleiben, wenn die TrueNAS-Weboberfläche vorübergehend nicht startet.

Erstellen Sie Vorher-Nachher-Snapshots der Konfigurations- und Monitoringdaten, ohne ein ZFS-Snapshot als vollwertiges Offsite-Backup zu behandeln. Prüfen Sie nach dem Update auf unbemerkte Daueralarme, nicht mehr laufende Jobs und stagnierende Replikationsaufträge. Ein automatisch als erfolgreich markiertes Systemupdate sagt wenig darüber aus, ob die letzte Stunde an Datenbank- oder Applikationsänderungen weiterhin sicher gespeichert und wiederherstellbar ist.

Wann sollte ein Unternehmen auf TrueNAS 27 wechseln?

Im Oktober 2026 ist RC.1 nach Herstellerangaben eine Vorabversion. Für produktive und besonders geschäftskritische Speicher sollte deshalb auf eine stabile, vom Hersteller für den eigenen Einsatzfall empfohlene Version gewartet werden. Das für Anfang Dezember 2026 vorgesehene 27.0-Release ist derzeit eine Planung, keine bereits erfolgte Veröffentlichung. Auch nach Erscheinen der Stable-Version kann ein zusätzliches Wartungsrelease für empfindliche Umgebungen sinnvoll sein.

Nutzen Sie die Zwischenzeit für eine Testinstallation oder eine separate Pilotumgebung. Identifizieren Sie technische Abhängigkeiten und führen Sie insbesondere die WebSocket-Migration vorab durch. Treffen Sie die produktive Updateentscheidung anhand von Supportstand, bekannten Fehlern, Testprotokollen und der Bedeutung der Workloads. Ein neues Feature ist kein Ersatz für ein erfolgreiches Rücksicherungsverfahren.

30-Tage-Vorbereitungsplan für TrueNAS 27

Woche eins: Alle TrueNAS-Systeme, Editionen, Pools, HA-Topologien, angeschlossenen Clients und API-Integrationen inventarisieren. Woche zwei: REST-Aufrufe auf WebSocket umstellen und mit dedizierten Servicekonten testen. Woche drei: Konfigurations-Backup, Boot Environments, Restore-Szenarien und die Protokoll-Tests für SMB, NFS, iSCSI oder Fibre Channel vorbereiten. Woche vier: Pilot-Upgrade auf nicht produktiver Hardware, Vergleich der Dienste und gemeinsames Review mit den betroffenen Anwendungsteams.

Ein formaler Go/No-Go-Entscheid sollte fünf Ergebnisse berücksichtigen: Die API-Integrationen funktionieren, Storage und Dienste sind gesund, die wichtigsten Anwendungen bestehen ihre Tests, die unabhängigen Backups wurden überprüft und ein realistischer Rückfallplan ist dokumentiert. Fehlt einer dieser Nachweise, ist eine Verschiebung des Produktiv-Upgrades die verantwortliche Entscheidung.

Häufige Fragen zum TrueNAS 27 Upgrade

Ist TrueNAS 27 Ende Oktober 2026 produktionsreif?

Die offiziell verfügbare RC.1 gilt als Early Release. TrueNAS warnt vor dem Einsatz auf kritischen Systemen; ein stabiles 27.0-Release ist für Anfang Dezember geplant.

Funktionieren bisherige REST-Skripte nach dem Upgrade?

Nein. Die alte REST API ist in TrueNAS 27 entfernt; Integrationen müssen auf die unterstützte WebSocket-API migriert werden.

Ersetzt ein HA-Paar das Backup?

Nein. Hochverfügbarkeit und Backup adressieren unterschiedliche Fehler- und Verlustszenarien.

Sind Boot Environments vollständige Datensicherungen?

Nein. Sie betreffen die Boot-Umgebung; Datenpools, Apps und Konfiguration benötigen eigene Schutz- und Recovery-Verfahren.

Fazit: Erst testen, dann produktiv aktualisieren

Ein erfolgreiches TrueNAS 27 Upgrade setzt eine dokumentierte WebSocket-Migration, sichere Servicekonten, überprüfte Datensicherungen und einen echten Funktionstest voraus. Die neue S3-Funktion und Verbesserungen an HA und Speicherverwaltung sind interessant, aber für kritische Systeme entscheidet die nachgewiesene Stabilität. Nutzen Sie die RC-Phase zur Vorbereitung und treffen Sie die produktive Entscheidung erst nach einer Herstellerfreigabe und eigener Abnahme.

Weitere GORTNET-Fachbeiträge

• Proxmox Backup Strategie
• Disaster Recovery Plan testen
• Backup und Recovery bei GORTNET

Benötigen Sie eine strukturierte Bewertung von Storage, Backup oder Recovery? GORTNET kontaktieren.

Offizielle Herstellerquellen

• TrueNAS: Version Notes 27 RC.1
• TrueNAS: API Reference und Umstellung
• TrueNAS: Feature Deprecations
• TrueNAS: Boot Pool Management
• TrueNAS: Stable-Status und Empfehlungen

Hinweis: Verfügbarkeit, Lizenzen und Funktionen werden nach der geprüften Release-Dokumentation vom Oktober 2026 beschrieben. Vor produktiven Änderungen immer den aktuellen Herstellerstatus und die individuellen Supportbedingungen prüfen.