bizIT

Wenn nach einer NAS-Migration plötzlich Freigaben leer wirken, Ordner fehlen oder Zugriffsrechte komplett durcheinander sind, ist das selten „einfach weg“. Meist steckt ein Mix aus falschem Kopiermodus, fehlerhaften ACLs, Snapshots/Versionen, Index-Illusionen oder einem Volume-Layout dahinter, das nicht so übernommen wurde, wie Sie es erwartet haben. Die gute Nachricht: Mit den richtigen Sofort-Schritten lässt sich der Schaden oft begrenzen – und die Daten sind häufig noch erreichbar oder rekonstruierbar. In diesem Beitrag bekommen Sie einen klaren Plan: Was Sie sofort stoppen sollten, wie Sie typische Migrationsfehler erkennen und wie eine saubere Datenrettung (und Notfall-Weiterbetrieb) rund um Berlin, etwa in Treptow, Neukölln oder Friedrichshain, praktisch aussieht.

Inhalt

• Typische Symptome nach einer NAS-Migration
• Erste Hilfe: Was Sie sofort tun (und lassen) sollten
• Warum Daten „weg“ wirken, obwohl sie noch da sind
• Sicher prüfen: Wo Sie als Erstes nachsehen
• Berechtigungen (ACLs) und Identitäten: Der klassische Stolperstein
• Migrationswege im Vergleich: rsync, SMB-Kopie, Hersteller-Tools
• Wenn das neue NAS schon „produktiv“ ist: Schonende Rettung ohne Betriebsstopp
• Sonderfälle: Verschlüsselte Shares, iSCSI, Docker/VM-Apps
• Prävention für den nächsten Umzug (kurz, aber Gold wert)
• Wann professionelle Datenrettung sinnvoll ist

Typische Symptome nach einer NAS-Migration

Sie kennen das vielleicht: Die Migration lief „durch“, das neue NAS steht im Rack, alle sind erleichtert – und dann kommen die ersten Tickets.

• Freigaben sind leer, obwohl die Kopie angeblich erfolgreich war.
• Ordnerstruktur ist da, aber Dateien fehlen oder wirken „unsichtbar“.
• Zugriff verweigert nach Domain-Wechsel oder neuer AD-Anbindung.
• Dateien sind da, aber Programme finden sie nicht (CAD, DMS, Buchhaltung, Medienserver).
• Duplikate oder kryptische Namen durch falsche Kodierung.
• Zeitstempel sind verdreht, „neueste“ Daten wirken plötzlich alt.

Gerade in Teams, die aus Kreuzberg, Mitte oder Potsdam auf zentrale Shares zugreifen, ist das ein echter Produktivitäts-Killer. Und genau darum zählt jetzt: nicht hektisch „reparieren“, sondern erst sicher verstehen.

Erste Hilfe: Was Sie sofort tun (und lassen) sollten

Ein NAS ist kein USB-Stick. Jede spontane Aktion kann Metadaten verändern – und die sind bei Rettung und Rekonstruktion oft wichtiger als die Datei selbst.

Sofort tun:

1. Schreibzugriffe stoppen, wenn möglich: Nutzer abmelden, Shares temporär read-only, Dienste pausieren (Indexing, Medienserver, Sync-Tools).

2. Status sichern: Screenshots der Storage-Ansicht, Volume/Pool-Layout, Fehlermeldungen, Migrationsprotokolle.

3. Schnelles „Was ist wo?“: Welche Freigabe fehlt? Welche Abteilung? Welche Datenmenge? Welche Uhrzeit war der Cutover?

4. Wenn das alte NAS noch existiert: nicht anfassen, nicht neu initialisieren, nicht „aufräumen“. Lieber sauber dokumentieren.

Unbedingt lassen:

• Kein „Rebuild“ auf Verdacht.
• Keine „Optimierung“, „Dedupe-Start“ oder „Scrubbing“, wenn Sie nicht sicher sind, was genau passiert.
• Kein wildes Rekopieren in beide Richtungen. Das erzeugt Versionschaos.

Warum Daten „weg“ wirken, obwohl sie noch da sind

Das fiese an NAS-Migrationsproblemen: Oft sind die Bits noch vorhanden – aber der Weg dorthin ist verstellt.

