Der technische Vergleich freenas vs truenas ist heute vor allem eine Frage von Produktgeneration, Support und ZFS-Strategie. Wer ein NAS neu aufsetzt oder ein altes System ersetzt, sollte nicht nur auf den Namen schauen, sondern auf Entwicklungsstand, Migrationsweg und RAID-Layout. Genau dort entstehen in der Praxis die meisten Fehlentscheidungen.
FreeNAS ist der alte Name, TrueNAS die aktuelle Plattform
- FreeNAS ist heute ein Legacy-Begriff; für neue Projekte ist die aktuelle TrueNAS-Linie die sinnvollere Basis.
- TrueNAS CORE ist die historische FreeNAS-Nachfolge, wird laut TrueNAS aber nicht mehr aktiv weiterentwickelt.
- Die kostenlose Community Edition bleibt offen und flexibel, Enterprise ist für Systeme mit Support- und Verfügbarkeitsbedarf gedacht.
- Bei NAS und RAID entscheidet das ZFS-Layout oft stärker über Sicherheit und Tempo als der Produktname.
- Snapshots, Replikation und sauber geplante VDEVs sind wichtiger als ein möglichst großer Rohspeicher auf dem Papier.
Was sich hinter dem Namenwechsel wirklich verbirgt
Wenn ich alte und neue Installationen nebeneinander betrachte, ist die wichtigste Erkenntnis ziemlich nüchtern: FreeNAS ist nicht einfach eine gleichberechtigte Alternative zu TrueNAS, sondern der historische Vorläufer. iXsystems hat die Linien zusammengeführt, FreeNAS wurde zur TrueNAS-Familie, und die alte FreeNAS-Welt ist heute vor allem für Bestandsanlagen relevant. Die aktuelle Dokumentation führt CORE inzwischen als nicht mehr aktiv entwickelt; Legacy-Versionen bleiben nur noch als Archiv- und Upgrade-Pfad erhalten.
| Aspekt | FreeNAS als Legacy | TrueNAS heute | Praktische Folge |
|---|---|---|---|
| Status | Historische Bezeichnung | Aktuelle Produktfamilie | Neue Systeme nicht mehr auf FreeNAS planen |
| Entwicklung | Archiviert | Aktiv gepflegt | Bessere Updates, aktuelle Doku, klarere Migrationspfade |
| Editionen | Früher Community und Enterprise getrennt | Community Edition und Enterprise | Free verfügbar, Support je nach Bedarf kostenpflichtig |
| Relevanz 2026 | Nur für Altbestände | Zielsystem für neue NAS-Projekte | Für Neuinstallationen ist TrueNAS die realistische Wahl |
Die eigentliche Konsequenz ist einfach: Wer heute ein neues NAS baut, denkt nicht mehr in FreeNAS, sondern in aktueller TrueNAS-Planung. Damit ist die Namensfrage geklärt - als Nächstes zählt, was die Plattform im Alltag tatsächlich besser oder anders macht.
Welche Unterschiede im Alltag wirklich zählen
Im Kern bleibt ZFS der gemeinsame Nenner. Das ist der Punkt, an dem viele Vergleiche zu oberflächlich werden, denn die Speicherlogik ist mehr als nur ein Dateisystem: Copy-on-Write, Prüfsummen, Scrubs, Snapshots und Replikation bilden zusammen das Sicherheitsnetz. Ich trenne bei solchen Systemen immer drei Ebenen sauber voneinander: lokale Redundanz, schnelle Wiederherstellung und Kopie auf ein zweites Ziel.
- Snapshots sichern einen Zustand zu einem bestimmten Zeitpunkt und machen versehentlich gelöschte Dateien oder fehlerhafte Änderungen schnell rückgängig.
- Replikation kopiert Snapshot-Stände an ein zweites Ziel; in TrueNAS braucht das einen Snapshot-Task, damit die Replikation sauber laufen kann.
- Verschlüsselung ist auf Dataset- und Zvol-Ebene verfügbar, aber die Schlüsselverwaltung liegt bei dir. Verlorene Schlüssel bedeuten praktisch Datenverlust.
- Support trennt die Linien stärker als früher: Community Edition für viele Heim- und Lab-Szenarien, Enterprise für Systeme mit klaren Betriebsanforderungen.
- Aktualität ist 2026 ein echter Faktor: Die aktiven Wege liegen bei TrueNAS, nicht bei FreeNAS als eigenständiger Plattform.
Für Datenschutz und Datensicherung ist genau das entscheidend. Ein NAS ist erst dann wirklich gut, wenn ich nicht nur speichern, sondern auch kontrolliert zurückrollen, replizieren und bei Bedarf verschlüsseln kann. Und weil diese Funktionen eng mit der Pool- und Dataset-Struktur zusammenhängen, lohnt sich der Blick auf RAID und VDEVs als Nächstes besonders.
Welches RAID-Layout zu welchem NAS passt
Bei ZFS ist der Begriff RAID nur die halbe Wahrheit. Entscheidend ist das VDEV-Layout, also die Art, wie einzelne Laufwerke zu einer logischen Einheit zusammengesetzt werden. Ein Pool ist später nur so belastbar wie sein schwächstes VDEV, deshalb plane ich das Layout immer vor der reinen Kapazität. Die TrueNAS-Dokumentation weist außerdem darauf hin, dass bei kleineren Arrays unter zehn Disks RAIDZ in der Regel die sinnvollere Wahl als dRAID ist.
| Layout | Typische Eignung | Platznutzen | Meine Einordnung |
|---|---|---|---|
| Mirror | VMs, Datenbanken, kleine bis mittlere NAS mit vielen Zufallszugriffen | Etwa 50 Prozent | Sehr schnell und robust, aber kapazitätsseitig teuer |
| RAIDZ1 | Leichte File-Server, Medienarchive, kleinere Setups mit überschaubarem Risiko | Etwa 67 bis 80 Prozent, je nach Laufwerkszahl | Für große HDDs und wichtige Daten nur mit Zurückhaltung einsetzen |
| RAIDZ2 | Heim- und Büro-NAS, Backup-Repository, gemischte Datenlast | Etwa 50 bis 75 Prozent | Für mich der beste Allround-Kompromiss |
| RAIDZ3 | Große Arrays, hohe Datenkritikalität, lange Rebuild-Zeiten | Etwa 60 bis 75 Prozent | Sinnvoll, wenn Ausfallsicherheit wichtiger ist als maximale Kapazität |
| dRAID | Sehr große Arrays mit vielen Laufwerken und großen Blöcken | Stark lastabhängig | Nur in Spezialfällen wirklich passend, für typische NAS meist überdimensioniert |
Ein praktischer Zusatz ist wichtig: Neuere TrueNAS- und OpenZFS-Versionen können RAIDZ erweitern, also einzelne Laufwerke nachträglich zu einem bestehenden RAIDZ-VDEV hinzufügen. Das ist hilfreich, ersetzt aber keine saubere Erstplanung, weil die Kapazitätsanzeige und die tatsächliche Nutzbarkeit nach einer Erweiterung nicht immer sofort so aussehen, wie man es auf den ersten Blick erwartet. Ich würde das als Werkzeug für gezielte Expansion sehen, nicht als Ausrede für ein schlechtes Layout.
Wer aus einer älteren Installation kommt, merkt spätestens hier, dass die eigentliche Frage nicht nur lautet, welches System man nimmt, sondern wie viel Struktur man später noch ändern kann. Genau deshalb lohnt sich ein sauberer Migrationsplan.
Wie eine Migration von FreeNAS realistisch aussieht
Bei Altanlagen würde ich nicht nach Gefühl vorgehen. Erst die Konfiguration sichern, dann die Pools und Schlüssel dokumentieren, dann den Zielpfad prüfen. Die aktuellen TrueNAS-Migrationshinweise trennen die Wege sehr sauber, und je nach Ausgangsversion kann ein sauberer Neuaufbau mit anschließendem Pool-Import robuster sein als ein riskanter Direktumstieg.
- Konfiguration exportieren und zusätzlich notieren, welche SMB-, NFS-, iSCSI-, Benutzer- und ACL-Einstellungen im Einsatz sind.
- Poolzustand prüfen, also Scrub-Ergebnis, SMART-Werte, Replikationsstatus und offene Warnungen kontrollieren.
- Schlüssel separat sichern, wenn Datasets verschlüsselt sind. Ohne saubere Key-Strategie wird jede Migration unnötig riskant.
- Zielweg festlegen: unterstütztes In-Place-Update, wenn es exakt für deine Quellversion vorgesehen ist, oder Clean Install plus Re-Import, wenn das die sauberere Variante ist.
- Erst testen, dann produktiv schalten, besonders wenn Jails, Plugins, ACLs oder ältere Dienste mit im Spiel sind.
Ich würde alte FreeNAS-Systeme außerdem nicht mit dem Gedanken anfassen, dass sich später alles irgendwie geradeziehen lässt. Genau das ist der Punkt, an dem viele NAS-Projekte unnötig teuer werden: Man unterschätzt die Abhängigkeiten zwischen Pool, Shares, Berechtigungen und Verschlüsselung. Daraus folgen die typischen Fehler, die man vorher vermeiden kann.
Die typischen Fehler bei NAS und RAIDZ
Viele Probleme wiederholen sich, weil dieselben Grundannahmen immer wieder falsch sind. ZFS macht das System nicht automatisch unverwundbar, und ein NAS ist nicht deshalb sicher, weil es RAID benutzt. Für mich sind das die häufigsten Stolpersteine:
| Fehler | Warum das teuer wird | Besser so |
|---|---|---|
| RAID mit Backup verwechseln | Ein defektes VDEV schützt nicht vor Ransomware, Löschen oder Bedienfehlern | Snapshots plus Replikation auf ein zweites Ziel einplanen |
| Verschlüsselung beim Pool blind aktivieren | Die Wiederherstellung wird unnötig kompliziert, wenn ein einzelner Schlüssel fehlt | Lieber unverschlüsselten Pool und verschlüsselte Datasets mit sauberem Key-Management nutzen |
| RAIDZ1 für große, wichtige HDD-Arrays | Rebuild-Zeiten und Risiko passen bei großen Laufwerken oft schlecht zusammen | Für wichtige Daten eher RAIDZ2 oder RAIDZ3 wählen |
| Das VDEV-Design später umbiegen wollen | Die ursprüngliche Daten-VDEV-Struktur lässt sich nicht beliebig ändern | Pool von Anfang an so planen, als müsse er mehrere Jahre unverändert laufen |
| Defekte Laufwerke durch kleinere Ersatzplatten ersetzen | TrueNAS verlangt ein Ersatzlaufwerk mit gleicher oder größerer Kapazität | Reserveplatten in passender Größe vorhalten und den Resilver abwarten |
Die TrueNAS-Dokumentation empfiehlt bei verschlüsselten Daten außerdem ausdrücklich, Schlüssel und Passphrasen getrennt zu sichern. Das ist keine theoretische Fußnote, sondern eine der wenigen Regeln, die ich in der Praxis nie verhandle. Sobald der Schlüssel weg ist, ist der Datensatz faktisch weg.
Wenn diese Fehler vermieden sind, bleibt noch die Frage, welche Konfiguration ich 2026 selbst wählen würde. Genau das entscheidet sich an den Workloads, nicht am Marketingnamen.
Womit ich 2026 ein neues System aufbauen würde
Für einen neuen Aufbau würde ich zuerst auf die Nutzung schauen und erst danach auf die Plattformdetails. TrueNAS bleibt für mich die klare Wahl, aber das passende Layout hängt vom Einsatz ab. Schon bei der Hardware gibt TrueNAS einen wichtigen Richtwert mit: Für grundlegende Installationen sind 8 GB RAM die Basis, mehr ist bei Apps, VMs oder intensiver Replikation sinnvoller.
- Heim- und Büro-NAS: aktuelles TrueNAS mit RAIDZ2, regelmäßigen Snapshots und einer zweiten Kopie außerhalb des Systems.
- VMs, Datenbanken oder viele kleine Dateien: Mirror oder mehrere gemirrorte VDEVs, weil IOPS und schnelle Wiederherstellung hier wichtiger sind als maximale Rohkapazität.
- Große Archiv- oder Medienpools: RAIDZ2 oder RAIDZ3, je nachdem wie kritisch die Daten und wie groß die Laufwerke sind.
- Sehr große Arrays mit vielen Laufwerken: dRAID nur dann, wenn die Größenordnung und der Workload wirklich dazu passen.
- Alte FreeNAS-Installationen: nur noch als Migrationsquelle behandeln, nicht als neues Zielsystem.
Die kurze Antwort auf die Ausgangsfrage ist deshalb ziemlich klar: Für neue Projekte würde ich 2026 nicht mehr auf FreeNAS setzen, sondern auf die aktuelle TrueNAS-Linie mit sauber geplantem Pool, passenden VDEVs und einer echten Backup-Strategie. Der Name ist zweitrangig; entscheidend ist, ob dein NAS im Ernstfall schnell wiederherstellbar bleibt und ob das RAID-Layout zu deinen Daten passt.
