Du er her: Hjem --> Annet --> bits & bytes --> Datamigrering

Datamigrering

Datamigrering vil si å flytte (kopiere) data fra ett system til et annet. Datamigrering gjøres typisk når et firma skal oppdatere datautstyet. For eksempel gå over til ny filserver eller ny databaseserver.

Ved all datamigrering vil man ha oppdaterte backuper før man starter. I tilfelle noe går galt. Mye data skal kopieres på en gang og da er det alltid en risiko for at en harddisk krasjer.

I det følgende vil vi se på migrering av data fra eksisterende til ny filserver.

Enkel datamigrering

En enkel datamigrering er når data kopieres over uendret fra gammelt til nytt system. psdigital har et egenprodusert bash-script for å gjøre dette, psmig.sh. Scriptet kan kjøre enten på kildesystemet eller målsystemet. Vanligvis kjører vi det på kildesystemet.

Selve kopijobben utføres av kommandoen/programmet rsync. Resten av scriptet er stort sett konfigurering av rsync-parametre og mekanismer for logging og feilsjekking. Scriptet må konfigureres med detaljer rundt kildesystem og målsystem (ip-adressen til målserveren, hvilke kataloger som skal kopieres fra kildesystemet og hvor de skal ende på målsystemet etc).

rsync-kallet er på følgende form, der det kan itereres over mange subdir:
rsync -rlptgoD -h --stats --log-file=$logf --password-file $pwf $fromdir/$subdir $1@$tosrv::$module

Når skriptet kjøres ønsker vi helst at kildesystem og målsystem er lokalisert på samme nettverk. Dvs fysisk så står både gammel og ny server på kontoret. Da er ikke sikkerhet noe man må ta mye hensyn til, og man kan kopiere data ukryptert. Det gjør at det hele går fortere. Vi benytter rsync daemon protokollen for dataoverføring. rsync er innebygd i Mac og Linux. På PC kan man få rsync med cygwin. På Windows 10 maskiner kan man også få rsync med et UNIX subsystem som følger med operativsystemet. Dersom man på forhånd konfigurerer brukere på målsystemet med samme navn som på kildesystemet kan rsync gi stort sett identiske fil- og katalogrettigheter på målsystemet som på kildesystemet.

Når script og overførelsesprotokoll er konfigurert riktig gjør man først noen testkjøringer på mindre datamengder, for å se at alt blir kopiert riktig over. Deretter kan man sette på hovedjobben - kopiering av alle data. Hvor lang tid dette tar er avhengig av hvor mye data det er, og nettverkshastigheten (vanligvis 1 gigabit/sekund). Det kan også variere med katalogstrukturen på kildesystemet, for eksempel antall tomme kataloger.

Avansert datamigrering

Avansert datamigrering er når dataene editeres samtidig som man flytter til nytt system.

Ved flytting til ny databaseserver kan det hende at det ikke er identiske tabeller på målsystemet. Da må man til med et fullstendig program (i Java?) for å konvertere dataene riktig inn i nye tabeller. På gammelt system var det kanskje ett felt for "Navn", mens på nytt system er det tre felt, "Fornavn", "Mellomnavn" og "Etternavn".

I dette eksempelet skal vi se på flytting til ny filserver, og vi vil underveis gjøre en modifisering av filnavnene. Dette kan være aktuelt dersom man på kildesystemet har benyttet filnavn med ukurante tegn, eksempelvis / (slash), . (punktum), , (komma), * (asterisk), ' (fnutt), " (dobbelfnutt), med flere. Gjør man ikke en modifisering av filnavnene kan man få feil på målsystemet dersom reglene for lovlige karakterer er forskjellig på kildesystem og målsystem. Ved migrering mellom to forskjellige operativsystemer, eksempelvis fra Mac server til Windows server, eller fra Mac server til Synology, kan dette fort bli tilfellet.

Et generelt tips er å kun bruke a-z, A-Z, 0-9 i filnavn. Og bruke - (minus, liten bindestrek) eller _ (underscore) istedenfor space (mellomrom).

Ekstern harddisk FAT32 ulovlige tegn i filnavn

Fig. 1 Synology-GUI for formattering av tilkoplet ekstern harddisk (USB). Det gis informasjon om ulovlige karakterer i filnavnet på et FAT32 volum.

NTFS-volum på Windows 10, ulovlige tegn i filnavn

