… ᎴaᏕ ᎶᎥᏰᏖ ÄᏒᎶᏋᏒ! – Sonderzeichen bereiten Probleme bei der Datenmigration

Datenmigrationen sind in vie­len Un­ter­neh­men ei­ne un­ter­schätz­te Pflicht­auf­ga­be. Häu­fig fehlt es in der Pra­xis schluss­end­lich an der not­wen­di­gen Er­fah­rung, dem ge­eig­ne­ten Fach­wis­sen oder spe­zi­el­len Mi­gra­ti­ons­lö­sun­gen und Tools. Da­bei er­wei­sen sich im­mer kom­ple­xe­re Spei­cher­sys­te­me als ein wah­res Mi­nen­feld, bei dem je­der ein­zel­ne Schritt ge­nau ge­plant und be­dacht sein will. Denn Pro­ble­me und dar­aus re­sul­tie­ren­de Feh­ler ste­cken oft im De­tail: Selbst banale Sonderzeichen in Dateinamen können Migrationen scheitern lassen.

von Ralf Draeger, Technischer Leiter bei dynaMigs.net

Die Evolution von Dateinamen sorgt für Probleme

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.

Autor Ralf Draeger, dynaMigs.net

Ralf Draeger ist einer der vier Gründer von dynaMigs.net (Webseite) und seit 1988 in der IT-Bran­che tä­tig. Als tech­ni­scher Lei­ter ist er für das So­lu­ti­on-De­sign und die Ad­mi­nis­tra­ti­on gro­ßer NAS-, SAN- und Cloud-Um­ge­bun­gen ver­ant­wort­lich. Vor dy­na­Migs war er sie­ben Jah­re im Be­reich der Pro­gram­mie­rung tä­tig, fünf wei­te­re als Sys­tem­ad­mi­nis­tra­tor (Unix/Win­dows) und 20 Jah­re im Con­sul­ting und der Im­ple­men­ta­ti­on im NAS-Um­feld. Da­bei war er haupt­säch­lich ver­ant­wort­lich für EMC Ce­ler­ra und VNX. Im Ver­lauf sei­ner Kar­rie­re war Dra­e­ger als Se­ni­or NAS-So­lu­ti­on-Ar­chi­tect und Im­ple­men­ta­ti­on-Spe­cia­list für na­m­haf­te Au­to­mo­bil­her­stel­ler, Ban­ken, Ver­si­che­run­gen, IT-Dienst­leis­ter und öf­fent­li­che In­sti­tu­tio­nen zuständig.

Das Pro­blem lässt sich bei Mi­gra­tio­nen tat­säch­lich kaum um­ge­hen. Ein au­to­ma­ti­sches Kon­ver­tie­ren von NFS­v3 auf NFS­v4, das im­mer in UT­F8 ar­bei­tet, ist kaum mög­lich, oder zu­min­dest nur nach ge­nau­er Ana­ly­se des Da­ten­be­stan­des. Zu­sätz­lich müs­sen für ei­ne Kon­ver­tie­rung die Da­tei­en host­ba­siert, al­so je­de Da­tei für sich, ko­piert wer­den, was ei­ne deut­lich län­ge­re Off­line-Zzeit erfordert.

Protokoll-Chaos unter NFSv3

Die Ver­fäl­schung von Dateinamen bei Mi­gra­tio­nen ist je­doch längst nicht das ein­zi­ge Pro­blem. Beim Nut­zen von File-Ser­vern mit Mul­ti­pro­to­koll kön­nen bei­spiels­wei­se in­va­li­de UTF-8-Se­quen­zen ent­ste­hen. Ein Bei­spiel: Ein Unix-Cli­ent mit NFS­v3 ist mit UTF-8 kon­fi­gu­riert und ver­gibt ei­nen Da­tei­na­men, der ein „ä“ ent­hält, et­wa „Re­port_März.tx­t“. Wird die­ser auf ein NAS ge­schrie­ben, wel­ches ei­ne Co­die­rung in ISO-8859-1 er­war­tet, in­ter­pre­tiert die­ses den Na­men beim Kon­ver­tie­ren in UTF-8 je­doch falsch. Zwar wür­de je­der an­de­re Unix-Cli­ent mit NFS­v3 trotz die­ser Fehl­kon­fi­gu­ra­ti­on auch „Re­port_März.tx­t“ le­sen. Ein mit NFS­v4 kon­fi­gu­rier­ter Cli­ent wür­de je­doch „Re­port_März.tx­t“ le­sen. Die Da­tei ist in die­sem Fall zwar nicht kor­rupt und kann wei­ter­hin ge­le­sen wer­den. Wür­de man nach ei­ner Mi­gra­ti­on auf dem neu­en Ser­ver nach dem „Re­port_Mär­z“ su­chen, könn­te ein An­wen­der die­se aber über die Such­funk­ti­on ei­nes Win­dows-Rech­ners kaum fin­den, weil sie un­ter die­sem kor­rek­ten 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.”

Fazit: Nur Expertise aus hunderten von Migrationen kann helfen

Die Mi­gra­ti­on un­struk­tu­rier­ter Da­ten ist an sich ei­ne kom­ple­xe Auf­ga­be mit vie­len Fall­stri­cken, die ei­ne pro­fes­sio­nel­le Ana­ly­se, Pla­nung und Um­set­zung er­for­dert. Da­ten­be­stän­de auf ei­nem NAS sind meist his­to­risch ge­wach­sen und wur­den mit un­ter­schied­li­chen Pro­to­kol­len ge­schrie­ben oder kon­ver­tiert. Ins­be­son­de­re Son­der­zei­chen wie die im deut­schen Sprach­raum üb­li­chen Um­lau­te be­rei­ten hier oft Pro­ble­me, Da­tei­na­men kor­rekt dar­zu­stel­len. Dies kann auch bei Unix-Um­ge­bun­gen vor­kom­men, wenn Da­tei­en von ein und dem­sel­ben Cli­ent mit un­ter­schied­li­chen Pro­to­kol­len ge­schrie­ben wur­den. Ganz zu schwei­gen von der Pro­ble­ma­tik, dass un­ter NFS­v3 mit Mul­ti­pro­to­koll kom­plett in­va­li­de Da­tei­na­men ent­ste­hen 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.Ralf Draeger, dynaMigs.net

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/130358

• teilen 
• teilen 
• teilen 
• teilen 
• teilen 
• RSS-feed 
• E-Mail 
• drucken