Ein paar typische Ursachen:

• Berechtigungen passen nicht mehr: Neue SIDs nach Domain-Move, lokale Benutzer statt AD, geänderte Gruppen.
• Dataset/Share zeigt auf einen anderen Pfad: Besonders bei Volume-Wechseln, Storage-Pools oder wenn ein Hersteller-Tool den Zielordner anders anlegt.
• Snapshot-/Versioning-Konflikte: Daten sind im Snapshot vorhanden, aber nicht in „Live“.
• Index-Illusion: Suche/Explorer zeigt „nichts“, weil Index neu aufbaut oder Caches falsch sind.
• SMB-Client-Caching / Offline Files: Auf Windows-Clients wirkt etwas leer, weil offline/Cache spinnt.

Klingt banal? Ist aber genau der Punkt: Wenn Sie jetzt „einfach neu kopieren“, schreiben Sie unter Umständen über die einzig konsistente Version drüber.

Sicher prüfen: Wo Sie als Erstes nachsehen

Sie wollen Beweise, keine Vermutungen. Gehen Sie in dieser Reihenfolge vor:

1. Speicherplatz-Check: Ist das Zielvolume „voller“ als es wirkt? Viel belegter Speicher bei „leeren“ Shares ist ein Hinweis auf unsichtbare Daten, Snapshots oder falsche Freigabe-Pfade.

2. Freigabe-Zielpfad: Stimmt der Pfad wirklich? Ein Tippfehler oder ein abweichender Mountpoint kann alles erklären.

3. Snapshot/Versionen: Gibt es Snapshots aus dem Migrationszeitraum? Können Sie Daten daraus browsen oder mounten?

4. Protokolle der Migration: rsync-Logs, Copy-Reports, Fehlerlisten (z. B. „permission denied“, „skipping“, „filename too long“).

5. Client-Sicht vs. NAS-Sicht: Wenn möglich, prüfen Sie lokal auf dem NAS (Shell/Dateimanager) vs. Zugriff über SMB/NFS.

Wenn Sie dabei merken, dass es „irgendwie nach Rechten riecht“ – ja, tut es oft.

Berechtigungen (ACLs) und Identitäten: Der klassische Stolperstein

Bei Migrationen in Teams (Agenturen, Kanzleien, Praxen) aus Berlin und Umgebung – etwa rund um Adlershof oder Schöneweide – sehen wir immer wieder das gleiche Muster: Daten sind da, aber niemand kommt ran.

Warum?

• NTFS-ACLs vs. NAS-ACLs: Nicht jede NAS-Plattform bildet Windows-Rechte 1:1 ab.
• SID-Übersetzung: Wechseln Sie Domäne oder AD-Struktur, werden alte SIDs zu „unknown account“.
• Vererbung: Eine falsch gesetzte Vererbung kann ganze Ordnerbäume „abschließen“.

Sicherer Ansatz:

• Prüfen Sie zuerst, ob ein Admin auf NAS-Ebene Dateien sehen kann.
• Dokumentieren Sie die bestehende ACL-Struktur (exportieren, wenn möglich).
• Setzen Sie Rechte nicht flächig neu, bevor Sie wissen, welche Identitäten gemappt werden müssen.

Manchmal ist die Rettung nicht „Daten wiederherstellen“, sondern „Zugriff korrekt wiederherstellen“. Für Betroffene fühlt sich das aber identisch an: Daten weg.

Migrationswege im Vergleich: rsync, SMB-Kopie, Hersteller-Tools

Nicht jede Methode ist gleich fehlertolerant. Und ja: Der Teufel steckt in Details wie Zeitstempeln, Sonderzeichen und Rechten.

• SMB-Kopie per Explorer/Robocopy

- Risiko: Unterbrüche, lange Pfade, Rechte-Übernahme, offene Dateien.

- Tipp: Wenn überhaupt, dann mit sauberer Robocopy-Strategie (Logging, Retry, Ausschlüsse) und einem klaren Cutover.

• rsync

- Risiko: Rechte/ACLs müssen explizit korrekt übertragen werden; je nach NAS kann die Interpretation abweichen.

• Hersteller-Migrationstools

- Risiko: „Black Box“ – wenn’s schiefgeht, ist die Fehleranalyse manchmal zäh.

