Synology-Alternative: die Migration auf TrueNAS in der Praxis

Synology Alternative ist 2026 eine Frage, die in vielen KMU auf den Tisch kommt: Nicht aus Ideologie, sondern weil das vorhandene NAS an eine reale Grenze stoesst — die Preisliste steigt, das Modell wird abgekuendigt, die verfuegbaren Festplatten der eigenen HCL passen nicht mehr zum benoetigten Volumen. TrueNAS ist dann der offensichtliche Kandidat. Wir zeigen aus mehreren Migrationsprojekten, wie der Wechsel realistisch ablaeuft — Datenkopie, Pool-Layout, Backup, Freigaben — und wo die haeufigsten Stolperstellen liegen.

Warum die Frage nach der Synology-Alternative 2026 lauter wird

Die Motive, ueber einen Wechsel nachzudenken, sind selten dogmatisch. In der Praxis sehen wir drei wiederkehrende Muster:

• Preisdruck bei DSM-Hardware und Erweiterungen. Die Rack-Modelle der oberen Klasse sind spuerbar teurer geworden, Erweiterungseinheiten ebenfalls. Wer heute ein groesseres Volumen aufbaut, vergleicht wieder aktiv.
• HDD-Kompatibilitaetslisten und knapper werdende Modell-Auswahl. DSM verlangt fuer viele Business-Geraete Festplatten aus einer engen Liste. Wenn das benoetigte Modell dort nicht auftaucht, ist die Diskussion mit dem Einkauf schnell laestig.
• Skalierung stoesst an das Gehaeuse. SHR ist bequem, aber die Zahl der Einschuebe ist endlich. Wer von 60 auf 250 TB will, wechselt entweder das Chassis oder das System.

Dazu kommen weiche Faktoren — Roadmap-Sichtbarkeit, die Frage nach echter Datenintegritaet, die Aussicht auf ZFS-Snapshots ohne Volumen-Limit. All das macht TrueNAS als Synology-Alternative zu einer Option, die man ernsthaft rechnen kann. Eine ausfuehrliche Featureseite dazu ist unser TrueNAS vs Synology Vergleich — hier geht es dagegen um die Migration in der Praxis.

TrueNAS als Synology-Alternative — was sich real aendert

Ein NAS-Wechsel ist mehr als ein Hardware-Tausch. Zwei Denkumstellungen sind entscheidend, damit spaeter niemand ueberrascht ist.

Vom fertigen Geraet zum Storage-Server

Ein Synology ist ein Konsumenten-nahes Appliance-Konzept: Karton auf, Platten rein, DSM oeffnet den Assistenten. TrueNAS ist ein Storage-Betriebssystem, das auf einem echten Server laeuft — ob als DATAZONE-Appliance (R-, H-, M- oder F-Serie) oder als Community-Edition auf eigener Hardware. Das ist ein Vorteil (kein Vendor-Lock-in, echte Server-Klasse, offene Roadmap) und eine Umstellung: Es gibt keine „One-Click-App fuer Foto-Sharing”. TrueNAS ist ein Storage-Server mit Apps-Katalog fuer die Aufgaben, die im Unternehmen wirklich zaehlen — SMB, NFS, iSCSI, S3, Replikation, Snapshots.

Fuer die Systemauswahl empfehlen wir, den TrueNAS-Konfigurator zu nutzen: Er berechnet nutzbare Kapazitaet je RAID-Level, ordnet die passende Serie zu und liefert ein pruefbares Angebot. Preisrahmen finden Sie dort direkt — feste Endpreise haengen an tagesaktuellen HDD- und NVMe-Kursen und laufen deshalb bei uns immer ueber ein individuelles Angebot.

SHR-Denken vs RAID-Z-Denke

Der groesste konzeptionelle Sprung liegt beim Pool-Layout. SHR ist ein Bequemlichkeits-Layer ueber mdadm mit gemischten Platten und automatischer Erweiterung. RAID-Z (ZFS) denkt anders: Ein Pool besteht aus einem oder mehreren vDevs, und der Grundriss der vDevs entscheidet ueber Performance, Redundanz und spaetere Erweiterbarkeit.

