Data Box gebruiken om te migreren van Nas (Network Attached Storage) naar een hybride cloudimplementatie met behulp van Azure File Sync
Dit migratieartikel is een van de verschillende die van toepassing zijn op de trefwoorden NAS, Azure File Sync en Azure Data Box. Controleer of dit artikel van toepassing is op uw scenario:
- Gegevensbron: Network Attached Storage (NAS)
- Migratieroute: NAS ⇒ Data Box ⇒ Azure-bestandsshare ⇒ synchroniseren met Windows Server
- On-premises bestanden in de cache opslaan: Ja, het uiteindelijke doel is een Azure File Sync-implementatie
Als uw scenario anders is, bekijkt u de tabel met migratiehandleidingen.
Azure File Sync werkt op DAS-locaties (Direct Attached Storage). Het biedt geen ondersteuning voor synchronisatie met NAS-locaties (Network Attached Storage). U moet uw bestanden dus migreren. In dit artikel wordt u begeleid bij het plannen en implementeren van die migratie.
Van toepassing op
Bestands sharetype | SMB | NFS |
---|---|---|
Standaardbestandsshares (GPv2), LRS/ZRS | ||
Standaardbestandsshares (GPv2), GRS/GZRS | ||
Premium bestandsshares (FileStorage), LRS/ZRS |
Migratiedoelen
Het doel is om de shares die u op uw NAS-apparaat hebt, te verplaatsen naar Windows Server. Vervolgens gebruikt u Azure File Sync voor een hybride cloudimplementatie. Deze migratie moet worden uitgevoerd op een manier die de integriteit van de productiegegevens en beschikbaarheid tijdens de migratie garandeert. Dit laatste vereist dat downtime tot een minimum wordt beperkt, zodat deze voldoet aan of slechts iets hoger is dan normale onderhoudsvensters.
Migratieoverzicht
Het migratieproces bestaat uit verschillende fasen. U moet het volgende doen:
- Azure-opslagaccounts en bestandsshares implementeren.
- Implementeer een on-premises computer met Windows Server.
- Configureer Azure File Sync.
- Bestanden migreren met Behulp van Robocopy.
- Doe de cutover.
In de volgende secties worden de fasen van het migratieproces gedetailleerd beschreven.
Tip
Als u terugkeert naar dit artikel, gebruikt u de navigatie aan de rechterkant van het scherm om naar de migratiefase te gaan waar u was gebleven.
Fase 1: bepalen hoeveel Azure-bestandsshares u nodig hebt
In deze stap bepaalt u hoeveel Azure-bestandsshares u nodig hebt. Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares synchroniseren.
Mogelijk hebt u meer mappen op uw volumes die u momenteel lokaal deelt als SMB deelt met uw gebruikers en apps. De eenvoudigste manier om dit scenario voor te stellen, is door een on-premises share te maken die 1:1 toewijst aan een Azure-bestandsshare. Als u een klein aantal shares hebt, lager dan 30 voor één Exemplaar van Windows Server, raden we u aan een toewijzing van 1:1 uit te voeren.
Als u meer dan 30 shares hebt, is het toewijzen van een on-premises share 1:1 aan een Azure-bestandsshare vaak overbodig. Houd rekening met de volgende opties.
Groeperen delen
Als uw hr-afdeling bijvoorbeeld 15 shares heeft, kunt u overwegen om alle HR-gegevens op te slaan in één Azure-bestandsshare. Als u meerdere on-premises shares opslaat in één Azure-bestandsshare, voorkomt u niet dat u de gebruikelijke 15 SMB-shares maakt op uw lokale Windows Server-exemplaar. Dit betekent alleen dat u de hoofdmappen van deze 15 shares ordent als submappen onder een gemeenschappelijke map. Vervolgens synchroniseert u deze algemene map naar een Azure-bestandsshare. Op die manier is slechts één Azure-bestandsshare in de cloud nodig voor deze groep on-premises shares.
Volumesynchronisatie
Azure File Sync ondersteunt het synchroniseren van de hoofdmap van een volume naar een Azure-bestandsshare. Als u de hoofdmap van het volume synchroniseert, gaan alle submappen en bestanden naar dezelfde Azure-bestandsshare.
Het synchroniseren van de hoofdmap van het volume is niet altijd de beste optie. Het synchroniseren van meerdere locaties heeft voordelen. Als u dit bijvoorbeeld doet, blijft het aantal items lager per synchronisatiebereik. We testen Azure-bestandsshares en Azure File Sync met 100 miljoen items (bestanden en mappen) per share. Maar een best practice is om het aantal onder de 20 miljoen of 30 miljoen in één aandeel te houden. Het instellen van Azure File Sync met een lager aantal items is niet alleen nuttig voor bestandssynchronisatie. Een lager aantal items biedt ook voordelen voor scenario's zoals deze:
- De eerste scan van de cloudinhoud kan sneller worden voltooid, waardoor de wachttijd voor de naamruimte wordt verlaagd op een server die is ingeschakeld voor Azure File Sync.
- Herstel aan de cloudzijde vanuit een momentopname van een Azure-bestandsshare is sneller.
- Herstel na noodgevallen van een on-premises server kan aanzienlijk versnellen.
- Wijzigingen die rechtstreeks in een Azure-bestandsshare (buiten synchronisatie) zijn aangebracht, kunnen sneller worden gedetecteerd en gesynchroniseerd.
Tip
Als u niet weet hoeveel bestanden en mappen u hebt, bekijkt u het hulpprogramma TreeSize van JAM Software GmbH.
Een gestructureerde benadering van een implementatieoverzicht
Voordat u cloudopslag in een latere stap implementeert, is het belangrijk om een kaart te maken tussen on-premises mappen en Azure-bestandsshares. Met deze toewijzing wordt aangegeven hoeveel resources en welke Azure File Sync-synchronisatiegroepsbronnen u gaat inrichten. Een synchronisatiegroep verbindt de Azure-bestandsshare en de map op uw server en brengt een synchronisatieverbinding tot stand.
Bekijk de volgende limieten en aanbevolen procedures om te bepalen hoeveel Azure-bestandsshares u nodig hebt. Als u dit doet, kunt u uw kaart optimaliseren.
Een server waarop de Azure File Sync-agent is geïnstalleerd, kan worden gesynchroniseerd met maximaal 30 Azure-bestandsshares.
Een Azure-bestandsshare wordt geïmplementeerd in een opslagaccount. Deze rangschikking maakt het opslagaccount een schaaldoel voor prestatienummers zoals IOPS en doorvoer.
Let op de IOPS-beperkingen van een opslagaccount bij het implementeren van Azure-bestandsshares. In het ideale geval moet u bestandsshares 1:1 toewijzen met opslagaccounts. Dit is echter mogelijk niet altijd mogelijk vanwege verschillende limieten en beperkingen, zowel van uw organisatie als van Azure. Wanneer het niet mogelijk is om slechts één bestandsshare in één opslagaccount te implementeren, moet u overwegen welke shares zeer actief zijn en welke shares minder actief zijn om ervoor te zorgen dat de heetste bestandsshares niet samen in hetzelfde opslagaccount worden geplaatst.
Als u van plan bent om een app naar Azure op te tillen die de Azure-bestandsshare systeemeigen gebruikt, hebt u mogelijk meer prestaties nodig van uw Azure-bestandsshare. Als dit type gebruik een mogelijkheid is, zelfs in de toekomst, kunt u het beste één standaard Azure-bestandsshare maken in een eigen opslagaccount.
Er geldt een limiet van 250 opslagaccounts per abonnement per Azure-regio.
Tip
Gezien deze informatie is het vaak nodig om meerdere mappen op het hoogste niveau op uw volumes te groeperen in een nieuwe algemene hoofdmap. Vervolgens synchroniseert u deze nieuwe hoofdmap en alle mappen die u erin hebt gegroepeerd, naar één Azure-bestandsshare. Met deze techniek kunt u binnen de limiet van 30 Azure-bestandssharesynchronisaties per server blijven.
Deze groepering onder een algemene hoofdmap heeft geen invloed op de toegang tot uw gegevens. Uw ACL's blijven zoals ze zijn. U hoeft alleen sharepaden (zoals SMB- of NFS-shares) aan te passen die u mogelijk hebt op de lokale servermappen die u nu hebt gewijzigd in een algemene hoofdmap. Niets anders verandert.
Belangrijk
De belangrijkste schaalvector voor Azure File Sync is het aantal items (bestanden en mappen) dat moet worden gesynchroniseerd. Bekijk de Azure File Sync-schaaldoelen voor meer informatie.
Het is een best practice om het aantal items per synchronisatiebereik laag te houden. Dat is een belangrijke factor om rekening mee te houden bij het toewijzen van mappen aan Azure-bestandsshares. Azure File Sync wordt getest met 100 miljoen items (bestanden en mappen) per share. Maar het is vaak het beste om het aantal items onder de 20 miljoen of 30 miljoen in één aandeel te houden. Splits uw naamruimte in meerdere shares als u deze getallen begint te overschrijden. U kunt meerdere on-premises shares blijven groeperen in dezelfde Azure-bestandsshare als u ongeveer onder deze getallen blijft. Deze praktijk geeft u ruimte om te groeien.
Het is mogelijk dat een set mappen in uw situatie logisch kan worden gesynchroniseerd met dezelfde Azure-bestandsshare (met behulp van de nieuwe veelgebruikte basismapbenadering die eerder is genoemd). Maar het is misschien nog beter om mappen opnieuw te groeperen, zodat ze worden gesynchroniseerd met twee in plaats van één Azure-bestandsshare. U kunt deze methode gebruiken om het aantal bestanden en mappen per bestandsshare verdeeld te houden over de server. U kunt uw on-premises shares ook splitsen en synchroniseren over meer on-premises servers, en de mogelijkheid toevoegen om te synchroniseren met 30 meer Azure-bestandsshares per extra server.
Veelvoorkomende scenario's en overwegingen voor bestandssynchronisatie
# | Synchronisatiescenario | Ondersteund | Overwegingen (of beperkingen) | Oplossing (of tijdelijke oplossing) |
---|---|---|---|---|
1 | Bestandsserver met meerdere schijven/volumes en meerdere shares naar dezelfde Azure-bestandsshare (samenvoeging) | Nee | Een azure-doelbestandsshare (cloudeindpunt) ondersteunt alleen synchronisatie met één synchronisatiegroep. Een synchronisatiegroep ondersteunt slechts één servereindpunt per geregistreerde server. |
1) Begin met het synchroniseren van één schijf (het hoofdvolume) naar de Azure-bestandsshare. Beginnend met de grootste schijf/het grootste volume helpt bij de opslagvereisten on-premises. Configureer cloudlagen om alle gegevens in de cloud te tieren, waardoor ruimte vrij is op de bestandsserverschijf. Verplaats gegevens van andere volumes/shares naar het huidige volume dat wordt gesynchroniseerd. Ga één voor één door met de stappen totdat alle gegevens zijn gelaagd tot in de cloud/gemigreerd. 2) Doel één hoofdvolume (schijf) tegelijk. Gebruik cloudlagen om alle gegevens in een laag te plaatsen voor de Azure-bestandsshare. Verwijder het servereindpunt uit de synchronisatiegroep, maak het eindpunt opnieuw met het volgende hoofdvolume/de volgende schijf, synchroniseer en herhaal het proces. Opmerking: mogelijk is het opnieuw installeren van de agent vereist. 3) Het gebruik van meerdere Doel-Azure-bestandsshares (hetzelfde of een ander opslagaccount op basis van prestatievereisten) aanbevelen |
2 | Bestandsserver met één volume en meerdere shares naar dezelfde Azure-bestandsshare (consolidatie) | Ja | Er kunnen niet meerdere servereindpunten per geregistreerde server worden gesynchroniseerd met dezelfde Azure-doelbestandsshare (hetzelfde als hierboven) | Synchroniseer de hoofdmap van het volume met meerdere shares of mappen op het hoogste niveau. Raadpleeg het concept groeperen delen en volumesynchronisatie voor meer informatie. |
3 | Bestandsserver met meerdere shares en/of volumes naar meerdere Azure-bestandsshares onder één opslagaccount (toewijzing van 1:1 share) | Ja | Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares synchroniseren. Een opslagaccount is een schaaldoel voor prestaties. IOPS en doorvoer worden gedeeld tussen bestandsshares. Houd het aantal items per synchronisatiegroep binnen 100 miljoen items (bestanden en mappen) per share. Idealiter is het raadzaam om onder de 20 of 30 miljoen per aandeel te blijven. |
1) Gebruik meerdere synchronisatiegroepen (aantal synchronisatiegroepen = aantal Azure-bestandsshares om mee te synchroniseren). 2) In dit scenario kunnen slechts 30 shares tegelijk worden gesynchroniseerd. Als u meer dan 30 shares op die bestandsserver hebt, gebruikt u het concept sharegroepering en volumesynchronisatie om het aantal hoofdmappen of mappen op het hoogste niveau bij de bron te verminderen. 3) Gebruik aanvullende bestandssynchronisatieservers on-premises en splits/verplaats gegevens naar deze servers om beperkingen op de Windows-bronserver te omzeilen. |
4 | Bestandsserver met meerdere shares en/of volumes naar meerdere Azure-bestandsshares onder een ander opslagaccount (toewijzing van 1:1 share) | Ja | Eén Windows Server-exemplaar (of cluster) kan maximaal 30 Azure-bestandsshares (hetzelfde of een ander opslagaccount) synchroniseren. Houd het aantal items per synchronisatiegroep binnen 100 miljoen items (bestanden en mappen) per share. Idealiter is het raadzaam om onder de 20 of 30 miljoen per aandeel te blijven. |
Dezelfde benadering als hierboven |
5 | Meerdere bestandsservers met één (hoofdvolume of share) met dezelfde Azure-bestandsshare (samenvoeging) | Nee | Een synchronisatiegroep kan geen cloudeindpunt (Azure-bestandsshare) gebruiken dat al is geconfigureerd in een andere synchronisatiegroep. Hoewel een synchronisatiegroep servereindpunten op verschillende bestandsservers kan hebben, kunnen de bestanden niet verschillen. |
Volg de richtlijnen in scenario 1 hierboven met extra aandacht voor het instellen van één bestandsserver tegelijk. |
Een toewijzingstabel maken
Gebruik de vorige informatie om te bepalen hoeveel Azure-bestandsshares u nodig hebt en in welke delen van uw bestaande gegevens de Azure-bestandsshare terechtkomt.
Maak een tabel waarin uw gedachten worden vastgelegd, zodat u ernaar kunt verwijzen wanneer dat nodig is. Georganiseerd blijven is belangrijk omdat u eenvoudig details van uw toewijzingsplan kwijtraakt wanneer u veel Azure-resources tegelijk inricht. Download het volgende Excel-bestand om te gebruiken als sjabloon om uw toewijzing te helpen maken.
Download een sjabloon voor naamruimtetoewijzing. |
Fase 2: Azure-opslagbronnen implementeren
In deze fase raadpleegt u de toewijzingstabel uit fase 1 en gebruikt u deze om het juiste aantal Azure-opslagaccounts en bestandsshares in te richten.
Een Azure-bestandsshare wordt opgeslagen in de cloud in een Azure-opslagaccount. Hier is een ander prestatieniveau van toepassing.
Als u zeer actieve shares hebt (shares die door veel gebruikers en/of toepassingen worden gebruikt), kunnen twee Azure-bestandsshares de prestatielimiet van een opslagaccount bereiken.
Een best practice is het implementeren van opslagaccounts met één bestandsshare. U kunt meerdere Azure-bestandsshares in hetzelfde opslagaccount groeperen als u archiveringsshares hebt of als u een lage dagelijkse activiteit verwacht.
Deze overwegingen zijn meer van toepassing op directe cloudtoegang (via een Azure-VM) dan op Azure File Sync. Als u van plan bent om alleen Azure File Sync op deze shares te gebruiken, is het prima om meerdere te groeperen in één Azure-opslagaccount.
Als u een lijst met uw shares hebt gemaakt, moet u elke share toewijzen aan het opslagaccount waarin deze zich bevinden.
In de vorige fase hebt u het juiste aantal shares bepaald. In deze stap hebt u een toewijzing van opslagaccounts aan bestandsshares. Implementeer nu het juiste aantal Azure-opslagaccounts met het juiste aantal Azure-bestandsshares erin.
Zorg ervoor dat de regio van elk van uw opslagaccounts hetzelfde is en overeenkomt met de regio van de opslagsynchronisatieserviceresource die u al hebt geïmplementeerd.
Let op
Als u een Azure-bestandsshare met een limiet van 100 TiB maakt, kan die share alleen lokaal redundante opslag of zone-redundante opslagredundantieopties gebruiken. Houd rekening met uw opslagredundantie voordat u 100 TiB-bestandsshares gebruikt.
Azure-bestandsshares worden standaard nog steeds gemaakt met een limiet van 5 TiB. Volg de stappen in Een Azure-bestandsshare maken om een grote bestandsshare te maken.
Een andere overweging bij het implementeren van een opslagaccount is de redundantie van Azure Storage. Zie de opties voor Azure Storage-redundantie.
De namen van uw resources zijn ook belangrijk. Als u bijvoorbeeld meerdere shares voor de HR-afdeling groeperen in een Azure-opslagaccount, moet u het opslagaccount de juiste naam opgeven. Op dezelfde manier moet u, wanneer u uw Azure-bestandsshares een naam krijgt, namen gebruiken die vergelijkbaar zijn met de namen die zijn gebruikt voor hun on-premises tegenhangers.
Fase 3: Bepalen hoeveel Azure Data Box-apparaten u nodig hebt
Start deze stap pas nadat u de vorige fase hebt voltooid. Uw Azure-opslagbronnen (opslagaccounts en bestandsshares) moeten op dit moment worden gemaakt. Wanneer u uw Data Box bestelt, moet u de opslagaccounts opgeven waarin de Data Box gegevens verplaatst.
In deze fase moet u de resultaten van het migratieplan uit de vorige fase toewijzen aan de limieten van de beschikbare Data Box-opties. Deze overwegingen helpen u bij het maken van een plan waarvoor Data Box-opties u kunt kiezen en hoeveel van deze opties u nodig hebt om uw NAS-shares te verplaatsen naar Azure-bestandsshares.
Houd rekening met de volgende belangrijke limieten om te bepalen hoeveel apparaten en hun typen u nodig hebt:
- Elk Azure Data Box-apparaat kan gegevens verplaatsen naar maximaal 10 opslagaccounts.
- Elke Data Box-optie wordt geleverd met een eigen bruikbare capaciteit. Zie Data Box-opties.
Raadpleeg uw migratieplan om het aantal opslagaccounts te vinden dat u hebt gemaakt en de shares in elk account. Bekijk vervolgens de grootte van elk van de shares op uw NAS. Door deze informatie te combineren, kunt u optimaliseren en bepalen welk apparaat gegevens moet verzenden naar welke opslagaccounts. Twee Data Box-apparaten kunnen bestanden verplaatsen naar hetzelfde opslagaccount, maar geen inhoud van één bestandsshare splitsen in twee Data Boxes.
Data Box-opties
Kies voor een standaardmigratie een of een combinatie van deze Data Box-opties:
- Data Box Disk. Microsoft stuurt u tussen één en vijf SSD-schijven met een capaciteit van 8 TiB elk, voor een maximum van 40 TiB. De bruikbare capaciteit is ongeveer 20 procent minder vanwege de overhead van versleuteling en bestandssysteem. Zie de Documentatie voor Data Box Disk voor meer informatie.
- Data Box. Deze optie is het meest gebruikelijk. Microsoft stuurt u een robuust Data Box-apparaat dat vergelijkbaar is met een NAS. Het heeft een bruikbare capaciteit van 80 TiB. Zie de Data Box-documentatie voor meer informatie.
- Data Box Heavy. Deze optie is voorzien van een robuust Data Box-apparaat op wielen die vergelijkbaar zijn met een NAS. Het heeft een capaciteit van 1 PiB. De bruikbare capaciteit is ongeveer 20 procent minder vanwege de overhead van versleuteling en bestandssysteem. Zie de Documentatie van Data Box Heavy voor meer informatie.
Fase 4: Een geschikt On-premises Windows Server-exemplaar inrichten
Terwijl u wacht tot uw Azure Data Box-apparaten binnenkomen, kunt u beginnen met het controleren van de behoeften van een of meer Windows Server-exemplaren die u gaat gebruiken met Azure File Sync.
- Maak een Exemplaar van Windows Server 2022 (minimaal Windows Server 2012 R2) als een virtuele machine of fysieke server. Een Windows Server-failovercluster wordt ook ondersteund.
- Direct Attached Storage inrichten of toevoegen. NAS wordt niet ondersteund.
De resourceconfiguratie (compute en RAM) van het Windows Server-exemplaar dat u implementeert, is voornamelijk afhankelijk van het aantal bestanden en mappen dat u wilt synchroniseren. We raden u aan een configuratie met hogere prestaties te configureren als u problemen ondervindt.
Notitie
Het eerder gekoppelde artikel bevat een tabel met een bereik voor servergeheugen (RAM). U kunt getallen onder aan het bereik voor uw server gebruiken, maar verwacht dat de eerste synchronisatie aanzienlijk langer duurt.
Fase 5: Bestanden kopiëren naar uw Data Box
Wanneer uw Data Box binnenkomt, moet u deze instellen met ongempte netwerkconnectiviteit met uw NAS-apparaat. Volg de installatiedocumentatie voor het type Data Box dat u hebt besteld:
- Data Box instellen.
- Data Box Disk instellen.
- Data Box Heavy instellen.
Afhankelijk van het type Data Box zijn er mogelijk hulpprogramma's voor het kopiëren van Data Box beschikbaar. Op dit moment raden we ze niet aan voor migraties naar Azure-bestandsshares, omdat ze uw bestanden niet met volledige betrouwbaarheid naar de Data Box kopiëren. Gebruik in plaats daarvan Robocopy.
Wanneer uw Data Box binnenkomt, zijn vooraf ingerichte SMB-shares beschikbaar voor elk opslagaccount dat u hebt opgegeven toen u deze bestelde.
- Als uw bestanden naar een Premium Azure-bestandsshare gaan, is er één SMB-share per premium 'File Storage'-opslagaccount.
- Als uw bestanden naar een standaardopslagaccount gaan, zijn er drie SMB-shares per standaardopslagaccount (GPv1 en GPv2). Alleen de bestandsshares die eindigen,
_AzFiles
zijn relevant voor uw migratie. Negeer eventuele blok- en pagina-blobshares.
Volg de stappen in de Documentatie voor Azure Data Box:
- Verbinding maken met Data Box.
- Gegevens kopiëren naar Data Box.
U kunt Robocopy gebruiken (volg de onderstaande instructies) of de nieuwe Data Box-service voor het kopiëren van gegevens. - Bereid uw Data Box voor op uploaden naar Azure.
Tip
Als alternatief voor Robocopy heeft Data Box een gegevenskopieerservice gemaakt. U kunt deze service gebruiken om bestanden met volledige betrouwbaarheid in uw Data Box te laden. Volg deze zelfstudie over het kopiëren van gegevens en zorg ervoor dat u het juiste Azure-bestandssharedoel instelt.
In de Data Box-documentatie wordt een Robocopy-opdracht opgegeven. Deze opdracht is niet geschikt voor het behouden van de volledige bestand- en mapkwaliteit. Gebruik in plaats daarvan deze opdracht:
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Switch | Betekenis |
---|---|
/MT:n |
Met Robocopy kunnen meerdere threads worden uitgevoerd. De standaardwaarde n is 8. Het maximum is 128 threads. Hoewel een hoog aantal threads helpt de beschikbare bandbreedte te verzadigen, betekent dit niet dat uw migratie altijd sneller is met meer threads. Tests met Azure Files geven aan dat tussen 8 en 20 evenwichtige prestaties worden weergegeven voor een eerste kopieerbewerking. Volgende /MIR uitvoeringen worden geleidelijk beïnvloed door de beschikbare rekenkracht versus de beschikbare netwerkbandbreedte. Voor volgende uitvoeringen moet u de waarde van het aantal threads nauwkeuriger overeen laten komen met het aantal processorkernen en het aantal threads per kern. Overweeg of kernen moeten worden gereserveerd voor andere taken die een productieserver mogelijk heeft. Tests met Azure Files hebben aangetoond dat maximaal 64 threads een goede prestaties opleveren, maar alleen als uw processors ze tegelijkertijd in leven kunnen houden. |
/R:n |
Het Maximum aantal nieuwe pogingen voor een bestand dat niet kan worden gekopieerd bij de eerste poging. Robocopy probeert n tijden voordat het bestand permanent niet kan worden gekopieerd in de uitvoering. U kunt de prestaties van uw uitvoering optimaliseren: kies een waarde van twee of drie als u denkt dat time-outproblemen in het verleden fouten hebben veroorzaakt. Dit kan vaker voorkomen via WAN-koppelingen. Kies geen nieuwe poging of een waarde als u denkt dat het bestand niet kan worden gekopieerd omdat het actief in gebruik was. Als u het een paar seconden later opnieuw probeert, is het mogelijk niet voldoende om de status in gebruik van het bestand te wijzigen. Gebruikers of apps die het bestand openen houden, hebben mogelijk uren meer tijd nodig. In dit geval is het accepteren van het bestand niet gekopieerd en in een van uw geplande, volgende Robocopy-uitvoeringen, mogelijk geslaagd om het bestand uiteindelijk te kopiëren. Dit helpt de huidige uitvoering sneller te voltooien zonder te worden verlengd door veel nieuwe pogingen die uiteindelijk in een meerderheid van de kopieerfouten terechtkomen omdat bestanden nog steeds zijn geopend na de time-out voor opnieuw proberen. |
/W:n |
Specificeert de tijd dat Robocopy wacht voordat wordt geprobeerd een bestand te kopiëren dat niet is gekopieerd tijdens een vorige poging. n is het aantal seconden dat moet worden gewacht tussen nieuwe pogingen. /W:n wordt vaak samen met /R:n . |
/B |
Voert Robocopy uit in dezelfde modus die een back-uptoepassing zou gebruiken. Met deze switch kan Robocopy bestanden verplaatsen waarvoor de huidige gebruiker geen machtigingen heeft. De back-upswitch is afhankelijk van het uitvoeren van de Robocopy-opdracht in een console met verhoogde beheerdersrechten of PowerShell-venster. Als u Robocopy voor Azure Files gebruikt, moet u ervoor zorgen dat u de Azure-bestandsshare koppelt met behulp van de toegangssleutel voor het opslagaccount versus een domeinidentiteit. Als u dat niet doet, leiden de foutberichten mogelijk niet intuïtief tot een oplossing van het probleem. |
/MIR |
(Sspiegelen van bron naar doel.) Hiermee kan Robocopy alleen delta's kopiëren tussen bron en doel. Lege submappen worden gekopieerd. Items (bestanden of mappen) die zijn gewijzigd of die niet bestaan in het doel, worden gekopieerd. Items die aanwezig zijn in het doel, maar niet in de bron, worden opgeschoond (verwijderd) uit het doel. Wanneer u deze switch gebruikt, moeten de bron- en doelmapstructuren exact overeenkomen. Vergelijking betekent dat u kopieert van het juiste bron- en mapniveau naar het overeenkomende mapniveau op het doel. Alleen dan kan een 'inhaalkopie' succesvol zijn. Wanneer de bron en het doel niet overeenkomen, leidt het gebruik /MIR tot grootschalige verwijderingen en nieuwe bereiken. |
/IT |
Zorgt dat de betrouwbaarheid behouden blijft in bepaalde spiegelscenario's. Als een bestand bijvoorbeeld een wijziging in een ACL en een kenmerkupdate tussen twee Robocopy-uitvoeringen ondervindt, wordt het gemarkeerd als verborgen. Zonder /IT kan de ACL-wijziging worden gemist door Robocopy en niet worden overgedragen naar de doellocatie. |
/COPY:[copyflags] |
De fidelity van de kopie van het bestand. Standaard: /COPY:DAT . Copy flags: D = Data, A = Attributes, T = Timestamps, S = Security = NTFS ACL's, O = Owner information, U = Auditing information. Controlegegevens kunnen niet worden opgeslagen in een Azure-bestandsshare. |
/DCOPY:[copyflags] |
Fidelity voor de kopie van mappen. Standaard: /DCOPY:DA . Copy flags: D = Data, A = Attributes, T = Timestamps. |
/NP |
Geeft aan dat de voortgang van de kopie voor elk bestand en elke map niet wordt weergegeven. Als de voortgang wordt weergegeven, zullen de prestaties aanzienlijk verminderen. |
/NFL |
Hiermee geeft u op dat bestandsnamen niet aan het logboek moeten worden toegevoegd. Verbetert de kopieerprestaties. |
/NDL |
Hiermee geeft u op dat mapnamen niet aan het logboek moeten worden toegevoegd. Verbetert de kopieerprestaties. |
/XD |
Hiermee geeft u mappen die moeten worden uitgesloten. Wanneer Robocopy wordt uitgevoerd op de hoofdmap van een volume, kunt u overwegen om de verborgen System Volume Information map uit te sluiten. Indien gebruikt zoals ontworpen, is alle informatie in die informatie specifiek voor het exacte volume op dit exacte systeem en kan worden herbouwd op aanvraag. Het kopiëren van deze informatie is niet handig in de cloud of wanneer de gegevens ooit worden gekopieerd naar een ander Windows-volume. Als u deze inhoud achterlaat, mag niet worden beschouwd als gegevensverlies. |
/UNILOG:<file name> |
Hiermee wordt de status naar het logboekbestand geschreven als Unicode. (Hiermee wordt het bestaande logboek overschreven.) |
/L |
Alleen voor een testuitvoeringsbestanden worden alleen weergegeven. Ze worden niet gekopieerd, niet verwijderd en krijgen geen tijdstempel. Vaak gebruikt met /TEE voor console-uitvoer. Vlaggen uit het voorbeeldscript, zoals /NP , /NFL en /NDL , moeten mogelijk worden verwijderd om u goed gedocumenteerde testresultaten te bereiken. |
/LFSM |
Alleen voor doelen met gelaagde opslag. Niet ondersteund wanneer de bestemming een externe SMB-share is. Hiermee geeft u op dat Robocopy werkt in de modus 'weinig vrije ruimte'. Deze switch is alleen nuttig voor doelen met gelaagde opslag die mogelijk geen lokale capaciteit meer heeft voordat Robocopy is voltooid. Het is specifiek toegevoegd voor gebruik met een doel dat is ingeschakeld voor opslag in cloudlagen van Azure File Sync. Het kan onafhankelijk van Azure File Sync worden gebruikt. In deze modus wordt Robocopy onderbroken wanneer een bestandskopie ervoor zorgt dat de vrije ruimte van het doelvolume onder de 'bodem'-waarde gaat. Deze waarde kan worden opgegeven door de /LFSM:n vorm van de vlag. De parameter n is opgegeven in basis 2: nKB , nMB of nGB . Als /LFSM deze is opgegeven zonder expliciete vloerwaarde, wordt de vloer ingesteld op 10 procent van de grootte van het doelvolume. De modus Weinig vrije ruimte is niet compatibel met /MT , /EFSRAW of /ZB . Ondersteuning voor /B is toegevoegd in Windows Server 2022. Zie de sectie Windows Server 2022 en RoboCopy LFSM hieronder voor meer informatie over een gerelateerde fout en tijdelijke oplossing. |
/Z |
Gebruik voorzichtig Bestanden kopiëren in de modus voor opnieuw opstarten. Deze switch wordt alleen aanbevolen in een instabiele netwerkomgeving. Het vermindert de kopieerprestaties aanzienlijk vanwege extra logboekregistratie. |
/ZB |
Gebruik voorzichtig de modus Opnieuw opstarten. Deze optie gebruikt de back-upmodus als de toegang is geweigerd. Deze optie vermindert de kopieerprestaties aanzienlijk vanwege controlepunten. |
Belangrijk
U wordt aangeraden een Windows Server 2022 te gebruiken. Wanneer u een Windows Server 2019 gebruikt, moet u ervoor zorgen dat op het laatste patchniveau of ten minste KB5005103 besturingssysteemupdate is geïnstalleerd. Het bevat belangrijke oplossingen voor bepaalde Robocopy-scenario's.
Fase 6: De Azure File Sync-cloudresource implementeren
Voordat u verdergaat met deze handleiding, wacht u totdat al uw bestanden zijn aangekomen in de juiste Azure-bestandsshares. Het proces van verzending en opname van Data Box-gegevens duurt even.
U hebt uw Azure-abonnementsreferenties nodig om deze stap te voltooien.
De kernresource die moet worden geconfigureerd voor Azure File Sync wordt een opslagsynchronisatieservice genoemd. We raden u aan slechts één te implementeren voor alle servers die dezelfde set bestanden nu of in de toekomst synchroniseren. Maak alleen meerdere opslagsynchronisatieservices als u afzonderlijke sets servers hebt die nooit gegevens mogen uitwisselen. U hebt bijvoorbeeld servers die nooit dezelfde Azure-bestandsshare mogen synchroniseren. Anders is het gebruik van één opslagsynchronisatieservice de best practice.
Kies een Azure-regio voor uw opslagsynchronisatieservice die zich dicht bij uw locatie bevindt. Alle andere cloudresources moeten in dezelfde regio worden geïmplementeerd. Maak een nieuwe resourcegroep in uw abonnement waarin synchronisatie- en opslagresources zijn opgenomen om het beheer te vereenvoudigen.
Zie de sectie over het implementeren van de opslagsynchronisatieservice in het artikel over het implementeren van Azure File Sync voor meer informatie. Volg alleen deze sectie van het artikel. In latere stappen vindt u koppelingen naar andere secties van het artikel.
Fase 7: De Azure File Sync-agent implementeren
In deze sectie installeert u de Azure File Sync-agent op uw Windows Server-exemplaar.
In de implementatiehandleiding wordt uitgelegd dat u verbeterde beveiliging van Internet Explorer moet uitschakelen. Deze beveiligingsmaatregel is niet van toepassing op Azure File Sync. Als u dit uitschakelt, kunt u zonder problemen verifiëren bij Azure.
Open PowerShell. Installeer de vereiste PowerShell-modules met behulp van de volgende opdrachten. Installeer de volledige module en de NuGet-provider wanneer u hierom wordt gevraagd.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
Als u problemen ondervindt met het bereiken van internet vanaf uw server, is het nu de tijd om ze op te lossen. Azure File Sync maakt gebruik van een beschikbare netwerkverbinding met internet. Het vereisen van een proxyserver om internet te bereiken, wordt ook ondersteund. U kunt nu een proxy voor de hele machine configureren of tijdens de installatie van de agent een proxy opgeven die alleen door Azure File Sync wordt gebruikt.
Als het configureren van een proxy betekent dat u uw firewalls voor de server moet openen, is deze benadering mogelijk acceptabel voor u. Nadat u de serverregistratie hebt voltooid, ziet u aan het einde van de serverinstallatie de exacte eindpunt-URL's in Azure waarmee Azure File Sync moet communiceren voor de regio die u hebt geselecteerd. Het rapport geeft ook aan waarom communicatie nodig is. U kunt het rapport gebruiken om de firewalls rond de server te vergrendelen voor specifieke URL's.
U kunt ook een meer conservatieve benadering gebruiken waarbij u de firewalls niet breed opent. U kunt in plaats daarvan de server beperken om te communiceren met DNS-naamruimten op een hoger niveau. Zie azure File Sync-proxy- en firewallinstellingen voor meer informatie. Volg uw eigen best practices voor netwerken.
Aan het einde van de installatiewizard van de server wordt een wizard serverregistratie geopend. Registreer de server bij de Azure-resource van uw opslagsynchronisatieservice van eerder.
Deze stappen worden uitgebreid beschreven in de implementatiehandleiding, waaronder de PowerShell-modules die u als eerste moet installeren: installatie van de Azure File Sync-agent.
Gebruik de nieuwste agent. U kunt het downloaden via het Microsoft Downloadcentrum: Azure File Sync Agent.
Na een geslaagde installatie en serverregistratie kunt u bevestigen dat u deze stap hebt voltooid. Ga naar de opslagsynchronisatieserviceresource in Azure Portal. Ga in het linkermenu naar Geregistreerde servers. U ziet dat uw server daar wordt vermeld.
Fase 8: Azure File Sync configureren op het Windows Server-exemplaar
Uw geregistreerde on-premises Windows Server-exemplaar moet gereed zijn en zijn verbonden met internet voor dit proces.
Deze stap verbindt alle resources en mappen die u tijdens de vorige stappen hebt ingesteld op uw Windows Server-exemplaar.
- Meld u aan bij het Azure-portaal.
- Zoek de opslagsynchronisatieserviceresource.
- Maak een nieuwe synchronisatiegroep in de Storage Sync Service-resource voor elke Azure-bestandsshare. In Azure File Sync-terminologie wordt de Azure-bestandsshare een cloudeindpunt in de synchronisatietopologie die u beschrijft met het maken van een synchronisatiegroep. Wanneer u de synchronisatiegroep maakt, geeft u deze een vertrouwde naam zodat u kunt herkennen welke set bestanden daar wordt gesynchroniseerd. Zorg ervoor dat u verwijst naar de Azure-bestandsshare met een overeenkomende naam.
- Nadat u de synchronisatiegroep hebt gemaakt, wordt er een rij voor deze weergegeven in de lijst met synchronisatiegroepen. Selecteer de naam (een koppeling) om de inhoud van de synchronisatiegroep weer te geven. U ziet uw Azure-bestandsshare onder Cloud-eindpunten.
- Zoek de knop Servereindpunt toevoegen. De map op de lokale server die u hebt ingericht, wordt het pad voor dit servereindpunt.
Schakel de functie voor cloudlagen in en selecteer alleen Naamruimte in de eerste downloadsectie.
Belangrijk
Cloudlagen zijn de Azure File Sync-functie waarmee de lokale server minder opslagcapaciteit kan hebben dan is opgeslagen in de cloud, maar de volledige naamruimte beschikbaar is. Lokaal interessante gegevens worden ook lokaal in de cache opgeslagen voor snelle toegangsprestaties. Cloudlagen zijn optioneel. U kunt deze afzonderlijk instellen voor elk Azure File Sync-servereindpunt. U moet deze functie gebruiken als u onvoldoende lokale schijfcapaciteit hebt op het Windows Server-exemplaar om alle cloudgegevens op te houden en u wilt voorkomen dat alle gegevens uit de cloud worden gedownload.
Herhaal de stappen voor het maken van synchronisatiegroepen en om de overeenkomende servermappen toe te voegen als servereindpunten voor alle Azure-bestandsshares/-serverlocaties die u voor synchronisatie moet configureren. Wacht totdat de synchronisatie van de naamruimte is voltooid. In de volgende sectie wordt uitgelegd hoe u ervoor kunt zorgen dat de synchronisatie is voltooid.
Notitie
Nadat u een servereindpunt hebt gemaakt, werkt de synchronisatie. Synchronisatie moet echter de bestanden en mappen die u via Data Box hebt verplaatst, inventariseren (detecteren) naar de Azure-bestandsshare. Afhankelijk van de grootte van de naamruimte kan het lang duren voordat de naamruimte uit de cloud op de server wordt weergegeven.
Fase 9: Wacht tot de naamruimte volledig op de server wordt weergegeven
Voordat u doorgaat met de volgende stappen van uw migratie, wacht u totdat de server de naamruimte volledig heeft gedownload van de cloudshare. Als u te vroeg begint met het verplaatsen van bestanden naar de server, riskeert u onnodige uploads en zelfs conflicten met bestandssynchronisatie.
Als u wilt bepalen of uw server de initiële downloadsynchronisatie heeft voltooid, opent u Logboeken op het synchroniserende Windows Server-exemplaar en gebruikt u het gebeurtenislogboek van De Azure File Sync-telemetrie. Het telemetrielogboek bevindt zich in Logboeken onder Toepassingen en Services\Microsoft\FileSync\Agent.
Zoek naar de meest recente gebeurtenis van 9102.
Gebeurtenis-id 9102 wordt geregistreerd wanneer een synchronisatiesessie is voltooid. In de gebeurtenistekst is er een veld voor de downloadsynchronisatierichting. (HResult
moet nul zijn en bestanden moeten worden gedownload.)
U wilt twee opeenvolgende gebeurtenissen van dit type zien, met deze inhoud, om ervoor te zorgen dat de server klaar is met het downloaden van de naamruimte. Het is ok als er andere gebeurtenissen zijn tussen de twee 9102-gebeurtenissen.
Fase 10: Robocopy uitvoeren vanaf uw NAS
Nadat de server de eerste synchronisatie van de volledige naamruimte vanuit de cloudshare heeft voltooid, kunt u doorgaan met deze stap. De eerste synchronisatie moet zijn voltooid voordat u doorgaat met deze stap. Zie de vorige sectie voor meer informatie.
In deze stap voert u Robocopy-taken uit om uw cloudshares te synchroniseren met de meest recente wijzigingen op uw NAS die zich hebben voorgedaan sinds u uw shares hebt gesplitst in de Data Box. Deze Robocopy-uitvoering kan snel of even duren, afhankelijk van het verloop dat is opgetreden op uw NAS-shares.
Waarschuwing
Vanwege teruggedraaid Robocopy-gedrag in Windows Server 2019 is de Robocopy-switch /MIR
niet compatibel met gelaagde doelmappen. U kunt geen Windows Server 2019- of Windows 10-client gebruiken voor deze fase van de migratie. Robocopy gebruiken op een tussenliggend Windows Server 2016-exemplaar.
Dit is de basismigratiebenadering:
- Voer Robocopy uit vanaf uw NAS-apparaat om uw Windows Server-exemplaar te synchroniseren.
- Gebruik Azure File Sync om de Azure-bestandsshares van Windows Server te synchroniseren.
Voer de eerste lokale kopie uit naar de doelmap van Windows Server:
- Identificeer de eerste locatie op uw NAS-apparaat.
- Identificeer de overeenkomende map op het Windows Server-exemplaar waarop Azure File Sync al is geconfigureerd.
- Start de kopie met Behulp van Robocopy.
Met de volgende Robocopy-opdracht worden alleen de verschillen (bijgewerkte bestanden en mappen) van uw NAS-opslag naar de doelmap van Windows Server gekopieerd. Het Windows Server-exemplaar synchroniseert deze vervolgens met de Azure-bestandsshares.
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Switch | Betekenis |
---|---|
/MT:n |
Met Robocopy kunnen meerdere threads worden uitgevoerd. De standaardwaarde n is 8. Het maximum is 128 threads. Hoewel een hoog aantal threads helpt de beschikbare bandbreedte te verzadigen, betekent dit niet dat uw migratie altijd sneller is met meer threads. Tests met Azure Files geven aan dat tussen 8 en 20 evenwichtige prestaties worden weergegeven voor een eerste kopieerbewerking. Volgende /MIR uitvoeringen worden geleidelijk beïnvloed door de beschikbare rekenkracht versus de beschikbare netwerkbandbreedte. Voor volgende uitvoeringen moet u de waarde van het aantal threads nauwkeuriger overeen laten komen met het aantal processorkernen en het aantal threads per kern. Overweeg of kernen moeten worden gereserveerd voor andere taken die een productieserver mogelijk heeft. Tests met Azure Files hebben aangetoond dat maximaal 64 threads een goede prestaties opleveren, maar alleen als uw processors ze tegelijkertijd in leven kunnen houden. |
/R:n |
Het Maximum aantal nieuwe pogingen voor een bestand dat niet kan worden gekopieerd bij de eerste poging. Robocopy probeert n tijden voordat het bestand permanent niet kan worden gekopieerd in de uitvoering. U kunt de prestaties van uw uitvoering optimaliseren: kies een waarde van twee of drie als u denkt dat time-outproblemen in het verleden fouten hebben veroorzaakt. Dit kan vaker voorkomen via WAN-koppelingen. Kies geen nieuwe poging of een waarde als u denkt dat het bestand niet kan worden gekopieerd omdat het actief in gebruik was. Als u het een paar seconden later opnieuw probeert, is het mogelijk niet voldoende om de status in gebruik van het bestand te wijzigen. Gebruikers of apps die het bestand openen houden, hebben mogelijk uren meer tijd nodig. In dit geval is het accepteren van het bestand niet gekopieerd en in een van uw geplande, volgende Robocopy-uitvoeringen, mogelijk geslaagd om het bestand uiteindelijk te kopiëren. Dit helpt de huidige uitvoering sneller te voltooien zonder te worden verlengd door veel nieuwe pogingen die uiteindelijk in een meerderheid van de kopieerfouten terechtkomen omdat bestanden nog steeds zijn geopend na de time-out voor opnieuw proberen. |
/W:n |
Specificeert de tijd dat Robocopy wacht voordat wordt geprobeerd een bestand te kopiëren dat niet is gekopieerd tijdens een vorige poging. n is het aantal seconden dat moet worden gewacht tussen nieuwe pogingen. /W:n wordt vaak samen met /R:n . |
/B |
Voert Robocopy uit in dezelfde modus die een back-uptoepassing zou gebruiken. Met deze switch kan Robocopy bestanden verplaatsen waarvoor de huidige gebruiker geen machtigingen heeft. De back-upswitch is afhankelijk van het uitvoeren van de Robocopy-opdracht in een console met verhoogde beheerdersrechten of PowerShell-venster. Als u Robocopy voor Azure Files gebruikt, moet u ervoor zorgen dat u de Azure-bestandsshare koppelt met behulp van de toegangssleutel voor het opslagaccount versus een domeinidentiteit. Als u dat niet doet, leiden de foutberichten mogelijk niet intuïtief tot een oplossing van het probleem. |
/MIR |
(Sspiegelen van bron naar doel.) Hiermee kan Robocopy alleen delta's kopiëren tussen bron en doel. Lege submappen worden gekopieerd. Items (bestanden of mappen) die zijn gewijzigd of die niet bestaan in het doel, worden gekopieerd. Items die aanwezig zijn in het doel, maar niet in de bron, worden opgeschoond (verwijderd) uit het doel. Wanneer u deze switch gebruikt, moeten de bron- en doelmapstructuren exact overeenkomen. Vergelijking betekent dat u kopieert van het juiste bron- en mapniveau naar het overeenkomende mapniveau op het doel. Alleen dan kan een 'inhaalkopie' succesvol zijn. Wanneer de bron en het doel niet overeenkomen, leidt het gebruik /MIR tot grootschalige verwijderingen en nieuwe bereiken. |
/IT |
Zorgt dat de betrouwbaarheid behouden blijft in bepaalde spiegelscenario's. Als een bestand bijvoorbeeld een wijziging in een ACL en een kenmerkupdate tussen twee Robocopy-uitvoeringen ondervindt, wordt het gemarkeerd als verborgen. Zonder /IT kan de ACL-wijziging worden gemist door Robocopy en niet worden overgedragen naar de doellocatie. |
/COPY:[copyflags] |
De fidelity van de kopie van het bestand. Standaard: /COPY:DAT . Copy flags: D = Data, A = Attributes, T = Timestamps, S = Security = NTFS ACL's, O = Owner information, U = Auditing information. Controlegegevens kunnen niet worden opgeslagen in een Azure-bestandsshare. |
/DCOPY:[copyflags] |
Fidelity voor de kopie van mappen. Standaard: /DCOPY:DA . Copy flags: D = Data, A = Attributes, T = Timestamps. |
/NP |
Geeft aan dat de voortgang van de kopie voor elk bestand en elke map niet wordt weergegeven. Als de voortgang wordt weergegeven, zullen de prestaties aanzienlijk verminderen. |
/NFL |
Hiermee geeft u op dat bestandsnamen niet aan het logboek moeten worden toegevoegd. Verbetert de kopieerprestaties. |
/NDL |
Hiermee geeft u op dat mapnamen niet aan het logboek moeten worden toegevoegd. Verbetert de kopieerprestaties. |
/XD |
Hiermee geeft u mappen die moeten worden uitgesloten. Wanneer Robocopy wordt uitgevoerd op de hoofdmap van een volume, kunt u overwegen om de verborgen System Volume Information map uit te sluiten. Indien gebruikt zoals ontworpen, is alle informatie in die informatie specifiek voor het exacte volume op dit exacte systeem en kan worden herbouwd op aanvraag. Het kopiëren van deze informatie is niet handig in de cloud of wanneer de gegevens ooit worden gekopieerd naar een ander Windows-volume. Als u deze inhoud achterlaat, mag niet worden beschouwd als gegevensverlies. |
/UNILOG:<file name> |
Hiermee wordt de status naar het logboekbestand geschreven als Unicode. (Hiermee wordt het bestaande logboek overschreven.) |
/L |
Alleen voor een testuitvoeringsbestanden worden alleen weergegeven. Ze worden niet gekopieerd, niet verwijderd en krijgen geen tijdstempel. Vaak gebruikt met /TEE voor console-uitvoer. Vlaggen uit het voorbeeldscript, zoals /NP , /NFL en /NDL , moeten mogelijk worden verwijderd om u goed gedocumenteerde testresultaten te bereiken. |
/LFSM |
Alleen voor doelen met gelaagde opslag. Niet ondersteund wanneer de bestemming een externe SMB-share is. Hiermee geeft u op dat Robocopy werkt in de modus 'weinig vrije ruimte'. Deze switch is alleen nuttig voor doelen met gelaagde opslag die mogelijk geen lokale capaciteit meer heeft voordat Robocopy is voltooid. Het is specifiek toegevoegd voor gebruik met een doel dat is ingeschakeld voor opslag in cloudlagen van Azure File Sync. Het kan onafhankelijk van Azure File Sync worden gebruikt. In deze modus wordt Robocopy onderbroken wanneer een bestandskopie ervoor zorgt dat de vrije ruimte van het doelvolume onder de 'bodem'-waarde gaat. Deze waarde kan worden opgegeven door de /LFSM:n vorm van de vlag. De parameter n is opgegeven in basis 2: nKB , nMB of nGB . Als /LFSM deze is opgegeven zonder expliciete vloerwaarde, wordt de vloer ingesteld op 10 procent van de grootte van het doelvolume. De modus Weinig vrije ruimte is niet compatibel met /MT , /EFSRAW of /ZB . Ondersteuning voor /B is toegevoegd in Windows Server 2022. Zie de sectie Windows Server 2022 en RoboCopy LFSM hieronder voor meer informatie over een gerelateerde fout en tijdelijke oplossing. |
/Z |
Gebruik voorzichtig Bestanden kopiëren in de modus voor opnieuw opstarten. Deze switch wordt alleen aanbevolen in een instabiele netwerkomgeving. Het vermindert de kopieerprestaties aanzienlijk vanwege extra logboekregistratie. |
/ZB |
Gebruik voorzichtig de modus Opnieuw opstarten. Deze optie gebruikt de back-upmodus als de toegang is geweigerd. Deze optie vermindert de kopieerprestaties aanzienlijk vanwege controlepunten. |
Belangrijk
U wordt aangeraden een Windows Server 2022 te gebruiken. Wanneer u een Windows Server 2019 gebruikt, moet u ervoor zorgen dat op het laatste patchniveau of ten minste KB5005103 besturingssysteemupdate is geïnstalleerd. Het bevat belangrijke oplossingen voor bepaalde Robocopy-scenario's.
Als u minder opslag hebt ingericht op uw Windows Server-exemplaar dan uw bestanden op het NAS-apparaat gebruiken, hebt u cloudlagen geconfigureerd. Naarmate het lokale Windows Server-volume vol wordt, worden cloudlagen geactiveerd en worden bestanden die al zijn gesynchroniseerd, geactiveerd. Met cloudlagen wordt voldoende ruimte gegenereerd om de kopie van het NAS-apparaat voort te zetten. In cloudlagen wordt eenmaal per uur gecontroleerd om te bepalen wat er is gesynchroniseerd en om schijfruimte vrij te maken om de vrije ruimte van 99 procent te bereiken.
Robocopy moet mogelijk meer bestanden verplaatsen dan u lokaal kunt opslaan op het Windows Server-exemplaar. U kunt verwachten dat Robocopy sneller wordt verplaatst dan Azure File Sync uw bestanden kan uploaden en ze van uw lokale volume kunt tieren. In deze situatie mislukt Robocopy. U wordt aangeraden de shares in een reeks te doorlopen die dit scenario voorkomt. Verplaats bijvoorbeeld alleen shares die passen in de beschikbare vrije ruimte op het Windows Server-exemplaar. Of vermijd het starten van Robocopy-taken voor alle shares tegelijk. Het goede nieuws is dat de /MIR
switch ervoor zorgt dat alleen delta's worden verplaatst. Nadat een delta is verplaatst, hoeft een opnieuw gestarte taak het bestand niet opnieuw te verplaatsen.
De cutover uitvoeren
Wanneer u de Robocopy-opdracht voor het eerst uitvoert, hebben uw gebruikers en toepassingen nog steeds toegang tot bestanden op de NAS en kunnen ze worden gewijzigd. Robocopy verwerkt een map en gaat vervolgens verder met de volgende map. Een gebruiker op de NAS kan vervolgens een bestand toevoegen, wijzigen of verwijderen in de eerste map die niet wordt verwerkt tijdens de huidige Robocopy-uitvoering. Dit gedrag is verwacht.
De eerste uitvoering gaat over het verplaatsen van het grootste deel van de gegevens naar uw Windows Server-exemplaar en naar de cloud via Azure File Sync. Dit eerste exemplaar kan lang duren, afhankelijk van:
- De uploadbandbreedte.
- De snelheid van het lokale netwerk en hoe optimaal het aantal Robocopy-threads overeenkomt.
- Het aantal items (bestanden en mappen) dat moet worden verwerkt door Robocopy en Azure File Sync.
Nadat de eerste uitvoering is voltooid, voert u de opdracht opnieuw uit.
Robocopy wordt sneller voltooid de tweede keer dat u deze uitvoert voor een share. Het moet alleen wijzigingen transporteren die zijn opgetreden sinds de laatste uitvoering. U kunt herhaalde taken uitvoeren voor dezelfde share.
Wanneer u rekening houdt met downtime die acceptabel is, moet u gebruikerstoegang tot uw NAS-shares verwijderen. U kunt dit op elke manier doen waardoor gebruikers de bestands- en mapstructuur en de inhoud niet kunnen wijzigen. U kunt uw DFS-naamruimte bijvoorbeeld verwijzen naar een locatie die niet bestaat of de hoofd-ACL's op de share wijzigen.
Voer Robocopy nog één keer uit. Hiermee worden eventuele wijzigingen opgehaald die zijn gemist. Hoe lang deze laatste stap duurt, is afhankelijk van de snelheid van de Robocopy-scan. U kunt een schatting maken van de tijd (die gelijk is aan uw downtime) door de lengte van de vorige uitvoering te meten.
Maak een share in de map Windows Server en pas de DFS-N-implementatie mogelijk aan zodat deze verwijst. Zorg ervoor dat u dezelfde machtigingen op shareniveau instelt die zich op uw NAS SMB-share bevinden. Als u een bedrijfsklasse NAS hebt die lid is van een domein, komen de gebruikers-SID's automatisch overeen omdat de gebruikers zich in Active Directory bevinden en Robocopy bestanden en metagegevens met volledige betrouwbaarheid kopieert. Als u lokale gebruikers op uw NAS hebt gebruikt, moet u het volgende doen:
- Maak deze gebruikers opnieuw als lokale gebruikers van Windows Server.
- Wijs de bestaande SID's toe die Robocopy naar uw Windows Server-exemplaar heeft verplaatst naar de SID's van uw nieuwe lokale Gebruikers van Windows Server.
U bent klaar met het migreren van een share of groep shares naar een gemeenschappelijke hoofdmap of -volume (afhankelijk van uw toewijzing van fase 1).
U kunt proberen een aantal van deze kopieën parallel uit te voeren. U wordt aangeraden het bereik van één Azure-bestandsshare tegelijk te verwerken.
Afgeschafte optie: 'offline gegevensoverdracht'
Voordat azure File Sync-agent versie 13 werd uitgebracht, werd Data Box-integratie uitgevoerd via een proces met de naam 'offline gegevensoverdracht'. Dit proces is afgeschaft en u kunt geen servereindpunt meer maken in de modus 'offlinegegevensoverdracht'. Met agentversie 13 is deze vervangen door de veel eenvoudigere en snellere stappen die in dit artikel worden beschreven.
Probleemoplossing
Het meest voorkomende probleem is dat de Robocopy-opdracht mislukt met 'Volume vol' aan de zijde van Windows Server. Opslag in cloudlagen werkt één keer per uur om inhoud te evacueren vanaf de lokale Windows Server-schijf die is gesynchroniseerd. Het doel is om uw vrije ruimte van 99 procent op het volume te bereiken.
Laat de voortgang van de synchronisatie en opslag in cloudlagen schijfruimte vrijmaken. U kunt dat zien in Bestandenverkenner op uw Windows Server-exemplaar.
Wanneer uw Windows Server-exemplaar voldoende beschikbare capaciteit heeft, voert u de opdracht opnieuw uit om het probleem op te lossen. Niets breekt in deze situatie. U kunt met vertrouwen vooruitgaan. Het ongemak van het opnieuw uitvoeren van de opdracht is het enige gevolg.
Zie het artikel in de volgende sectie voor het oplossen van problemen met Azure File Sync.
Volgende stappen
In de volgende artikelen vindt u meer informatie over geavanceerde opties en aanbevolen procedures voor Azure Files en Azure File Sync.