Fig. 2 File Explorer, NTFS-volum på en Windows 10 maskin. Det gis informasjon om ulovlige karakterer i filnavnet på et slikt volum når man forsøker sette inn et slikt tegn i filnavnet. Jmf bildet ovenfor - det ser ut til å være de samme reglene for FAT32 og NTFS når det gjelder hvilke tegn som er ulovlige i filnavn. Disse reglene er forskjellige fra det som gjelder for en Mac, som gjerne bruker filsystemet HFS+. Her kan man skrive inn de fleste av de viste ulovlige tegnene uten at man får feilmelding. Det betyr igjen at dersom man migrerer filer fra en Mac til en Windows maskin kan det bli problemer dersom filnavn inneholder tegn som er lovlige på Mac, men ulovlige på Windows.

Oppgaven

Oppgaven er å migrere data fra en Macmini med ServerApp til en Synology. Følgende punkter må tilfredsstilles:

Programmeringsspråk

Vi valgte å lage migreringssoftware i bash-script og C-kode. Bash-scriptet kaller systemfunksjoner og vår egen C-kode.

Algoritme

Vi valgte å dele opp oppgaven i 3 skritt, som utføres i sekvens. Vi lagde et hovedscript psefn.sh (efn = edit file name), som tar 1 eller flere inputparametre. Første inputparameter er et tall 1, 2 eller 3, og dette avgjør om det er skritt 1, 2 eller 3 vi vil utføre. De 3 skrittene, kallet og beskrivelse:

  1. ./psefn.sh 1 &
    Analyse av katalognavn og filnavn på eksisterende server. Med find og xargs går vi igjennom hele filtreet. Hver katalognavnstreng sendes som inputargument til et C-program, som analyserer strengen for ulovlige tegn og gjør eventuell substitusjon. Vi gjør det samme for filnavnene. Følgende tekstfiler produseres:
    • dirorg.txt: Alle originale katalognavn.
    • dirnew.txt: Alle editerte katalognavn.
    • fileorg.txt: Alle originale filnavn.
    • filenew.txt: Alle editerte filnavn.
    I bash: vi editerer hver hver linje i dirnew.txt slik at hver linje får riktig sti i forhold til ny server. Videre editeres hver linje slik at istedenfor en opplisting av katalognavn inneholder filen kommandoene for å lage katalogene på den nye serveren. Resultatet skrives til en ny fil, dircmd.txt. Eksempel på hvordan en linje vil endres:
    • dirorg.txt: /Macintosh HD/%filer%/firmanavn/mitt prosjekt/Sverige og Åland/
    • dirnew.txt: /Macintosh-HD/filer/firmanavn/mitt-prosjekt/Sverige-og-AAland/
    • dircmd.txt: mkdir -p /Volume1/firmanavn/mitt-prosjekt/Sverige-og-AAland/;
    I bash: vi lager en ny fil filewpath.txt fra filenew.txt. Filstien endres slik at første del av stien blir riktig i forhold til ny server. Og i forhold til rsync daemon modulen. Eksempel på hvordan en linje vil endres:
    • fileorg.txt: /Macintosh HD/%filer%/firmanavn/mitt prosjekt/Sverige og Åland/første prosjekt.obj
    • filenew.txt: /Macintosh-HD/filer/firmanavn/mitt-prosjekt/Sverige-og-AAland/forste-prosjekt.obj
    • filewpath.txt: /mitt-prosjekt/Sverige-og-AAland/forste-prosjekt.obj. Her er rsync daemon modulen satt til /Volume1/firmanavn.
    Filene vi har laget i skritt 1 vil vi bruke i de neste skrittene. Før vi setter igang skritt 2 tar vi en manuell titt på filene og ser at alt ser riktig ut.
  2. ./psefn.sh 2 ssh-user-name
    Før vi kopierer filene må vi lage katalogene på den nye serveren. I psefn.sh gjøres dette ved å kjøre kommandoene i dircmd.txt på den nye serveren, over ssh:
    • ssh $2@ip-adresse-ny-server <dircmd.txt
    Den andre parameteren i kallet er navnet på en Administrator-bruker. Du vil bli bedt om å oppgi ssh-passordet. Derfor kan dette skrittet ikke kjøres i bakgrunnen (dropper &).
    Det går også an å kopiere dircmd.txt over til ny server og kjøre kommandoene der, så man slipper å gjøre det over ssh.
    Etter skritt 2 er katalogstrukturen etablert på målserveren.
  3. ./psefn.sh 3 rsync-daemon-user-name &
    Nå skal vi kopiere filene. Dette gjøres med rsync daemon, et kall for hver fil. Vi itererer over de to filene fileorg.txt og filewpath.txt, der korresponderende linjer i de to filene angir en fil på kildesystemet, og en path og filnavn på målsystemet. Linjen i fileorg.txt leses inn i variabelen sourcefile, linjen i filewpath.txt leses inn i targetfile. rsync-kallet ser noe slikt ut:
    • rsync -rlptgoD -h --log-file "$flog3" --password-file "$fpw" "$sourcefile" $2@$ipto::$module$targetfile
    Legg merke til formatet på kallet der variablen module inneholder første del av stien på målsystemet. Vi har med denne fordi rsync daemon konfigureres med en modul i rsyncd.config filen på målsystemet (på Synology lokalisert i /etc/ katalogen).

