Thought Leadership
Datenmigrationen sind in vielen Unternehmen eine unterschätzte Pflichtaufgabe. Häufig fehlt es in der Praxis schlussendlich an der notwendigen Erfahrung, dem geeigneten Fachwissen oder speziellen Migrationslösungen und Tools.
Dabei erweisen sich immer komplexere Speichersysteme 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.
Die Evolution von Dateinamen kann für Probleme sorgen
Das Problem beruht auf der Evolution der Zeichensätze von ASCII zu Mainframe-Zeiten bis hin zum heute gebräuchlichen UTF-8, das seit Windows NT 4.0, unter Unix und auf NAS zu Einsatz kommt. Konnte ASCII gerade einmal 127 Zeichen darstellen, stellt UTF-8 mehr als eine Millionen Zeichen bereit. Mit Daten, die unter einem älteren Zeichensatz erstellt und später migriert wurden, kann während dieser Migrationen unter Umständen einiges passiert sein.
Aus „ä” wird mitunter ein griechisches „δ“
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 griechisches Delta „δ“ interpretiert und dargestellt. Wird diese Datei aber dann beispielsweise von einem Rechner mit ISO 8859-7 mit Konversion unter UTF-8 via NFS auf ein neues Ziel geschrieben, verschwindet das ursprüngliche „ä“ vollkommen, weil E4 in Unicode keinen gültigen Buchstaben repräsentiert oder es bei korrekter Konvertierung als „δ“ (0xCE94). 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 hostbasiert, also jede Datei für sich, kopiert werden, was eine deutlich längere Offlinezeit erfordert.
Protokoll-Chaos unter NFSv3
Die Verfälschung von Dateinamen bei Migrationen ist jedoch längst nicht das einzige Problem. Beim Nutzen von File-Servern mit Multiprotokoll können beispielsweise invalide UTF-8-Sequenzen entstehen. 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 einem munteren Ratespiel, da man natürlich nicht mehr nachvollziehen kann, wann und warum der Dateiname beim Konvertieren falsch interpretiert wurde.
Bei Migrationen von File-Servern mit Multiprotokoll können invalide UTF-8-Sequenzen entstehen. So kann etwa der Dateiname „Report_März.txt“ in „Report_März.txt“ umgewandelt werden – und ist anschliessend nicht mehr über die Suche zu finden. Bildquelle: dynaMigs
