Datenmigrationen sind in vielen Unternehmen eine unterschätzte Pflichtaufgabe. Die Führungsebene nimmt diese Projekte als Fleißaufgabe wahr und unterschätzt die notwendige Erfahrung, das Fachwissen und den Bedarf an speziellen Lösungen, um Migrationen erfolgreich umzusetzen. Dabei erweisen sich immer komplexere Systeme als ein wahres Minenfeld, bei dem jeder einzelne Schritt genau geplant und bedacht sein will. Denn Probleme und daraus resultierende Fehler stecken oft im Detail: Selbst banale Sonderzeichen in Dateinamen können Migrationen scheitern lassen. Um diese Problematik zu verstehen, hilft ein Blick in die Evolution der Zeichensätze, vom Mainframe bis hin zur heutigen Generation moderner Rechner.

Die Evolution der Zeichensätze

Zu Mainframe-Zeiten waren über ASCII gerade einmal 127 Zeichen verfügbar. Weit verbreitete Umlaute einiger auf römischem Alphabet aufbauenden europäischen Sprachen hielten dann mit ANSI/437 (DOS/Alte Unix Systeme) Einzug. So verfügte man immerhin schon über 255 Zeichen. Noch internationaler wurde es dann mit ISO8859-X (Windows 3.1 - Windows 98 / Windows NT 3.5), das fünfzehn verschiedene Zeichensätze umfasste, bei denen die herkömmlichen Buchstaben und Zahlen in allen Varianten identisch waren, die zweite Hälfte jedoch jeweils Sonderzeichen aus verschiedenen Sprachkreisen enthielt. So ließen sich nicht nur die westeuropäischen Sprachen darstellen, sondern auch andere Alphabete wie beispielsweise Griechisch, Thai oder Japanisch. Der größte Durchbruch, Zeichen darzustellen, gelang dann mit UTF-8 / Unicode (Windows NT 4.0 und höher / Unix / NAS), das Zeichen mit ein bis vier Bytes darstellt. Seitdem stehen mehr als eine Million Zeichen bereit.

Zu Anfang der Vernetzung wurden Daten erzeugt, die im Laufe der Zeit auf neue Generationen von File-Servern migriert wurden. Auf dem Weg bis zum heutigen UTF-8 ist mit diesen Daten somit erwartungsgemäß einiges Spannendes geschehen. Alte DOS- oder Windows-Versionen verwenden ANSI oder ISO 8859-X. Dies stellt in der Regel kein Problem dar, da die Umlauteinstellung bei der Netzwerkverbindung ausgehandelt wird. Dies gilt hauptsächlich für Steuerrechner für Produktionsroboter, wo zumeist auch keine Umlaute vorkommen. Auch bei modernen Windows-Versionen gibt es seltener Probleme, weil diese für jede Applikation durchgehend Unicode verwenden.

Babylonische Sprachenverwirrung

Ein hexadezimaler Wert kann beispielsweise auf unterschiedlichen Rechnern unterschiedliche Buchstaben darstellen. Ein Rechner, der als ISO 8859-1, also für westlich lateinische Schriftzeichen, konfiguriert war, schrieb auf dem Fileserver ein "ä" (hex E4). Wurde diese Datei später von einem Rechner unter ISO 8859-7, also mit griechischen Schriftzeichen gelesen, wurde der gleiche Hex-Wert E4 als "d" interpretiert und dargestellt. Wird diese Datei aber dann beispielsweise von einem Rechner mit ISO 8859-7 mit Konversion unter UTF-8 auf ein neues Ziel geschrieben, verschwindet das ursprüngliche "ä" vollkommen, weil E4 in Unicode keinen gültigen Buchstaben repräsentiert. Aus diesem Grund kann es vorkommen, dass gegebene Dateinamen aufgrund verschiedener Zeichensätze verfälscht werden. Im schlimmsten Fall sind diese Dateinamen dann für andere Rechner sogar unlesbar. Von dieser Problematik sind circa 400 Sonderzeichen aus unterschiedlichen Sprachkreisen betroffen.

Das Problem lässt sich bei Migrationen tatsächlich kaum umgehen. Ein automatisches Konvertieren von NFSv3 auf NFSv4, das immer in UTF8 arbeitet, ist kaum möglich, oder zumindest nur nach genauer Analyse des Datenbestandes. Zusätzlich müssen für eine Konvertierung die Dateien Host-basiert, also jede Datei für sich, kopiert werden, was eine deutlich längere Offline-Zeit erfordert.

Unix-Clients können verschiedene Protokolle nutzen

