File Server Migraties met Robocopy Deel 1 van 2

File Server Migraties met Robocopy Deel 1 van 2

Deze blog is deel 1 van een 2-delige serie. Om deel 2 te zien, klik hier.

Met verschillende Windows Server besturingssystemen die dit jaar niet meer ondersteund worden, heb ik een behoorlijk aantal migraties van bestandsservers van het ene systeem naar het andere moeten uitvoeren. Soms, als de server geen andere rollen of functies heeft dan alleen een bestandsserver, dan kan ik gewoon de shares op de originele server unsharen, de virtuele harde schijf daarvan loskoppelen, de virtuele harde schijf aan de nieuwe server koppelen, en de shares opnieuw delen. Hierdoor blijven de NTFS rechten behouden als beide servers lid zijn van hetzelfde Active Directory domein. Het is over het algemeen ook erg snel, omdat er geen terabytes aan gegevens van de ene server naar de andere hoeven te worden gekopieerd. Dit proces werkt echter alleen elegant als de file share gegevens bestaan op een volume dat niet is waar Windows of andere applicaties zijn geinstalleerd.

Als de noodzaak zich voordoet om de gegevens te dupliceren voor de migratie naar de nieuwe server, grijp ik altijd terug naar de oude getrouwe-Robocopy (Robust File Copy for Windows). Robocopy bestaat al sinds de NT4 dagen in 1996, dus dit is waarschijnlijk niet de eerste keer dat je er van hoort. In die tijd en tot 2008, was het beschikbaar met de Windows Resource Kit download. Vanaf 2008 (en daarna) werd het gebundeld met zowel desktop- als serverbesturingssystemen, te beginnen met Vista en Server 2008. De kans is dus groot dat als je een opdrachtprompt op je computer start en “robocopy /?” intypt, je de helpdump met informatie op je scherm krijgt over hoe je het hulpprogramma moet gebruiken.

Er zijn nogal wat opties als het gaat om bestandsservermigraties met Robocopy, en je weet misschien niet waar je moet beginnen. Wees voorzichtig met sommige opties als u het net uitprobeert, omdat sommige de gegevens verplaatsen (waarbij de bestanden en mappen op de bronlocatie of de doellocatie worden verwijderd).

In de loop der jaren heb ik deze syntax gevonden, waar ik steeds weer naar teruggrijp:

robocopy \Sourceservernaam D:/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

Laten we dat eens uitsplitsen.

Robocopy
Start het commando.

Robocopy
De eerste parameter is altijd de bron locatie. Ik voer Robocopy altijd uit vanaf de nieuwe bestandsserver als:

• Er is waarschijnlijk een nieuwere versie van Robocopy geinstalleerd; en
• Ik heb waarschijnlijk de shares nog niet gebouwd op de nieuwe server.

D:\SharesShareName
De tweede parameter is altijd de bestemmings lokatie. Ik raad je sterk aan om deze niet op het C:-besturingssysteemvolume te zetten als dat mogelijk is. Ik maak ook graag een hoofdmap aan met de naam “Shares” en plaats alle gedeelde mappen in deze map in plaats van ze in de hoofdmap te laten staan. Dat heeft meerdere voordelen heb ik in de loop der jaren ondervonden.

De volgende parameters hoeven niet in een bepaalde volgorde te staan.

/e

Dit kopieert subdirectories, inclusief de lege. Dit is waar de echte waarde van Robocopy in het spel komt. Als het alleen de bestanden in de top-level gedeelde map zou kopiëren, zou het niet van veel waarde zijn.

/b
Dit kopieert bestanden in Backup modus. Dit maakt geen VSS-snapshot, maar is handig als de Windows-account waarmee u Robocopy uitvoert geen volledige toegang heeft tot de bronlocatie vanwege ACL’s in NTFS.

/copy all
Dus u vraagt zich misschien af, waarom al die moeite? Waarom niet navigeren naar beide locaties en de bestanden kopiëren-plakken van locatie naar locatie? Deze parameter kopieert alle bestandsinfo. Op die manier is er geen nieuwe tijdstempel, of eigenaar, of geërfde NTFS rechten wanneer die er niet zouden moeten zijn, enz. Alle bestandsinfo omvat:

• Data
• Attributes
• Timestamps
• Security (NTFS ACLs)
• Owner info
• Auditing info

/PURGE
Deze parameter verwijdert doelbestanden en -mappen die niet langer bestaan in het bronbestand. Merk op dat technisch gezien, het gebruik van parameters /e en /PURGE samen hetzelfde effect geeft als het gebruik van één parameter op zichzelf (/mir – voor “mirror”), maar ik verkies een grote hoofdletter “PURGE” in de syntax zodat wanneer ik er naar kijk, ik weet dat ik waarschijnlijk iets aan het verwijderen ben. De vraag rijst hier: als het bestand of de map niet langer bestaat op de bronlocatie, waarom zou ik het dan proberen te kopiëren naar het doel. Bovendien, waarom zou ik een bestand willen verwijderen dat nooit heeft bestaan?