bash-kode

Det var en stor fordel å kunne skrive dette programmet i bash, fordi oppgaven tilsier at man vil bruke mange av funksjonene som følger med UNIX, som enkelt lar seg kalle fra bash. Dermed tok det ikke så lang tid å lage programmet, i underkant av 2 uker. Hovedtrekkene i bash-koden er beskrevet ovenfor.

Iterering over hele katalogstrukturen med find og xargs, der vi kaller C-programmet pseditn med 5 parametre - 4 filnavn og resultatet av find:
find $fromdir -type d -print0 | xargs -0 -n1 ./pseditn $f01 $f02 $f07 $f08

De 4 filene er: for lagring av originale katalognavn, for lagring av editerte katalognavn, fil med ulovlige substrenger og tilhørende substitusjonsstrenger, logfil.

Iterering over en fil f04, lese hver linje inn i en variable, editere denne og skrive resultatet til en ny fil f06:
while IFS='' read -r line || [[ -n "$line" ]]; do
  foo=${line/$oldprefix/$fnewprefix}
  echo $foo >> $f06
done < $f04

Iterering over to filer f03 og f06, lese inn en linje fra hver fil i to variable p og q, og kalle rsync:
while IFS='' read -r -u 10 p || [[ -n "$p" ]]; do
  IFS='' read -r -u 11 q
  rsync -rlptgoD -h --log-file=$logf3 --password-file "$rswf" "$p" $2@$ipto::$module$q
  strs=$?
  if [ $strs -eq 0 ] ; then
    echo rsync run OK. >> $logf3
  else
    echo ----------rsync run ERROR---------->> $logf3
  fi
done 10<$f03 11<$f06

Koden ovenfor har også feilsjekking. Exit-koden fra rsync-kallet leses inn i variabelen strs. Hvis denne er forskjellig fra 0 har rsync feilet.

C-kode

Som beskrevet ovenfor kalles et C-program pseditn med en katalognavnstreng som parameter. Programmet analyserer strengen for ulovlige tegn og skriver originalstrengen og editert streng til fil.

En input-fil pssubs.txt inneholder hvilke tegn som er ulovlige, og hva hvert ulovlig tegn skal erstattes med. Filen er på formatet:
ulovlig-substreng1
substitusjons-substreng1
ulovlig-subtegn2
substitusjons-substreng2
...
...

Et eksempel på en slik fil:
##
00
/
-
?
-
%
-

Her skal ## erstattes med 00, / skal erstattes med - og ? skal erstattes med -.

Programmet leser to og to linjer fra filen, og sjekker katalognavnstrengen for forekomster av den ulovlige strengen. Alle forekomster av den ulovlige strengen i katalognavnstrengen substitureres med den tilhørende substitusjonsstrengen.

For å få til dette lagde vi en C-funksjon fsub som returnerte posisjonen til første forekomst av substreng i en streng, -1 hvis det ikke var match. Og en funksjon newstr som kaller fsub og produserer substitusjonsstrengen - strengen med bare lovlige tegn.

Tilslutt i pseditn sjekker vi for mulige uønsketheter som substitusjonen kan føre til, eksempelvis dobbel minus (kort bindestrek) kan fort forekomme dersom mange ulovlige tegn skal erstattes med minus.

Vi måtte også lage en C-funksjon lsub som returnerte posisjonen til siste forekomst av substreng i en streng, -1 hvis det ikke var match.

C-koden ble kompilert på en Macmini med:
cc -o pseditn pseditn.c psstr.c

Eksempelkjøring1

Et kataloghierarki med 8028 kataloger og 53639 filer. Total størrelse 142 gigabyte (dvs 1 136 000 megabit). Kontornettverket er et gigabit nettverk der filer vanligvis overføres med hastigheter opp mot 1 gigabit/sekund.

Skritt 1 og 2 tok mye mindre tid enn skritt 3. Ikke så overraskende.

Skritt 3: overføringshastigheten ble 1 136 000 megabit / 9 505 sekunder = 120 megabit/sekund. Et gigabit nettverk skal kunne overføre 1 gigabit/sekund, eller med andre ord, 1000 megabit/sekund. Så vi har her ikke oppnådd gigabit nettverkshastighet. Uklart hvorfor. Kjøringen ble gjort remote over SSH, kanskje det har noe å si.

Feilkilder

