Filserveroverførsler med Robocopy Del 1 af 2
Denne blog er del 1 af en serie på 2 dele. Hvis du vil se del 2, skal du klikke her.
Med forskellige varianter af Windows Server-operativsystemer, der går ud af support i år, har jeg fundet mig selv med et anstændigt antal filservermigrationer fra et system til et andet. Nogle gange, hvis serveren ikke har andre roller eller funktioner installeret end blot en filserver, så kunne jeg simpelthen fjerne delingen af aktierne på den oprindelige server, løsne den virtuelle harddisk fra den, vedhæfte den virtuelle harddisk til den nye server og dele aktierne igen. Dette opretholder NTFS-tilladelser, hvis begge servere er medlemmer af det samme Active Directory-domæne. Det er også generelt meget hurtigt, da der ikke er behov for at kopiere terabytes af data fra den ene server til den anden. Denne proces fungerer dog kun elegant, når fildelingsdataene findes på et volumen, der ikke er der, hvor Windows eller nogen programmer er installeret.
Når behovet opstår for at duplikere dataene til migreringen til den nye server, vender jeg altid tilbage til den gamle trofaste-Robocopy (Robust File Copy for Windows). Robocopy har eksisteret siden NT4-dagene i 1996, så det er nok ikke første gang, du hører om det. Dengang og indtil 2008 var det tilgængeligt sammen med Windows Resource Kit download. Fra 2008 (og derefter) blev det leveret sammen med både desktop- og serveroperativsystemer fra og med Vista og Server 2008. Så hvis du starter en kommandoprompt på din computer og skriver “robocopy /?”, er der gode chancer for at se hjælpedumpet med oplysninger til skærmen om, hvordan du bruger værktøjet.
Der er en hel del muligheder, når det gælder filservermigrationer ved hjælp af Robocopy, og du ved måske ikke, hvor du skal begynde. Vær forsigtig med nogle af mulighederne, hvis du bare prøver det, da nogle af dem flytter dataene (sletter filer og mapper på kildeplaceringen eller målplaceringen).
Igennem de mange års brug har jeg fundet ud af, at denne syntaks er den, jeg vender tilbage til igen og igen:
robocopy \\sourceserver\ShareName D:\Shares\ShareName /e /b /copyall /PURGE /r:5 /w:5 /MT:64 /tee /log+:D:\Shares\log_ShareName _%date:~-10,2%”-“%date:~7,2%”-“%date:~-4,4%.txt /v
Lad os bryde det ned.
Robocopy
Initierer kommandoen.
\\sourceserver\ShareName
Den første parameter er altid kildeplaceringen. Jeg kører typisk altid Robocopy fra den nye filserver som:
- Den vil sandsynligvis have en nyere version af Robocopy installeret, og
- Jeg vil sandsynligvis ikke have delingerne bygget endnu på den nye server.
D:\Shares\ShareName
Den anden parameter er altid destinationsplaceringen. Jeg opfordrer kraftigt til, at du ikke placerer disse på C:\-styresystemets volumen, når det er muligt. Jeg kan også godt lide at oprette en rodmappe kaldet “Shares” og lægge alle de delte mapper i denne mappe i stedet for at lade dem ligge i roden. Der er flere fordele ved det, har jeg fundet ud af i årenes løb.
De næste parametre behøver ikke at være i nogen bestemt rækkefølge.
/e
Dette kopierer undermapper, også de tomme undermapper. Det er her, at den sande værdi af Robocopy kommer i spil. Hvis den kun kopierede filerne i den delte mappe på øverste niveau, ville den ikke være af stor værdi.
/b
Dette kopierer filer i Backup-tilstand. Dette opretter ikke et VSS-snapshot, men er i stedet nyttigt, hvis den Windows-konto, du kører Robocopy med, måske ikke har fuld adgang til kildeplaceringen på grund af ACL’er i NTFS.
/copy all
Så du har måske spurgt dig selv, hvorfor alt det besvær? Hvorfor ikke navigere til begge lokationer og copy-paste filerne fra lokation til lokation? Denne parameter kopierer alle filoplysninger. På den måde er der ikke et nyt tidsstempel, eller ejer, eller arvede NTFS-tilladelser, når der ikke burde være det osv. Alle filoplysninger omfatter:
- Data
- Attributter
- Tidsstempler
- Sikkerhed (NTFS ACL’er)
- Ejerinfo
- Ejerinfo
- Auditeringsinfo
/PURGE
Denne parameter sletter destinationsfiler og mapper, der ikke længere findes i kilden. Bemærk, at teknisk set giver det samme resultat at bruge parametrene /e og /PURGE sammen som at bruge den ene parameter alene (/mir – for “mirror”), men jeg foretrækker at have et stort stort stort “PURGE” i syntaksen, så når jeg ser på den, ved jeg, at jeg sandsynligvis sletter noget. Spørgsmålet opstår her om, hvis filen eller mappen ikke længere eksisterer på kildeplaceringen, hvorfor skulle jeg så forsøge at kopiere den til målet. Desuden, hvorfor skulle jeg ønske at slette en fil, der aldrig har eksisteret i første omgang.
Det er det andet sted, hvor Robocopy virkelig skinner. Jeg kører normalt ikke bare Robocopy én gang og er færdig, medmindre jeg kopierer inaktive forældede data. Jeg opretter normalt en planlagt opgave for at køre en batchfil, der indeholder de Robocopy-linjer, der skal køres. Med dette i tankerne og med ovenstående parametre vil den første udførelse af jobbet tage et stykke tid, da den skal foretage den indledende kopiering af alle data. Men når det kører næste gang (jeg indstiller det normalt til at køre dagligt efter arbejdstid), vil det kigge på kilden og sammenligne den med målet, og hvis filen ikke er ændret, vil det ikke gøre noget med den. Hvis filen i kilden er nyere, vil den overskrive filen i målet. Hvis filen i kilden er blevet slettet siden den sidste kørsel af jobbet, vil den samme fil i målet også automatisk blive slettet i målet. I forbindelse med en egentlig fildelingsmigrering sætter jeg dette op ca. en uge i forvejen, ser på de logfiler, det genererer, løser eventuelle problemer, og lader det køre dagligt indtil den planlagte overgangsdato. På cutover-datoen ville jeg sætte kildedelen i Read-Only og køre Robocopy-jobbet endnu en gang for at kopiere eventuelle deltaer, der er ændret siden sidste kørsel. Herefter ville jeg for at afslutte opløse kildeudvekslingen og derefter dele den nye deling.
/r:5
Dette flag angiver antallet af gange, Robocopy vil gentage en mislykket kopiering af en fil eller en mappe. Nogle gange mislykkes dette, fordi der er en lås på filen, fordi brugeren eller processen har den åben. Når dette sker, vil Robocopy forsøge kopieringen igen for at se, om låsen ikke længere er låst på filen. Som standard (hvis du ikke angiver denne parameter) vil Robocopy forsøge kopieringen 1 million gange igen. Da jeg ved, at vi vil forsøge at kopiere denne fil igen under den næste planlagte kørsel om en dag, er jeg mere end tilfreds med at prøve fem gentagelser, og hvis det ikke lykkes at kopiere, fortsætter jeg til den næste fil.
/w:5
Dette flag går hånd i hånd med /r. Dette flag angiver den tid i sekunder, der skal ventes mellem genforsøg. Standardværdien er 30 sekunder. Hvis man lægger 2 og 2 sammen, får man 1.000.000 * 30 = 30.000.000 sekunder eller 500.000 minutter eller 8.333 timer og 20 minutter eller 347 dage og 5 timer. Det betyder, at hvis en enkelt fil blev låst og forblev låst, ville det tage Robocopy næsten et år, før den ville gå videre til den næste opgave! Dette er et must for at indstille /r- og /w-flagene korrekt.
/MT:64
Dette flag indstiller et nyt maksimalt antal tråde, når der udføres flertrådet kopiering. Dette kopierer ikke flere filer eller mapper på samme tid, men bruger i stedet flere tråde med CPU’en til at udføre den kopi, som den er sat til at udføre. Standardtallet er 8. Jeg kan godt lide at øge dette antal til i alt 64 (husk dette, hvis du kører flere Robocopy-jobs samtidig). Der er CPU-overhead ved åbning af kildefilen, åbning af destinationsfilen, kopiering af data, lukning af kildefilen og lukning af destinationsfilen. Hvis alt dette skal gøres, før man går videre til den næste fil, er der risiko for, at I/O-undersystemet vil være inaktivt i en del af den tid, hvor det kunne have arbejdet. Bemærk: Dette vil sandsynligvis få dit system til at virke sløvt, da det arbejder anstændigt med CPU’en. Hvis dette er på en ny filserver, der endnu ikke er i produktion, bør det være ligegyldigt, om den er “langsom.”
/tee
Som standard, når dette køres manuelt fra kommandoprompten, vil Robocopy outputte, hvad den laver, til skærmbilledet. Med potentielt tusindvis af filer, der skal kopieres, er det en knap så effektiv måde at finde noget, der gik galt. Ved at angive /tee (i stedet for at udelade det helt) tvinges den til at output til konsolvinduet samt til logfilen. Dette er specielt nyttigt, hvis det er din første kørsel af Robocopy-jobbet, og du er ved at fejlfinde noget, der ikke helt fungerer, som det skal. Hvis jeg opretter en planlagt opgave af Robocopy-jobbet, anbefaler jeg at udelade denne kommando.
log+:D:\Shares\log_ShareName _%date:~-10,2%”-“%date:~7,2%”-“%date:~-4,4%.txt
Som standard er den eneste logning fra Robocopy visning til skærmen. Med parameteren /log kan du angive filstien til en ny fil (eller en eksisterende fil). Den vil overskrive filen, hvis den allerede findes. Når du udfører denne proces med en planlagt opgave, kan du imidlertid ønske at se alle iterationer af kørslen i stedet for kun den seneste. Ved at angive + efter log (/log+) vil den føje den til den angivne fil i stedet for at overskrive den. Ved også at sætte “_%date:~-10,2%”-“%date:~7,2%”-“%date:~-4,4%” i filnavnet vil den automatisk oprette en ny fil (hvis den er kørt for første gang den pågældende dag) med et suffiks _MM_DD_YYYYYY i slutningen af logfilen til historisk reference. For særligt store filandele kan selv logfilerne vokse til flere gigabyte, hvis de kører i dagevis, og det giver meget god mening at opdele dem i daglige logfiler.
/v
Denne parameter viser Verbose output, som vil vise oversete filer. Generelt vil du virkelig gerne se dette for at sikre dig, at overspringsfiler bliver logget.
I del 2 af denne blog vil jeg vise, hvordan du opretter et dagligt Robocopy-job med Task Scheduler.
Har du spørgsmål om migrering af dine filservere? Kontakt Sikich. Vi er klar til at hjælpe.