Praktische Regeln aus unseren Projekten:

• Gleichgrosse Platten pro vDev. Sonst richtet ZFS sich nach der kleinsten — Kapazitaet geht verloren.
• Anzahl der vDevs bestimmt IOPS, nicht die Anzahl der Platten pro vDev. Wer viele parallele Zugriffe hat (Virtualisierung, Datenbanken), plant mehr, kleinere vDevs.
• RAID-Z2 ist der Standard fuer Business-Storage ab acht Platten pro vDev. RAID-Z1 nur fuer kleine Pools oder klar unkritische Daten.
• Erweiterung geschieht durch Hinzufuegen ganzer vDevs, nicht durch Einschieben einzelner Platten (auch wenn RAID-Z Expansion im aktuellen TrueNAS schrittweise moeglich ist — planbar bleibt die vDev-Denke).

Wer ein 8-Bay-DSM mit SHR-2 hatte, kommt in der Regel auf einer 12-Bay-R-Serie mit zwei RAID-Z2-vDevs an — gleiche Redundanz, aber Kopfzeile fuer Wachstum ohne Systemwechsel.

Datenmigration Synology zu TrueNAS — rsync und SMB in der Praxis

Die Datenkopie ist meistens weniger dramatisch, als sie in Foren klingt. Zwei Wege haben sich bewaehrt.

SMB-Kopie — fuer kleine Volumen und Windows-Admins

Bis etwa 5 TB und wenn die Migration ohnehin ueber ein Wochenende laeuft, ist SMB die pragmatischste Loesung. Beide Systeme werden als Freigaben in denselben Windows-Server oder Windows-Client eingebunden, dann laeuft robocopy mit /MIR /COPY:DAT /R:2 /W:5 /MT:16 durch. Vorteil: vertraute Werkzeuge, gute Berechtigungs-Uebernahme, im Wesentlichen fehlerfrei. Nachteil: langsamer als eine direkte Verbindung, und bei Millionen kleiner Dateien wird SMB-Overhead spuerbar.

rsync ueber SSH — der Weg fuer grosse und langlaufende Migrationen

Ab zweistelligen Terabytes oder wenn die Migration ueber mehrere Tage inkrementell laufen soll, ist rsync ueberlegen. Auf dem Synology-Modell wird rsync per SSH aktiviert — als root-aequivalenter Nutzer, damit ACLs mitkommen. Auf dem TrueNAS-Zielsystem wird ein SSH-Zugang mit Schluessel eingerichtet und ein Ziel-Dataset vorbereitet. Der klassische Aufruf sieht so aus (bewusst als Blockzitat, nicht als Fence, damit die Syntax lesbar bleibt):

rsync -aHAXv —numeric-ids —progress /volume1/quelle/ user@truenas:/mnt/pool1/ziel/

Wichtig ist der Punkt zwischen Anfangs- und Folge-Lauf: Der Erst-Sync darf lange laufen, danach sind inkrementelle Nachlaeufe kurz genug, um eine echte Umschaltung an einem definierten Zeitpunkt zu erlauben. In der Praxis heisst das: eine Woche Vorbereitung, ein Wochenende fuer die Umschaltung, kein Big-Bang.

Bei sehr grossen Volumen empfehlen wir zusaetzlich, temporaer eine direkte 10-GbE-Verbindung zwischen Alt- und Neu-System zu schalten — das ist der Unterschied zwischen 12 Stunden und 3 Tagen bei 30 TB.

Freigaben, Berechtigungen, ACLs

Wer heute ueber Synology mit Active Directory authentifiziert, sollte den TrueNAS-AD-Join vor der Migration abschliessen und mit einem Testshare validieren. Details dazu finden Sie in unserem Beitrag TrueNAS Active Directory Domain Join. rsync mit -aHAXv uebertraegt die Rechte, aber die Zuordnung UID/GID -> SID bekommt erst in einer sauber gejointen Domaene den richtigen Kontext.