Overskrivning og datatap ved identiske filnavn

Dersom to filer i samme katalog har omtrent samme navn i utgangspunktet, er det mulig at navnene blir identiske etter at de er editert. Resultatet blir da at en av filene overskrives og at data tapes. Anta følgende to filer i samme katalog:

hei-hei.txt
hei?hei.txt

Etter editering vil begge filene på den nye filserveren bli hetende

hei-hei.txt

Den første av de to som kopieres med rsync vil bli overskrevet når den siste kopieres. Vi mister altså den første filen - rett og slett et datatap. Denne feilen logges heller ikke, så det er ganske umulig å oppdage. IKKE BRA.

Det er mulig dette kan rettes med rsync-parameteren --ignore-existing.

Filer i forskjellige kataloger på kildesystemet havner i samme katalog på målsystemet ved identiske katalognavn

Noe annet skjer dersom to kataloger ender opp med identisk navn etter editering. Programmet lager først tomme kataloger. Dersom to kataloger har fått samme navn etter editering vil programmet forsøke å lage denne katalogen to ganger. Det vil sannsynligvis ikke skje noe, eller det kommer en feilmelding som ikke fanges opp. Resultatet vil være en katalog mindre på målsystemet enn på kildesysmet. Når vi så etterpå kopierer filene med rsync vil filer som på kildesystemet var i to forskjellige kataloger, havne i samme katalog. Anta følgende to kataloger på kildesystemet:

/Macintosh HD/%filer%/firmanavn/mitt prosjekt/Danmark?Tyskland/
/Macintosh HD/%filer%/firmanavn/mitt prosjekt/Danmark-Tyskland/

Etter korrigering av filnavn vil disse bli til:

/Macintosh HD/filer/firmanavn/mitt-prosjekt/Danmark-Tyskland/
/Macintosh HD/filer/firmanavn/mitt-prosjekt/Danmark-Tyskland/

Vi ser at de to katalogene har identisk navn. Når programmet lager denne katalogen for andre gang vil det sannsynligvis ikke skje noe, eller vi får en feilmelding som ikke fanges opp. Når vi skal kopiere filer fra gammelt system til nytt system vil alle filene fra /Danmark?Tyskland/ og fra /Danmark-Tyskland/ havne i samme katalog på ny filserver, /Danmark-Tyskland/. Vi får ikke et datatap, men uventet plassering av noen filer.

Her oppstår uregelmessigheten høyere opp i hierarkiet:

/Macintosh HD/%filer%/firmanavn/mitt prosjekt/Prosjekt00/Norge/Oslo/
/Macintosh HD/%filer%/firmanavn/mitt prosjekt/Prosjekt##/Norge/Oslo/

Etter korrigering av filnavn vil vi ha:

/Macintosh-HD/filer/firmanavn/mitt-prosjekt/Prosjekt00/Norge/Oslo/
/Macintosh-HD/filer/firmanavn/mitt-prosjekt/Prosjekt00/Norge/Oslo/

Det samme vil skje her - filer i de to katalogene på kildesystemet vil havne i samme katalog på målsystemet.

Loggmekanisme

Det er en mekanisme som logger hver gang programmet finner et ulovlig tegn i et katalognavn eller filnavn. Selve tegnet blir skrevet til en egene fil (to separate filer, en for katalognavn og en for filnavn, dirlog.txt og filelog.txt). Hensikten er å få en oversikt over datahierarkiet - hvor mange ulovlige tegn det var, og hvilke. Denne sjekken var vanskelig å tolke - enten bør den fjernes eller så bør det lages egen kode for å tolke disse loggfilen.

Programfilene

Filene for å kjøre programmet:

Filene programmet lager:

Konklusjon

Dette konverteringsprogrammet ble laget på relativt kort tid, noe som var et kriterie. Jobben besto i migrering av rundt 600 gigabyte med data, og over 100 000 filer og kataloger. For så mange filer og kataloger er det umulig å manuelt sjekke at alt er kommet med, at det ikke er noen feil. Det er derfor viktig at vi gjør maskinell feilsjekking, for eksempel ved at migreringsprogrammet har innebygget slike mekanismer. Maskinelt uoppdagete feil vil typisk bli oppdaget av brukerne etter dager, uker, måneder. Derfor er det viktig at kildesystemet ikke slettes, men er tilgjengelig i en god periode etter en slik jobb, for eksempel et år eller to.

En måned etter migrering er ingen feil oppdaget. Så det tyder godt.

Referanser

  1. Kernighan/Ritchie: The C Programming language
  2. Diverse internettressurser rundt C, bash, Unicode og SSH
Telefon: 67 20 71 21 / 92 60 51 57 Fugler som migrerer