WISSEN > GLOBAL FILESYSTEM -> NAS AUF GLOBAL FILE SYSTEM MIGRIEREN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
NAS auf Global File System migrieren
Von NAS zum Global File System: Warum die Migration über den Plattformwechsel entscheidet
Das sollten Sie mitnehmen:
- Die Migration ist der eigentliche Blocker.
Nicht die Zielarchitektur verhindert den Wechsel vom klassischen NAS zum Global File System, sondern die Unsicherheit über den Weg dorthin.
- Terabyte sind die falsche Planungsgröße.
Dateianzahl, Größenverteilung und Anzahl historischer Datenstände bestimmen die Laufzeit weit stärker als das Volumen.
- Der Datenpfad muss geprüft werden, nicht die Kopiergeschwindigkeit.
In hierarchischen Architekturen entsteht Backend-I/O auch dort, wo keine Datei übertragen wird.
- Übertragene ACLs sind noch keine identischen Rechte.
Quell- und Zielsystem können aus demselben Security Descriptor unterschiedliche effektive Berechtigungen ableiten.
- Abnahme braucht reale Benutzerprofile.
Administrative Tests prüfen Erreichbarkeit, nicht die Berechtigungssemantik im Alltag.
NAS auf Global File System migrieren
Inhaltsverzeichnis
- Was ein Global File System an der Migrationsplanung verändert
- Der Migrationsumfang bemisst sich nicht an den aktiven Daten
- Historische Snapshots sind ein eigenes Migrationsprojekt
- Warum der Pilot die spätere Laufzeit nicht vorhergesagt hat
- Ein Pilot muss den ungünstigsten Fall abbilden
- Die Reihenfolge der ACEs ist Semantik, nicht Formsache
- Berechtigungen müssen funktional abgenommen werden
- Warum die Server- und Share-Struktur unverändert blieb
- Zeitdruck verändert die Abnahmekriterien nicht
- Was vor dem ersten produktiven Datenlauf geklärt sein muss
- Fazit
- Quellen
Der Wechsel von einem klassischen NAS auf ein Global File System ist architektonisch gut beschrieben: ein globaler Namensraum statt gewachsener Share-Inseln, zentrale Datenhaltung im Objektspeicher, Caching am Standort. Die Argumente für diese Architektur sind in der Praxis selten strittig.
Strittig ist der Weg dorthin. In unseren Projekten ist nicht die Zielarchitektur der Grund, warum Organisationen ein bestehendes NAS länger betreiben als geplant, sondern die Migration. Sie berührt jede Abhängigkeit, die über Jahre entstanden ist, und sie ist der einzige Projektabschnitt, in dem sich Fehler unmittelbar auf produktive Zugriffe auswirken.
Wie weit dieser Abschnitt über eine Datenkopie hinausgeht, zeigt ein Projekt, das wir für eine Schweizer Behörde begleitet haben. Eine bestehende Umgebung aus Hitachi Data Ingestor (HDI) mit HCP als Objektspeicher wurde auf HCP Anywhere Enterprise abgelöst. Der Objektspeicher blieb dabei unverändert; ausgetauscht wurde die File-Service-Schicht darüber. Migriert wurden bis zu rund 300 TB, und zwar einschließlich der historischen Snapshots des Altsystems.
Ein Hinweis zur Einordnung: HCP Anywhere Enterprise ist die unter Hitachi-Marke vertriebene Ausprägung der CTERA-Plattform aus einer OEM-Vereinbarung beider Hersteller. CTERA gehört zum Portfolio von ASSISTRA. Wir weisen darauf hin, weil die im Folgenden beschriebenen Erkenntnisse nicht als Produktbewertung zu lesen sind, sondern als Migrationserfahrung; die problematischen Effekte lagen überwiegend auf der Quellseite und in der Semantik zwischen beiden Welten.
Was ein Global File System an der Migrationsplanung verändert
Bei einer NAS-zu-NAS-Migration liegen Quelle und Ziel strukturell nahe beieinander: zwei Dateisysteme, ein Kopiervorgang, vergleichbare Zugriffssemantik. Beim Übergang auf ein Global File System gilt das nicht mehr. Sowohl das Altsystem als auch die Zielplattform sind in diesem Projekt Caching-Systeme vor einem Objektspeicher. Was lokal vorliegt und was aus dem Backend geholt werden muss, entscheidet nicht der Migrationsauftrag, sondern die jeweilige Cache-Logik.
Damit verschiebt sich die Planungsfrage. Sie lautet nicht mehr, wie schnell zwei Dateisysteme Daten austauschen, sondern über welche Schichten ein einzelner Vergleichs- oder Kopiervorgang tatsächlich läuft. Diese Frage lässt sich nicht aus dem Datenblatt beantworten und in vielen Fällen auch nicht aus der Produktdokumentation. Sie muss gemessen werden.
Hinzu kommt eine zweite Verschiebung. Ein klassisches NAS speichert Berechtigungen in der Semantik des Betriebssystems, unter dem es läuft. Ein Global File System stellt SMB in der Regel über eine Samba-basierte Schicht bereit und bildet Windows-Rechte auf eine Unix-Grundlage ab. Die Übertragung der Berechtigungen ist damit nicht nur eine Kopie, sondern eine Übersetzung.
Der Migrationsumfang bemisst sich nicht an den aktiven Daten
Vor der Planung ist zu klären, was tatsächlich erhalten bleiben muss. Aktive Dateien und Verzeichnisse stehen dabei am Anfang, sind aber selten der aufwendige Teil. Hinzu kommen NTFS-ACLs samt Vererbung, Share-Berechtigungen, Verzeichnis- und Dateimetadaten, historische Versionen und Snapshots sowie sämtliche Abhängigkeiten von Clients und Applikationen. Ebenso gehören die Eigenschaften des Bestands dazu, die erfahrungsgemäß Ärger machen: sehr lange Pfade, problematische Dateinamen, extreme Verzeichnistiefen und große Mengen sehr kleiner Dateien.
In diesem Projekt erwiesen sich zwei Bereiche als bestimmend: die Migration der historischen Snapshots und die Interpretation der übernommenen Berechtigungsinformationen auf der Zielplattform. Beides war technisch deutlich anspruchsvoller als die Übertragung der aktiven Nutzdaten, und beides wäre bei einer reinen Volumenbetrachtung nicht sichtbar geworden.
Historische Snapshots sind ein eigenes Migrationsprojekt
Die bestehende HDI-Umgebung enthielt historische Snapshots, die weiterhin verfügbar bleiben mussten. Eine Migration des aktuellen Dateibestands hätte diese Historie verloren, und keines der verfügbaren Standardwerkzeuge deckt diesen Fall ab. Wir haben deshalb für das Projekt eine eigene Skriptsammlung entwickelt.
Das Verfahren arbeitet je Datenstand chronologisch. Der zu migrierende historische Snapshot wird auf dem Quellsystem gemountet und damit zugänglich gemacht. Anschließend vergleicht Robocopy diesen Stand gegen den bereits auf der Zielplattform vorhandenen Bestand und überträgt nur, was dort noch fehlt. Der so entstandene Stand wird abschließend in der Datenbank der Zielplattform so verankert, dass HCP Anywhere Enterprise ihn als eigenen Snapshot führt. Auf diesem Weg ließen sich die historischen HDI-Stände auf der neuen Plattform weiter bereitstellen.
Für die Planung ist der entscheidende Punkt, dass eine solche Snapshot-Migration keine wiederholte Dateikopie ist. Sie hat einen eigenen Datenpfad, eine eigene Zugriffsdynamik und damit ein eigenes Performanceprofil — und genau daran ist die ursprüngliche Zeitschätzung des Projekts gescheitert.
Warum der Pilot die spätere Laufzeit nicht vorhergesagt hat
Im Pilot- und Testbetrieb blieb eine Eigenschaft des Quellsystems unauffällig, die in der großen Migration bestimmend wurde. Sie war weder vorab dokumentiert noch in den technischen Vorabklärungen erkennbar.
HDI arbeitet beim Zugriff auf historische Snapshots effektiv als Gateway. Der lokale Festplattencache, der den aktiven Share bedient, kommt dabei nicht zum Tragen. Bereits das Lesen eines Verzeichnisses in einem alten Snapshot löst deshalb einen Download der zugehörigen Metadaten aus dem HCP aus. Für den Anwendungsfall, für den dieses Verhalten entworfen wurde, ist das unkritisch: Der Rückgriff auf einen historischen Stand betrifft im Alltag eine einzelne Datei, und die Latenz eines einzelnen Backend-Zugriffs fällt nicht ins Gewicht.
Bei einer Migration kehrt sich diese Annahme um. Der reale Datenpfad war nicht der erwartete Weg vom Migrationswerkzeug zum lokalen HDI-Bestand, sondern führte für jeden betroffenen Eintrag über HDI in den HCP und zurück.
[BILD: Datenpfad-Vergleich – erwarteter Pfad (Robocopy → HDI-Cache) gegenüber realem Pfad bei historischen Snapshots (Robocopy → HDI → HCP → HDI → Robocopy)]
Verschärft wurde das durch die Funktionsweise des Vergleichs. Robocopy kopiert eine bereits vorhandene Datei nur dann erneut, wenn Zeitstempel oder Größe abweichen. Dieser Vergleich ist ein Metadaten-Lookup — und genau der löste auf der Quellseite den Backend-Zugriff aus. Daraus folgt eine Unterscheidung, die in der Migrationsplanung regelmäßig untergeht: Dass eine Datei nicht kopiert werden muss, bedeutet nicht, dass sie keinen I/O auf dem Quellsystem verursacht.
Bei Millionen kleiner Dateien dominiert genau dieser Unterschied die Laufzeit. In einem dokumentierten Teilbestand des Projekts lagen rund 4,5 Millionen Dateien mit Größen bis etwa 4 KB. Ein solcher Bestand erzeugt bei gleicher Kapazität eine völlig andere Anzahl an Einzeloperationen als ein Bestand aus wenigen großen Dateien — und diese Anzahl multipliziert sich mit jedem zusätzlichen historischen Stand.
Die Angabe, es seien 300 TB zu migrieren, trägt eine Migrationsplanung deshalb nicht. Belastbar wird sie erst, wenn Datenvolumen, Dateianzahl, Größenverteilung, Verzeichnistiefe und Anzahl der zu übernehmenden historischen Datenstände gemeinsam erhoben werden. Zwei Bestände von je 100 TB können Laufzeiten erzeugen, die um eine Größenordnung auseinanderliegen.
Ein Pilot muss den ungünstigsten Fall abbilden
Aus dem Verlauf folgt eine methodische Konsequenz für die Testplanung. Ein funktional erfolgreicher Pilot beweist, dass der Migrationsweg funktioniert. Er beweist nicht, dass er unter den Bedingungen des vollständigen Bestands in vertretbarer Zeit funktioniert. Beides deckt sich nur, wenn Pilot und Produktion hinsichtlich Datenstruktur, Datenmenge, Historie, Berechtigungen und tatsächlichem Datenpfad vergleichbar sind.
Für einen Performance-Piloten sollte deshalb bewusst der technisch schwierigste Ausschnitt gewählt werden: sehr viele kleine Dateien, tiefe Verzeichnisstrukturen, historische Snapshots, komplexe ACL-Strukturen und Daten, die mit Sicherheit nicht im Cache liegen. Der durchschnittliche Datenbestand ist für diese Frage uninteressant.
Ebenso wichtig ist, was der Test beantworten soll. Die Frage nach der Kopiergeschwindigkeit des Werkzeugs greift zu kurz. Zu klären ist, welchen vollständigen I/O-Pfad das Werkzeug auf Quell- und Zielsystem erzeugt und ob die Daten dabei aus dem Arbeitsspeicher, einem lokalen Cache, einem Backend-Storage oder über eine weitere Storage-Schicht gelesen werden.
Die Reihenfolge der ACEs ist Semantik, nicht Formsache
Die zweite große Herausforderung trat erst nach produktiven Umschaltungen auf. Bei bestimmten Verzeichnisstrukturen zeigte sich ein Berechtigungsverhalten, das in den vorausgegangenen Tests nicht aufgefallen war. Die Analyse führte auf einen Effekt, der die Grenze zwischen Übertragung und Übersetzung sehr genau markiert.
Eine Discretionary Access Control List ist eine geordnete Liste. Windows wertet sie sequentiell aus und bricht ab, sobald der angeforderte Zugriff explizit gewährt oder verweigert wurde. Die kanonische Reihenfolge nach MS-DTYP stellt sicher, dass dabei das gewünschte Ergebnis entsteht: erst die expliziten Einträge, darin Deny vor Allow, anschließend die geerbten Einträge in der Reihenfolge ihrer Vererbung. Eine Liste in anderer Reihenfolge ist nicht ungültig — sie liefert lediglich ein anderes Ergebnis.
Im Projekt hatte das Quellsystem Einträge in nicht-kanonischer Reihenfolge gespeichert. Robocopy überträgt den Security Descriptor unverändert und damit auch diese Reihenfolge. Auf einem Windows-Ziel blieb das folgenlos, weil die Abweichung bei der Verarbeitung korrigiert wurde und der Fehler der Quelle damit verdeckt blieb.
Die Zielplattform stellt SMB über eine Samba-basierte Schicht bereit, und dort greift ein anderer Mechanismus. Samba legt den Windows-Security-Descriptor binär im erweiterten Attribut security.NTACL ab und bildet ihn in der Standardkonfiguration zusätzlich auf die POSIX-ACL-Schicht ab; beide Ebenen werden gesetzt und ausgewertet. Die NT-Sicht übernahm die gelieferte Reihenfolge unverändert, die abgeleitete POSIX-Schicht entstand daraus mit einem abweichenden Ergebnis. Der Effekt war entsprechend schwer zu greifen: Die angezeigten Berechtigungen waren korrekt, die darunterliegende Durchsetzung war es nicht.
[BILD: Zwei-Schichten-Darstellung – nicht-kanonische ACE-Reihenfolge in security.NTACL und daraus abgeleitete POSIX-ACL mit abweichendem effektivem Ergebnis]
Die verallgemeinerbare Erkenntnis ist nicht, dass ACL-Migrationen problematisch sind. Sie lautet präziser: Die erfolgreiche Übertragung einer ACL beweist nicht, dass Quell- und Zielsystem daraus bei jedem Zugriff dasselbe effektive Berechtigungsergebnis ableiten. Das gilt immer dann, wenn sich die Implementierungen unterscheiden — und beim Wechsel von einem NAS auf ein Global File System unterscheiden sie sich fast immer.
Berechtigungen müssen funktional abgenommen werden
Eine ACL-Prüfung, die Einträge auf Quelle und Ziel vergleicht, hätte diesen Fehler nicht gefunden. Die Einträge waren identisch. Abweichend war ihre Auswertung.
Wir hatten vor der finalen produktiven Migration empfohlen, das Ergebnis von einer Gruppe realer Testbenutzer prüfen zu lassen. Die Abnahme wurde stattdessen administrativ durchgeführt und war in dieser Form nicht geeignet, das Verhalten zu erkennen; sichtbar wurde es erst im produktiven Betrieb. Das ist keine Besonderheit dieses Projekts, sondern ein strukturelles Problem: Administrative Tests prüfen typischerweise, ob Shares erreichbar sind, Daten vorhanden sind und grundlegende Berechtigungen greifen. Ein Anwender erzeugt andere Zugriffspfade und arbeitet unter seinen tatsächlichen Gruppenmitgliedschaften.
Eine belastbare Abnahme braucht deshalb eine definierte Testgruppe, die unterschiedliche Berechtigungssituationen abdeckt: normale Benutzer, Benutzer verschiedener Abteilungen, Benutzer mit zusätzlichen Gruppenrechten und Benutzer mit bewusst eingeschränktem Zugriff. Geprüft wird nicht die Anzahl der Dateien, sondern die Vielfalt der Zugriffssituationen — ob ein Benutzer eine Datei sieht, ein Verzeichnis betreten, eine Datei anlegen, ändern oder löschen kann, ob ein Ausschluss wirksam bleibt und ob Verzeichnisse mit unterbrochener Vererbung sich verhalten wie zuvor.
Eine Vorgehensweise hat sich im weiteren Verlauf besonders bewährt. Nachdem die Berechtigungsprobleme aufgetreten waren, wurden Änderungen nicht wiederholt auf der produktiven Umgebung erprobt. Stattdessen haben wir separate Testsysteme aufgebaut und mit Kopien der betroffenen Datenbestände gearbeitet.
Im Juni 2026 gelang es, das an einem produktiven Filesystem beobachtete Verhalten auf einer Testinstanz reproduzierbar nachzustellen. Erst danach wurden Korrekturen und Firmware-Stände getestet; mit der korrigierten Firmware liefen die Tests erfolgreich durch.
Bei komplexen ACL- oder Metadatenproblemen sollte die erste Frage deshalb nicht lauten, welche Einstellung sich in der Produktion ändern lässt, sondern ob sich das Verhalten außerhalb der Produktion reproduzieren lässt. Ein reproduzierbarer Testfall verändert die Qualität des Troubleshootings grundlegend: Hypothesen lassen sich kontrolliert prüfen, und das Risiko weiterer Veränderungen an produktiven Daten sinkt.
Zeitdruck verändert die Abnahmekriterien nicht
Parallel zur Storage-Migration lief eine Windows-Client-Migration. Beim Zugriff dieser Clients auf die bestehende HDI-Umgebung standen benötigte Funktionen nicht mehr zur Verfügung, wodurch die Bereitstellung der Daten über die neue Plattform auch für die Client-Migration terminkritisch wurde. Der Druck, die Migration schnell abzuschließen, war entsprechend hoch.
Aus dem Projektverlauf lässt sich nicht ableiten, dass dieser Zeitdruck die späteren technischen Probleme verursacht hätte. Eine andere Schlussfolgerung ist dagegen unmittelbar belastbar: Zeitdruck reduziert die technischen Anforderungen an einen Cutover nicht. Wenn eine zweite Migration vom neuen Storage abhängt, steigt die Bedeutung einer belastbaren Abnahme sogar — der Fehler wirkt dann in zwei Projekte hinein. Storage-, Client-, Berechtigungs- und Applikationsabhängigkeiten gehören deshalb bereits in die Projektplanung, nicht in die Cutover-Woche.
Was vor dem ersten produktiven Datenlauf geklärt sein muss
Fünf Fragen sollten beantwortet sein, bevor der erste produktive Datenlauf startet.
Was muss tatsächlich erhalten bleiben? Nicht nur aktive Dateien, sondern Snapshots, historische Versionen, ACLs, Metadaten und gegebenenfalls weitere Funktionen des Altsystems.
Wie sieht der reale Datenbestand aus? Dateianzahl, Größenverteilung, Verzeichnistiefe und Anzahl historischer Stände, nicht nur Terabyte.
Welchen Datenpfad verwendet die Migration tatsächlich? Bei hierarchischen Architekturen mit Caches und Objektspeicher-Backends ist zu prüfen, woher die Daten während Vergleich und Kopie gelesen werden.
Wie wird funktionale Gleichheit geprüft? Mit realen Benutzeridentitäten, nicht durch den Vergleich von Dateianzahl und ACL-Einträgen.
Was passiert, wenn der Test scheitert? Testumgebung, Rollback, Verantwortlichkeiten und Go/No-Go-Kriterien müssen vor dem Cutover feststehen.
Fazit
Die Migration der Schweizer Behörde auf HCP Anywhere Enterprise wurde Ende August 2026 abgeschlossen. Die technisch schwierigsten Themen waren nicht die mehreren hundert Terabyte, sondern die Eigenschaften der Daten und ihrer Historie: Millionen kleiner Dateien, historische Snapshots, der tatsächliche Datenpfad in den Objektspeicher und die Semantik der Berechtigungsstrukturen.
Wer den Wechsel vom klassischen NAS auf ein Global File System plant, sollte die Migration deshalb nicht als Anhängsel der Architekturentscheidung behandeln. Sie ist kein Kopiervorgang, sondern die Überführung von Daten, Historie, Metadaten, Berechtigungssemantik und Zugriffspfaden in eine andere Systemlogik. Ein Pilot ist dafür unverzichtbar, aber nur aussagekräftig, wenn er die schwierigsten Eigenschaften des späteren Produktionsbestands bewusst abbildet.
Eine technisch erfolgreiche Kopie ist noch keine erfolgreiche Migration. Validiert ist sie erst, wenn reale Benutzer unter ihren tatsächlichen Berechtigungen auf der Zielplattform dasselbe Verhalten vorfinden wie zuvor.
Quellen
Microsoft, [MS-DTYP] Windows Data Types, Abschnitt 2.4.5 (ACL, kanonische Form)
Microsoft, Order of ACEs in a DACL, Windows Security Authorization Dokumentation
Samba, vfs_acl_xattr(8) Manpage, Parameter acl_xattr:ignore system acls
Microsoft, Robocopy-Dokumentation (Klassifikation von Dateien anhand Zeitstempel und Größe)
Hitachi Vantara, Hitachi Data Ingestor – Installation and Configuration Guide, Kapitel „Linking HDI and HCP" (Stub-Dateien, Recall, Versionsverwaltung)
Hitachi Vantara / CTERA, Ankündigung der OEM-Vereinbarung zu HCP Anywhere Enterprise, Juni 2023
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
