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 stößt — die Preisliste steigt, das Modell wird abgekündigt, die verfügbaren Festplatten der eigenen HCL passen nicht mehr zum benötigten Volumen. TrueNAS ist dann der offensichtliche Kandidat. Wir zeigen aus mehreren Migrationsprojekten, wie der Wechsel realistisch abläuft — Datenkopie, Pool-Layout, Backup, Freigaben — und wo die häufigsten Stolperstellen liegen.

Warum die Frage nach der Synology-Alternative 2026 lauter wird

Die Motive, über 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 spürbar teurer geworden, Erweiterungseinheiten ebenfalls. Wer heute ein größeres Volumen aufbaut, vergleicht wieder aktiv.
• HDD-Kompatibilitätslisten und knapper werdende Modell-Auswahl. DSM verlangt für viele Business-Geräte Festplatten aus einer engen Liste. Wenn das benötigte Modell dort nicht auftaucht, ist die Diskussion mit dem Einkauf schnell lästig.
• Skalierung stößt an das Gehäuse. SHR ist bequem, aber die Zahl der Einschübe 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 Datenintegrität, die Aussicht auf ZFS-Snapshots ohne Volumen-Limit. All das macht TrueNAS als Synology-Alternative zu einer Option, die man ernsthaft rechnen kann. Eine ausführliche 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 ändert

Ein NAS-Wechsel ist mehr als ein Hardware-Tausch. Zwei Denkumstellungen sind entscheidend, damit später niemand überrascht ist.

Vom fertigen Gerät zum Storage-Server

Ein Synology ist ein Konsumenten-nahes Appliance-Konzept: Karton auf, Platten rein, DSM öffnet den Assistenten. TrueNAS ist ein Storage-Betriebssystem, das auf einem echten Server läuft — 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 für Foto-Sharing”. TrueNAS ist ein Storage-Server mit Apps-Katalog für die Aufgaben, die im Unternehmen wirklich zählen — SMB, NFS, iSCSI, S3, Replikation, Snapshots.

Für die Systemauswahl empfehlen wir, den TrueNAS-Konfigurator zu nutzen: Er berechnet nutzbare Kapazität je RAID-Level, ordnet die passende Serie zu und liefert ein prüfbares Angebot. Preisrahmen finden Sie dort direkt — feste Endpreise hängen an tagesaktuellen HDD- und NVMe-Kursen und laufen deshalb bei uns immer über ein individuelles Angebot.

SHR-Denken vs RAID-Z-Denke

Der größte konzeptionelle Sprung liegt beim Pool-Layout. SHR ist ein Bequemlichkeits-Layer über 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 über Performance, Redundanz und spätere Erweiterbarkeit.

Praktische Regeln aus unseren Projekten:

• Gleichgroße Platten pro vDev. Sonst richtet ZFS sich nach der kleinsten — Kapazität 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 für Business-Storage ab acht Platten pro vDev. RAID-Z1 nur für kleine Pools oder klar unkritische Daten.
• Erweiterung geschieht durch Hinzufügen ganzer vDevs, nicht durch Einschieben einzelner Platten (auch wenn RAID-Z Expansion im aktuellen TrueNAS schrittweise möglich 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 für 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 bewährt.

SMB-Kopie — für kleine Volumen und Windows-Admins

Bis etwa 5 TB und wenn die Migration ohnehin über ein Wochenende läuft, ist SMB die pragmatischste Lösung. Beide Systeme werden als Freigaben in denselben Windows-Server oder Windows-Client eingebunden, dann läuft robocopy mit /MIR /COPY:DAT /R:2 /W:5 /MT:16 durch. Vorteil: vertraute Werkzeuge, gute Berechtigungs-Übernahme, im Wesentlichen fehlerfrei. Nachteil: langsamer als eine direkte Verbindung, und bei Millionen kleiner Dateien wird SMB-Overhead spürbar.

rsync über SSH — der Weg für große und langlaufende Migrationen

Ab zweistelligen Terabytes oder wenn die Migration über mehrere Tage inkrementell laufen soll, ist rsync überlegen. Auf dem Synology-Modell wird rsync per SSH aktiviert — als root-äquivalenter Nutzer, damit ACLs mitkommen. Auf dem TrueNAS-Zielsystem wird ein SSH-Zugang mit Schlüssel 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 Nachläufe kurz genug, um eine echte Umschaltung an einem definierten Zeitpunkt zu erlauben. In der Praxis heißt das: eine Woche Vorbereitung, ein Wochenende für die Umschaltung, kein Big-Bang.

Bei sehr großen Volumen empfehlen wir zusätzlich, temporär 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 über Synology mit Active Directory authentifiziert, sollte den TrueNAS-AD-Join vor der Migration abschließen und mit einem Testshare validieren. Details dazu finden Sie in unserem Beitrag TrueNAS Active Directory Domain Join. rsync mit -aHAXv überträgt die Rechte, aber die Zuordnung UID/GID -> SID bekommt erst in einer sauber gejointen Domäne 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 aufgeräumter 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 für den kurzfristigen Rückgriff (Ransomware, versehentlich gelöschte Datei).
• Replikation zu einem zweiten TrueNAS für die Standby-Kopie mit Verzögerung — Basis unserer KMU-Backup-Strategie mit Proxmox und TrueNAS.
• Cloud Sync in einen Objektspeicher (S3, Backblaze B2, Wasabi) für die Offsite-Kopie.

Für 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-Kompatibilität und Volumen-Limits zu oft dazwischen funken.

Der Wechsel Schritt für Schritt in einer typischen KMU-Umgebung

Wir arbeiten in Projekten meistens nach diesem Grundriss:

1. Aufnahme. Welche Freigaben, welche Volumen, welche Kunden-Prozesse hängen dran, welche Snapshot-Historie muss überleben.
2. Zielsystem auslegen. Über den Konfigurator wird die passende Serie gewählt — R für klassische File-Server, H für Virtualisierung, F für alles latenzkritische. Für 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. Über SMB oder rsync, mit klarer Abschätzung der Laufzeit.
5. Test-Freigaben parallel eröffnen — eine Handvoll Anwender arbeitet einige Tage gegen die neue Struktur, bevor umgeschaltet wird.
6. Umschaltung. Ein Freitagabend rsync-Delta, DNS/DFS-Wechsel, Montag früh Bestätigung.
7. Rückbau. Synology bleibt zwei bis vier Wochen als Nur-Lese-Ziel im Netz, danach wird sie außer Betrieb genommen oder als Backup-Landeplatz für 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 grundsätzlich keine festen EUR-Preise heraus, weil HDD- und NVMe-Preise sich taktisch bewegen — gerade 2026 mit den Nachwirkungen der KI-Nachfrage. Realistisch gilt für einen KMU-typischen Wechsel:

• Hardware: Ein Preisrahmen, der über den TrueNAS-Konfigurator je nach Serie und Kapazität transparent wird. Konkrete Angebote bekommt man bei uns oder unseren Partnern — ein Blick auf die Partnerseite für TrueNAS-Deutschland zeigt den Rahmen. Enterprise-Modelle und M-Serie laufen über individuelle Angebote.
• Migrationsprojekt (Dienstleistung, Planung, Datenkopie, AD-Integration, Abnahme): Je nach Volumen und Komplexität ein überschaubarer Projekttopf im niedrigen bis mittleren vierstelligen Bereich; große Umgebungen entsprechend höher.
• Ausfallzeit für die Endanwender: Bei sauberer Vorbereitung ein Wochenende, oft nur ein Samstag.

Die Frage, die wir am häufigsten am Ende hören: „Warum haben wir das nicht schon früher gemacht?” — meistens deshalb, weil die Angst vor der Migration größer war als die Migration selbst. Das mag hemdsärmelig klingen, deckt sich aber mit unserer Erfahrung.

FAQ zur Synology-Alternative und TrueNAS-Migration

Ist TrueNAS überhaupt die richtige Synology-Alternative für ein kleines Büro?

Ja, sofern das Büro mehr will als reines File-Sharing für zwei bis drei Personen. Für wirklich kleine Szenarien sind Synology-Einstiegsmodelle bequem, und das bleibt auch so. Sobald aber Snapshots ohne Volumen-Limit, echte Datenintegrität oder eine geplante Skalierung über die Jahre eine Rolle spielen, ist TrueNAS — auch als Mini-Baureihe — der belastbarere Weg.

Müssen wir alle Daten gleichzeitig migrieren?

Nein. In der Praxis migrieren wir in Wellen. Große, kalte Archive laufen im Voraus als Erst-Sync, aktive Freigaben werden über ein Wochenende inkrementell nachgezogen. Ein Big-Bang-Wechsel ist selten nötig und selten sinnvoll.

Was passiert mit den bestehenden Synology-Snapshots?

Snapshots aus DSM sind Btrfs-nah und lassen sich nicht 1:1 in ZFS übergeben. Der übliche Weg: Auf dem Synology einen definierten Retention-Stand einfrieren, ihn zusätzlich als vollständige 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 — dafür nahezu kostenlos und ohne Limit.

Müssen wir eine große Enterprise-Appliance kaufen, oder reicht auch ein kleineres Modell?

Die Antwort hängt am Workload. Für klassische File-Server-Nutzung mit einem SHR-2-Vorgänger reicht meistens ein Modell aus der R-Serie. Für Virtualisierung oder Datenbanken kommt die H-Serie ins Spiel, für Rechenzentrum und HA die M-Serie. Der TrueNAS-Konfigurator hilft bei der Auslegung, ohne dass man dafür Datenblätter wälzen muss.

Wie sieht die Backup-Strategie nach dem Wechsel aus?

TrueNAS macht 3-2-1-1-0 sauber darstellbar: ZFS-Snapshots als Nahzeit-Rückgriff, 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 müssen wir einplanen?

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