Dit is de tweede plaats waar Robocopy echt uitblinkt. Ik voer Robocopy meestal niet één keer uit en klaar, tenzij ik inactieve, oude data kopieer. Ik maak meestal een geplande taak om een batch bestand uit te voeren dat de Robocopy regels bevat om uit te voeren. Met dit in gedachten en met de bovenstaande parameters, zal de eerste uitvoering van de taak een tijdje duren, omdat het de eerste kopie van alle gegevens moet doen. Echter, wanneer hij de volgende keer wordt uitgevoerd (ik stel hem meestal in om dagelijks na kantooruren uit te voeren), zal hij kijken naar de bron en deze vergelijken met het doel, en als het bestand niet is veranderd, zal hij er niets mee doen. Als het bestand in de broncode nieuwer is, zal het het bestand in de doelcode overschrijven. Als het bestand in de bron is verwijderd sinds de laatste run van de job, zal hetzelfde bestand in het doel automatisch ook worden verwijderd. Voor een echte file share migratie, stel ik dit ongeveer een week van te voren in, bekijk de logs die het genereert, los eventuele problemen op, en laat het dagelijks draaien tot de geplande cutover datum. Op de overdrachtsdatum zet ik de bron share in Alleen-lezen en voer de Robocopy job nog een keer uit om alle delta’s te kopiëren die zijn gewijzigd sinds de laatste run. Daarna, om af te ronden, zou ik de bron share unsharen en dan de nieuwe share delen.

/r:5
Deze vlag geeft het aantal keren aan dat Robocopy een mislukte kopie van een bestand of map opnieuw zal proberen. Soms mislukt dit omdat er een “lock” op het bestand zit omdat de gebruiker of het proces het open heeft staan. Wanneer dit gebeurt, zal Robocopy de kopie opnieuw proberen om te zien of de blokkade niet meer op het bestand zit. Standaard (als u deze parameter niet opgeeft), zal Robocopy de kopie 1 miljoen keer opnieuw proberen. Wetende dat we gaan proberen om dit bestand opnieuw te kopiëren tijdens de volgende geplande run over een dag, ben ik meer dan tevreden met vijf keer opnieuw proberen, en als het niet succesvol kopieert, doorgaan naar het volgende bestand.

/w:5
Deze vlag gaat hand in hand met /r. Deze vlag specificeert de hoeveelheid tijd in seconden te wachten tussen herhalingen. Standaard is 30 seconden. Als we 2 en 2 samenvoegen, 1.000.000 * 30 = 30.000.000 seconden of 500.000 minuten of 8.333 uur en 20 minuten of 347 dagen en 5 uur. Dit betekent dat als een enkel bestand geblokkeerd is en blijft, Robocopy er bijna een jaar over zou doen voordat het verder gaat met de volgende taak! Dit is een must om de /r en /w vlaggen goed in te stellen.

/MT:64
Deze vlag stelt een nieuw maximum aantal threads in wanneer multi-threaded kopieën worden gemaakt. Dit kopieert niet meerdere bestanden of mappen tegelijk, maar gebruikt in plaats daarvan meer threads met de CPU om de kopie te doen waarvoor het is ingesteld. Het standaard aantal is 8. Ik verhoog dit aantal graag tot een totaal van 64 (houd dit in gedachten als je meerdere Robocopy opdrachten tegelijk uitvoert). Er is CPU overhead van het openen van het bron bestand, het openen van het doel bestand, het kopiëren van de data, het sluiten van het bron bestand, en het sluiten van het doel bestand. Als dit allemaal gedaan moet worden voordat naar het volgende bestand gegaan kan worden, kan het I/O subsysteem een deel van de tijd inactief zijn, terwijl het had kunnen werken. Opmerking: dit zal uw systeem waarschijnlijk traag doen lijken omdat het de CPU behoorlijk laat werken. Als dit op een nieuwe, nog niet in productie zijnde bestandsserver is, zou het niet uit moeten maken dat het “traag” is.

/tee
Standaard zal Robocopy, wanneer dit handmatig vanaf de opdrachtprompt wordt uitgevoerd, op het scherm laten zien wat het aan het doen is. Met potentieel duizenden bestanden om te kopiëren, is dit een minder dan efficiënte manier om iets te vinden dat fout ging. Door /tee op te geven (in plaats van het helemaal weg te laten) wordt de uitvoer naar het consolevenster en het logbestand geforceerd. Dit is vooral handig als je Robocopy voor het eerst uitvoert en je iets aan het oplossen bent dat niet helemaal werkt zoals het zou moeten. Als ik een geplande taak maak van de Robocopy taak, adviseer ik om dit commando weg te laten.

log+:D:/log_ShareName _%date:~-10,2%”-“%date:~7,2%”-“%date:~-4,4%.txt

Standaard is de enige logging van Robocopy de weergave op het scherm. Met de /log parameter, geef het bestandspad op naar een nieuw bestand (of bestaand bestand). Het zal het bestand overschrijven als het al bestaat. Echter, wanneer je dit proces uitvoert met een geplande taak, kan het zijn dat je alle iteraties van de run wilt zien in plaats van alleen de meest recente. Door de + achter log (/log+) te zetten, wordt het bestand toegevoegd aan het opgegeven bestand in plaats van het te overschrijven. Ook door “_%date:~-10,2%”-“%date:~-7,2%”-“%date:~-4,4%” in de bestandsnaam te zetten, wordt automatisch een nieuw bestand aangemaakt (als het die dag voor het eerst is uitgevoerd) met een achtervoegsel _MM_DD_JJJJ aan het eind van het logbestand voor historische verwijzingen. Voor bijzonder grote bestandsdelingen kunnen zelfs de logbestanden uitgroeien tot meerdere gigabytes als ze dagenlang worden uitgevoerd en het is zinvol om ze op te splitsen in dagelijkse logbestanden.

/v
Deze parameter toont Verbose-uitvoer, die overgeslagen bestanden laat zien. Over het algemeen wil je dit echt zien om er zeker van te zijn dat overgeslagen bestanden worden gelogd.

In deel 2 van deze blog, zal ik laten zien hoe je een dagelijkse Robocopy job instelt met Task Scheduler.

Heb je vragen over het migreren van je file servers? Neem contact op met Sikich. Wij staan klaar om te helpen.