Über das potenzielle Verfälschen von Dateinamen hinaus gibt es ein weiteres Problem, das mit den verschiedenen Protokollen auf Unix-Clients zusammenhängt. So arbeitet das heutige Windows schon seit mehr als einem Jahrzehnt nur noch mit Unicode. Das bedeutet, dass ein zu übertragender Dateiname im SMB-Protokoll über Unicode darzustellen ist. Vorhandene Dateinamen lassen sich daher nicht übertragen und müssen schon vorher in Unicode konvertiert worden sein. Unter NFSv4 kommt es dabei nicht auf den Client an, weil NFSv4 den Client zwingt, den Dateinamen in UTF8 zu übertragen. So sprechen sowohl Client als auch File-Server die gleiche Sprache und es kann nicht mehr viel schiefgehen.

Dies ist allerdings erst seit NFSv4 so. Unter NFSv3 herrschen dagegen noch völlig ungeordnete Verhältnisse, weil Nutzer bei einem Unix-Client je nach Terminal verschiedene Codepages nutzen können - und damit Dateinamen mit unterschiedlichen Codierungen auf ein und demselben Fileserver schreiben. Die Gefahr ist daher groß, dass im Directory zwei unterschiedliche Dateien mit scheinbar identischen Dateinamen vorkommen: beide vom gleichen Client geschrieben, jedoch aus unterschiedlichen Terminals und mit verschiedenen Codepages.

Protokoll-Chaos unter NFSv3

Als zusätzliches Problem kommt hinzu, dass beim Nutzen eines File-Servers, der Multiprotokoll anbietet, invalide UTF-8-Sequenzen entstehen können. Ein Beispiel: Ein Unix-Client mit NFSv3 ist mit UTF-8 konfiguriert und vergibt einen Dateinamen, der ein "ä" enthält, etwa "Report_März.txt". Wird dieser auf ein NAS geschrieben, welches eine Codierung in ISO-8859-1 erwartet, interpretiert dieses den Namen beim Konvertieren in UTF-8 jedoch falsch. Zwar würde jeder andere Unix-Client mit NFSv3 trotz dieser Fehlkonfiguration auch "Report_März.txt" lesen. Ein mit NFSv4 konfigurierter Client würde jedoch "Report_März.txt" lesen. Die Datei ist in diesem Fall zwar nicht korrupt und kann weiterhin gelesen werden. Würde man nach einer Migration auf dem neuen Server nach dem "Report_März" suchen, könnte ein Anwender diese aber über die Suchfunktion eines Windows-Rechners kaum finden, weil sie unter diesem korrekten Dateinamen nicht mehr existiert.

Der Versuch, solche Dateinamen zu reparieren, mündet schnell in ein munteres Ratespiel. So kann man in der Regel nicht mehr nachvollziehen, wann und warum der Dateiname beim Konvertieren falsch interpretiert wurde. Bei Migrationen lassen sich Dateien zumindest gewissen Unternehmensbereichen und den dort genutzten Protokollen zuordnen. Für deutsche Standorte ist es beispielsweise naheliegend, dass Dateien mit ISO 8859-1 erstellt wurden. Auch lässt sich überprüfen, ob auf dem Fileserver die Konvertierung eingeschaltet war. So kann man zumindest das Verhalten nachvollziehen und nach entsprechende Fehlkonfigurationen suchen.

Weiß man anhand der Einstellungen am Fileserver beim Planen einer Migration, dass potenzielle Fehler beim Konvertieren von Dateinamen vorkommen können, dann lassen sich diese über einen Algorithmus zur Verifikation aufdecken. Die als fehleranfällig identifizierten Dateien sind anschließend jedoch manuell auf der Quelle umzubenennen. Prinzipiell sollten die Verantwortlichen bei einer Migration im Vorfeld erkannte Umlautproblematiken bereits quellseitig bereinigen. Dies ermöglicht anschließend eine saubere Migration ohne Fehler in den Logfiles.

Professionelle Analyse, Planung und Umsetzung erforderlich

Die Migration unstrukturierter Daten ist an sich eine komplexe Aufgabe mit vielen Fallstricken, die professionelle Analyse, Planung und Umsetzung erfordert. Datenbestände auf einem NAS sind meist historisch gewachsen und wurden mit unterschiedlichen Protokollen geschrieben oder konvertiert. Insbesondere Sonderzeichen, wie die im deutschen Sprachraum üblichen Umlaute, bereiten hier oft Probleme. Dateinamen korrekt darzustellen. Dies kann auch bei Unix-Umgebungen vorkommen, wenn Dateien von ein und demselben Client mit unterschiedlichen Protokollen geschrieben wurden. Ganz zu schweigen von der Problematik, dass unter NFSv3 mit Multiprotokoll komplett invalide Dateinamen entstehen können.

Ohne das Wissen und die Erfahrung, wo welche Probleme auftreten können, stoßen viele IT-Teams schnell an ihre Grenzen. Unternehmen, die größere Migrationsprojekte planen, sollten sich im Vorfeld Rat bei Daten- und Migrationsexperten einholen oder diese in das Projekt einbeziehen. Dank oft jahrzehntelanger Expertise können diese Schwierigkeiten schon vor der eigentlichen Migration erkennen. (mb)