Wenn Sie gerade mitten im Problem stecken: Entscheidend ist nicht, was „eigentlich best practice“ gewesen wäre, sondern welcher Weg jetzt am wenigsten verändert.

Wenn das neue NAS schon „produktiv“ ist: Schonende Rettung ohne Betriebsstopp

Manchmal ist der Umzug abgeschlossen, die Teams in Lichtenberg oder Köpenick arbeiten schon auf dem neuen System – und erst dann fällt auf, dass ein Teilbestand fehlt.

Dann gilt: Keine Vollbremsung, aber kontrolliert.

• Erstellen Sie, wenn möglich, einen Snapshot des aktuellen Zustands. Das ist Ihr „Rettungsanker“.
• Identifizieren Sie den fehlenden Datenbereich (Projektordner, Zeitraum, Abteilung).
• Arbeiten Sie mit kleinen, verifizierten Rückkopien statt mit „alles nochmal“.
• Prüfen Sie Dateisummen oder Stichproben: nicht nur „Ordnergröße“, sondern echte Dateien öffnen.

Das Ziel ist, die Produktivität zu schützen und trotzdem eine konsistente Datenbasis wiederherzustellen.

Sonderfälle: Verschlüsselte Shares, iSCSI, Docker/VM-Apps

Hier wird’s kurz technischer – aber keine Sorge, wir bleiben praktisch.

• Verschlüsselte Freigaben/Volumes: Ohne Key/Passphrase hilft das beste Kopierlog nichts. Prüfen Sie, ob beim neuen NAS der Schlüsselbund korrekt importiert wurde.
• iSCSI-LUNs: Werden oft als „Dateien“ behandelt, sind aber Block-Storage. Eine falsche Kopie kann inkonsistente Images erzeugen.
• Apps (Docker, Datenbanken, Groupware): Daten liegen nicht nur in einem Ordner. Konfig, Volumes, Berechtigungen und Versionen müssen zusammenpassen.

Wenn genau diese Komponenten betroffen sind, lohnt sich früh eine strukturierte Analyse – sonst reparieren Sie am Ende nur Symptome.

Prävention für den nächsten Umzug (kurz, aber Gold wert)

Damit eine Migration nicht wieder zur Nervenprobe wird:

• Inventar vorher: Shares, Quotas, ACLs, Sonderfälle (iSCSI, Verschlüsselung, Apps).
• Testlauf mit Teilmenge: Ein echtes Pilot-Projekt, nicht nur „ein Ordner“.
• Cutover-Fenster klar kommunizieren: Schreibstopp, wann, wie lange, wer bestätigt.
• Verifikation: Stichproben, Hashes, Logs, Nutzerfreigabe.

Klingt nach Bürokratie – spart aber im Ernstfall Tage.

Wann professionelle Datenrettung sinnvoll ist

Wenn Sie eines der folgenden Zeichen sehen, ist es meist effizienter (und sicherer), Hilfe zu holen:

• Das alte NAS ist noch da, aber Sie trauen sich nicht, es anzufassen – gut so.
• Die Daten scheinen „da“, aber niemand bekommt reproduzierbar Zugriff.
• Snapshots/Versionen sind vorhanden, aber Sie finden den richtigen Stand nicht.
• Es geht um kritische Firmendaten (Buchhaltung, Mandantenakten, Produktion) und jeder Fehlversuch verschärft das Risiko.

Gerade im Raum Berlin – auch wenn Teams verteilt in Brandenburg arbeiten – ist es hilfreich, wenn jemand die Lage vor Ort strukturiert aufnimmt, statt dass fünf Leute gleichzeitig „mal kurz“ etwas probieren.

CTA: Wenn Ihre NAS-Migration gerade Daten „verschluckt“ – lassen Sie uns das sauber entwirren

Sie möchten keine weiteren Experimente, sondern einen klaren Rettungsplan? Dann melden Sie sich bei bizIT. Wir schauen uns Ihren Migrationsweg, Rechte, Snapshots und Volumes an – und sagen Ihnen ehrlich, was realistisch ist und wie Sie wieder zu konsistenten Daten kommen.

bizIT

Heidelberger Str. 64a , 12435 Berlin

Telefon: +49 30 588008800

Website: https://www.bizit.de/