Kleiner Tipp: Wenn ACLs auf dem Synology historisch gewachsen sind (aus Zeiten, in denen mal lokal angelegt, mal via AD, mal via SMB von einem Mac gesetzt wurde), lohnt der Anlass, sie einmal zu bereinigen statt sie 1:1 zu klonen. Wir sehen das in praktisch jedem Projekt — ein aufgeraeumter Share ist ein Nebenprodukt der Migration.

Snapshots und Backup — was ersetzt Hyper Backup und Snapshot Replication?

Der Umstieg beim Snapshotting ist erfreulich: TrueNAS-Snapshots sind auf ZFS-Ebene, kosten praktisch nichts und sind pro Dataset frei planbar. Snapshot Replication wird zu ZFS Send/Receive — meist zu einem zweiten TrueNAS als Ziel, entweder im gleichen Rack oder in einem zweiten Standort.

Hyper Backup wird typischerweise durch eine Kombination ersetzt:

• ZFS Snapshots fuer den kurzfristigen Rueckgriff (Ransomware, versehentlich geloeschte Datei).
• Replikation zu einem zweiten TrueNAS fuer die Standby-Kopie mit Verzoegerung — Basis unserer KMU-Backup-Strategie mit Proxmox und TrueNAS.
• Cloud Sync in einen Objektspeicher (S3, Backblaze B2, Wasabi) fuer die Offsite-Kopie.

Fuer viele KMU ergibt das ein 3-2-1-1-0-Setup, das mit dem alten Synology in dieser Klarheit nicht darstellbar war — weil DSM-seitige Retention-Regeln, App-Kompatibilitaet und Volumen-Limits zu oft dazwischen funken.

Der Wechsel Schritt fuer Schritt in einer typischen KMU-Umgebung

Wir arbeiten in Projekten meistens nach diesem Grundriss:

1. Aufnahme. Welche Freigaben, welche Volumen, welche Kunden-Prozesse haengen dran, welche Snapshot-Historie muss ueberleben.
2. Zielsystem auslegen. ueber den Konfigurator wird die passende Serie gewaehlt — R fuer klassische File-Server, H fuer Virtualisierung, F fuer alles latenzkritische. Fuer Rechenzentrum und HA nutzen wir die M-Serie (Modelle M30 und M40 sind aktuell; M50/M60 sind EOL und keine Empfehlung mehr).
3. Netz und AD. VLAN, IPs, SMB-Signing, AD-Join, DFS-N-Namespace-Anpassung wenn vorhanden.
4. Erst-Sync. Ueber SMB oder rsync, mit klarer Abschaetzung der Laufzeit.
5. Test-Freigaben parallel eroeffnen — eine Handvoll Anwender arbeitet einige Tage gegen die neue Struktur, bevor umgeschaltet wird.
6. Umschaltung. Ein Freitagabend rsync-Delta, DNS/DFS-Wechsel, Montag frueh Bestaetigung.
7. Rueckbau. Synology bleibt zwei bis vier Wochen als Nur-Lese-Ziel im Netz, danach wird sie ausser Betrieb genommen oder als Backup-Landeplatz fuer eine spezifische Kopie umgewidmet.

Dieser Ablauf ist bewusst konservativ. Wir haben in fast allen Projekten Reserven eingebaut — gerade an einem AD-Join oder an einem DFS-N-Wechsel kann eine unentdeckte Berechtigungsleiche das Wochenende ruinieren.

Was ein Migrationsprojekt realistisch kostet und dauert

Wir geben grundsaetzlich keine festen EUR-Preise heraus, weil HDD- und NVMe-Preise sich taktisch bewegen — gerade 2026 mit den Nachwirkungen der KI-Nachfrage. Realistisch gilt fuer einen KMU-typischen Wechsel:

• Hardware: Ein Preisrahmen, der ueber den TrueNAS-Konfigurator je nach Serie und Kapazitaet transparent wird. Konkrete Angebote bekommt man bei uns oder unseren Partnern — ein Blick auf die Partnerseite fuer TrueNAS-Deutschland zeigt den Rahmen. Enterprise-Modelle und M-Serie laufen ueber individuelle Angebote.
• Migrationsprojekt (Dienstleistung, Planung, Datenkopie, AD-Integration, Abnahme): Je nach Volumen und Komplexitaet ein ueberschaubarer Projekttopf im niedrigen bis mittleren vierstelligen Bereich; grosse Umgebungen entsprechend hoeher.
• Ausfallzeit fuer die Endanwender: Bei sauberer Vorbereitung ein Wochenende, oft nur ein Samstag.

Die Frage, die wir am haeufigsten am Ende hoeren: „Warum haben wir das nicht schon frueher gemacht?” — meistens deshalb, weil die Angst vor der Migration groesser war als die Migration selbst. Das mag hemdsaermelig klingen, deckt sich aber mit unserer Erfahrung.

FAQ zur Synology-Alternative und TrueNAS-Migration

Ist TrueNAS ueberhaupt die richtige Synology-Alternative fuer ein kleines Buero?

Ja, sofern das Buero mehr will als reines File-Sharing fuer zwei bis drei Personen. Fuer wirklich kleine Szenarien sind Synology-Einstiegsmodelle bequem, und das bleibt auch so. Sobald aber Snapshots ohne Volumen-Limit, echte Datenintegritaet oder eine geplante Skalierung ueber die Jahre eine Rolle spielen, ist TrueNAS — auch als Mini-Baureihe — der belastbarere Weg.

Muessen wir alle Daten gleichzeitig migrieren?

Nein. In der Praxis migrieren wir in Wellen. Grosse, kalte Archive laufen im Voraus als Erst-Sync, aktive Freigaben werden ueber ein Wochenende inkrementell nachgezogen. Ein Big-Bang-Wechsel ist selten noetig und selten sinnvoll.

Was passiert mit den bestehenden Synology-Snapshots?

Snapshots aus DSM sind Btrfs-nah und lassen sich nicht 1:1 in ZFS uebergeben. Der uebliche Weg: Auf dem Synology einen definierten Retention-Stand einfrieren, ihn zusaetzlich als vollstaendige Kopie migrieren und in einem eigenen Read-Only-Dataset auf dem TrueNAS aufheben, solange er compliance-relevant ist. Aktive Snapshot-Historie beginnt auf TrueNAS neu — dafuer nahezu kostenlos und ohne Limit.

Muessen wir eine grosse Enterprise-Appliance kaufen, oder reicht auch ein kleineres Modell?

Die Antwort haengt am Workload. Fuer klassische File-Server-Nutzung mit einem SHR-2-Vorgaenger reicht meistens ein Modell aus der R-Serie. Fuer Virtualisierung oder Datenbanken kommt die H-Serie ins Spiel, fuer Rechenzentrum und HA die M-Serie. Der TrueNAS-Konfigurator hilft bei der Auslegung, ohne dass man dafuer Datenblaetter waelzen muss.

Wie sieht die Backup-Strategie nach dem Wechsel aus?

TrueNAS macht 3-2-1-1-0 sauber darstellbar: ZFS-Snapshots als Nahzeit-Rueckgriff, Replikation zu einem zweiten TrueNAS als Standby-Kopie, Cloud Sync in Objektspeicher als Offsite. Wer bereits eine KMU-Backup-Strategie mit Proxmox und TrueNAS gelesen hat, findet die gleichen Bausteine wieder — nur mit besserer Kontrolle als in DSM.

Wie viel Ausfallzeit muessen wir einplanen?

In den meisten unserer Projekte liegt die eigentliche Umschaltung zwischen zwei und acht Stunden am Wochenende. Der Erst-Sync laeuft vorher parallel im Hintergrund, das Delta am Umschaltabend ist klein. Voraussetzung ist eine saubere Vorbereitung — vor allem AD-Join, Freigabenamen und DFS-N.