Δфلהไ – Sonderzeichen bereiten Probleme bei Migrationen

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.

Anzeige

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.

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

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.

Kollision mit Fehlkonfiguration dynamigs

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

Fazit: Nur Expertise aus hunderten von Migrationen kann helfen

Die Migration unstrukturierter Daten ist an sich eine komplexe Aufgabe mit vielen Fallstricken, die eine 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, kommen 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 für Teile des Projektes engagieren. Diese Spezialisten bauen auf ihre jahrzehntelange Expertise und können Schwierigkeiten schon vor der eigentlichen Migration erkennen.

Draeger Ralf

dynaMigs.net -

Gründer

Ralf Draeger ist einer der vier Gründer von dynaMigs.net und seit 1988 in der IT-Branche tätig. Als technischer Leiter ist er für das Solution-Design und die Administration großer NAS-, SAN- und Cloud-Umgebungen verantwortlich. Vor dynaMigs war er sieben Jahre im Bereich der Programmierung tätig, fünf weitere als Systemadministrator (Unix/Windows)
Anzeige

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.