Använda Data Box för att migrera från nätverksansluten lagring (NAS) till en hybridmolndistribution med hjälp av Azure File Sync

Den här migreringsartikeln är en av flera som gäller för nyckelorden NAS, Azure File Sync och Azure Data Box. Kontrollera om den här artikeln gäller för ditt scenario:

• Datakälla: Nätverksansluten lagring (NAS)
• Migreringsväg: NAS ⇒ Data Box ⇒ Azure-filresurs ⇒ synkronisering med Windows Server
• Cachelagring av filer lokalt: Ja, det sista målet är en Azure File Sync-distribution

Om ditt scenario är annorlunda kan du titta igenom tabellen med migreringsguider.

Azure File Sync fungerar på DAS-platser (Direct Attached Storage). Den stöder inte synkronisering till NAS-platser (Network Attached Storage). Så du måste migrera dina filer. Den här artikeln vägleder dig genom planering och implementering av migreringen.

Gäller för

Typ av filresurs	SMB	NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premiumfilresurser (FileStorage), LRS/ZRS

Migreringsmål

Målet är att flytta de resurser som du har på DIN NAS-installation till Windows Server. Sedan använder du Azure File Sync för en hybridmolndistribution. Den här migreringen måste göras på ett sätt som garanterar integriteten för produktionsdata och tillgänglighet under migreringen. Det senare kräver att stilleståndstiden hålls till ett minimum så att den uppfyller eller bara något överskrider regelbundna underhållsperioder.

Migreringsöversikt

Migreringsprocessen består av flera faser. Du behöver:

• Distribuera Azure Storage-konton och filresurser.
• Distribuera en lokal dator som kör Windows Server.
• Konfigurera Azure File Sync.
• Migrera filer med robocopy.
• Gör cutover.

I följande avsnitt beskrivs faserna i migreringsprocessen i detalj.

Dricks

Om du återgår till den här artikeln använder du navigeringen till höger på skärmen för att gå vidare till migreringsfasen där du slutade.

Fas 1: Fastställa hur många Azure-filresurser du behöver

I det här steget avgör du hur många Azure-filresurser du behöver. En enda Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser.

Du kan ha fler mappar på dina volymer som du för närvarande delar lokalt som SMB-resurser till dina användare och appar. Det enklaste sättet att föreställa sig det här scenariot är att föreställa sig en lokal resurs som mappar 1:1 till en Azure-filresurs. Om du har ett tillräckligt litet antal resurser, under 30 för en enda Windows Server-instans, rekommenderar vi en 1:1-mappning.

Om du har fler än 30 resurser är det ofta onödigt att mappa en lokal resurs 1:1 till en Azure-filresurs. Överväg följande alternativ.

Dela gruppering

Om personalavdelningen till exempel har 15 resurser kan du överväga att lagra alla HR-data i en enda Azure-filresurs. Att lagra flera lokala resurser i en Azure-filresurs hindrar dig inte från att skapa de vanliga 15 SMB-resurserna på din lokala Windows Server-instans. Det innebär bara att du organiserar rotmapparna för dessa 15 resurser som undermappar under en gemensam mapp. Sedan synkroniserar du den här gemensamma mappen till en Azure-filresurs. På så sätt behövs bara en enda Azure-filresurs i molnet för den här gruppen med lokala resurser.

Volymsynkronisering

Azure File Sync stöder synkronisering av roten på en volym till en Azure-filresurs. Om du synkroniserar volymroten går alla undermappar och filer till samma Azure-filresurs.

Att synkronisera volymens rot är inte alltid det bästa alternativet. Det finns fördelar med att synkronisera flera platser. Om du till exempel gör det kan du hålla antalet objekt lägre per synkroniseringsomfång. Vi testar Azure-filresurser och Azure File Sync med 100 miljoner objekt (filer och mappar) per resurs. Men bästa praxis är att försöka hålla antalet under 20 miljoner eller 30 miljoner i en enda andel. Att konfigurera Azure File Sync med ett lägre antal objekt är inte bara fördelaktigt för filsynkronisering. Ett lägre antal objekt har också fördelar med scenarier som dessa:

• Den första genomsökningen av molninnehållet kan slutföras snabbare, vilket i sin tur minskar väntan på att namnområdet ska visas på en server som är aktiverad för Azure File Sync.
• Det går snabbare att återställa molnsidan från en Ögonblicksbild av Azure-filresursen.
• Haveriberedskapen för en lokal server kan påskyndas avsevärt.
• Ändringar som görs direkt i en Azure-filresurs (utanför synkroniseringen) kan identifieras och synkroniseras snabbare.

Dricks

Om du inte vet hur många filer och mappar du har kan du kolla in verktyget TreeSize från JAM Software GmbH.

En strukturerad metod för en distributionskarta

Innan du distribuerar molnlagring i ett senare steg är det viktigt att skapa en karta mellan lokala mappar och Azure-filresurser. Den här mappningen informerar hur många och vilka Azure File Sync-synkroniseringsgruppresurser du ska etablera. En synkroniseringsgrupp kopplar samman Azure-filresursen och mappen på servern och upprättar en synkroniseringsanslutning.

Information om hur många Azure-filresurser du behöver finns i följande begränsningar och metodtips. Om du gör det kan du optimera kartan.

• En server där Azure File Sync-agenten är installerad kan synkroniseras med upp till 30 Azure-filresurser.

• En Azure-filresurs distribueras i ett lagringskonto. Det här arrangemanget gör lagringskontot till ett skalningsmål för prestandanummer som IOPS och dataflöde.

  Var uppmärksam på IOPS-begränsningarna för ett lagringskonto när du distribuerar Azure-filresurser. Helst bör du mappa filresurser 1:1 med lagringskonton. Detta kanske dock inte alltid är möjligt på grund av olika gränser och begränsningar, både från din organisation och från Azure. När det inte är möjligt att bara ha en filresurs distribuerad på ett lagringskonto bör du överväga vilka resurser som är mycket aktiva och vilka resurser som är mindre aktiva för att säkerställa att de hetaste filresurserna inte sätts in på samma lagringskonto tillsammans.

  Om du planerar att lyfta en app till Azure som ska använda Azure-filresursen internt kan du behöva mer prestanda från din Azure-filresurs. Om den här typen av användning är en möjlighet, även i framtiden, är det bäst att skapa en enda Standard Azure-filresurs i sitt eget lagringskonto.

• Det finns en gräns på 250 lagringskonton per prenumeration per Azure-region.

Dricks

Med den här informationen blir det ofta nödvändigt att gruppera flera mappar på den översta nivån på dina volymer i en ny gemensam rotkatalog. Sedan synkroniserar du den nya rotkatalogen och alla mappar som du grupperade i den till en enda Azure-filresurs. Med den här tekniken kan du hålla dig inom gränsen på 30 Azure-filresurssynkroniseringar per server.

Den här gruppering under en vanlig rot påverkar inte åtkomsten till dina data. Dina ACL:er håller sig som de är. Du behöver bara justera eventuella resurssökvägar (till exempel SMB- eller NFS-resurser) som du kan ha på de lokala servermappar som du nu har ändrat till en gemensam rot. Inget annat ändras.

Viktigt!

Den viktigaste skalningsvektorn för Azure File Sync är antalet objekt (filer och mappar) som måste synkroniseras. Mer information finns i skalningsmålen för Azure File Sync.

Det är en bra idé att hålla antalet objekt per synkroniseringsomfång lågt. Det är en viktig faktor att tänka på i mappningen av mappar till Azure-filresurser. Azure File Sync testas med 100 miljoner objekt (filer och mappar) per resurs. Men det är ofta bäst att hålla antalet objekt under 20 miljoner eller 30 miljoner i en enda andel. Dela upp namnområdet i flera resurser om du börjar överskrida dessa tal. Du kan fortsätta att gruppera flera lokala resurser i samma Azure-filresurs om du ligger ungefär under dessa siffror. Den här metoden ger dig utrymme att växa.

Det är möjligt att en uppsättning mappar i din situation kan synkroniseras logiskt med samma Azure-filresurs (med hjälp av den nya gemensamma rotmappsmetoden som nämndes tidigare). Men det kan fortfarande vara bättre att omgruppera mappar så att de synkroniseras till två i stället för en Azure-filresurs. Du kan använda den här metoden för att hålla antalet filer och mappar per filresurs balanserade på servern. Du kan också dela upp dina lokala resurser och synkronisera mellan fler lokala servrar, vilket lägger till möjligheten att synkronisera med ytterligare 30 Azure-filresurser per extra server.

Vanliga scenarier och överväganden för filsynkronisering

#	Synkroniseringsscenario	Stöds	Överväganden (eller begränsningar)	Lösning (eller lösning)
1	Filserver med flera diskar/volymer och flera resurser till samma Azure-målfilresurs (konsolidering)	Nej	En Azure-målfilresurs (molnslutpunkt) stöder endast synkronisering med en synkroniseringsgrupp. En synkroniseringsgrupp stöder endast en serverslutpunkt per registrerad server.	1) Börja med att synkronisera en disk (dess rotvolym) för att rikta in sig på Azure-filresursen. Från och med den största disken/volymen hjälper det med lagringskraven lokalt. Konfigurera molnnivåindelning för att nivåindela alla data till molnet, vilket frigör utrymme på filserverdisken. Flytta data från andra volymer/resurser till den aktuella volymen som synkroniseras. Fortsätt stegen en i taget tills alla data har nivåindelats upp till molnet/migrerats. 2) Rikta in sig på en rotvolym (disk) i taget. Använd molnnivåindelning för att nivåindela alla data för att rikta in sig på Azure-filresurs. Ta bort serverslutpunkten från synkroniseringsgruppen, återskapa slutpunkten med nästa rotvolym/disk, synkronisera och upprepa processen. Obs! Ominstallation av agenten kan krävas. 3) Rekommenderar att du använder flera Azure-målfilresurser (samma eller ett annat lagringskonto baserat på prestandakrav)
2	Filserver med en enskild volym och flera resurser till samma Azure-målfilresurs (konsolidering)	Ja	Det går inte att ha flera serverslutpunkter per registrerad serversynkronisering till samma Azure-målfilresurs (samma som ovan)	Synkronisera roten på volymen som innehåller flera resurser eller mappar på den översta nivån. Mer information finns i Dela grupperingskoncept och Volymsynkronisering.
3	Filserver med flera resurser och/eller volymer till flera Azure-filresurser under ett enda lagringskonto (1:1 resursmappning)	Ja	En enda Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser. Ett lagringskonto är ett skalningsmål för prestanda. IOPS och dataflöde delas mellan filresurser. Behåll antalet objekt per synkroniseringsgrupp inom 100 miljoner objekt (filer och mappar) per resurs. Helst är det bäst att hålla sig under 20 eller 30 miljoner per aktie.	1) Använd flera synkroniseringsgrupper (antal synkroniseringsgrupper = antal Azure-filresurser att synkronisera med). 2) Endast 30 resurser kan synkroniseras i det här scenariot åt gången. Om du har fler än 30 resurser på filservern använder du konceptet Dela gruppering och Volymsynkronisering för att minska antalet rotmappar eller toppnivåmappar vid källan. 3) Använd ytterligare filsynkroniseringsservrar lokalt och dela upp/flytta data till dessa servrar för att kringgå begränsningar på Windows-källservern.
4	Filserver med flera resurser och/eller volymer till flera Azure-filresurser under ett annat lagringskonto (1:1 resursmappning)	Ja	En enskild Windows Server-instans (eller ett kluster) kan synkronisera upp till 30 Azure-filresurser (samma eller ett annat lagringskonto). Behåll antalet objekt per synkroniseringsgrupp inom 100 miljoner objekt (filer och mappar) per resurs. Helst är det bäst att hålla sig under 20 eller 30 miljoner per aktie.	Samma metod som ovan
5	Flera filservrar med enskild (rotvolym eller resurs) till samma Azure-målfilresurs (konsolidering)	Nej	En synkroniseringsgrupp kan inte använda molnslutpunkt (Azure-filresurs) som redan har konfigurerats i en annan synkroniseringsgrupp. Även om en synkroniseringsgrupp kan ha serverslutpunkter på olika filservrar kan filerna inte vara distinkta.	Följ vägledningen i scenario nr 1 ovan med ytterligare övervägande av att rikta in sig på en filserver i taget.

Skapa en mappningstabell

Använd den tidigare informationen för att avgöra hur många Azure-filresurser du behöver och vilka delar av dina befintliga data som ska hamna i vilken Azure-filresurs.

Skapa en tabell som registrerar dina tankar så att du kan referera till den när du behöver det. Det är viktigt att hålla ordning eftersom det kan vara enkelt att förlora information om din mappningsplan när du etablerar många Azure-resurser samtidigt. Ladda ned följande Excel-fil som ska användas som mall för att skapa mappningen.

Ladda ned en mall för namnområdesmappning.

Fas 2: Distribuera Azure Storage-resurser

I den här fasen läser du mappningstabellen från fas 1 och använder den för att etablera rätt antal Azure-lagringskonton och filresurser i dem.

En Azure-filresurs lagras i molnet på ett Azure-lagringskonto. En annan nivå av prestandaöverväganden gäller här.

Om du har mycket aktiva resurser (resurser som används av många användare och/eller program) kan två Azure-filresurser nå prestandagränsen för ett lagringskonto.

Bästa praxis är att distribuera lagringskonton med en filresurs var. Du kan poola flera Azure-filresurser till samma lagringskonto om du har arkivresurser eller om du förväntar dig låg daglig aktivitet i dem.

Dessa överväganden gäller mer för direkt molnåtkomst (via en virtuell Azure-dator) än för Azure File Sync. Om du endast planerar att använda Azure File Sync på dessa resurser är det bra att gruppera flera till ett enda Azure Storage-konto.

Om du har gjort en lista över dina resurser bör du mappa varje resurs till det lagringskonto som den kommer att finnas i.

I föregående fas fastställde du lämpligt antal resurser. I det här steget har du en mappning av lagringskonton till filresurser. Distribuera nu lämpligt antal Azure-lagringskonton med lämpligt antal Azure-filresurser i dem.

Kontrollera att regionen för vart och ett av dina lagringskonton är densamma och matchar regionen för den Storage Sync Service-resurs som du redan har distribuerat.

Varning

Om du skapar en Azure-filresurs som har en gräns på 100 TiB kan den resursen endast använda lokalt redundant lagring eller zonredundanta alternativ för lagringsredundans. Överväg dina behov av lagringsredundans innan du använder 100 TiB-filresurser.

Azure-filresurser skapas fortfarande med en 5 TiB-gräns som standard. Följ stegen i Skapa en Azure-filresurs för att skapa en stor filresurs.

Ett annat att tänka på när du distribuerar ett lagringskonto är redundansen i Azure Storage. Se Redundansalternativ för Azure Storage.

Namnen på dina resurser är också viktiga. Om du till exempel grupperar flera resurser för HR-avdelningen till ett Azure-lagringskonto bör du namnge lagringskontot på rätt sätt. När du namnger dina Azure-filresurser bör du på samma sätt använda namn som liknar de som används för deras lokala motsvarigheter.

Fas 3: Fastställa hur många Azure Data Box-enheter du behöver

Starta det här steget först när du har slutfört föregående fas. Dina Azure Storage-resurser (lagringskonton och filresurser) bör skapas just nu. När du beställer Data Box måste du ange de lagringskonton som Data Box flyttar data till.

I den här fasen måste du mappa resultatet av migreringsplanen från föregående fas till gränserna för tillgängliga Data Box-alternativ. Dessa överväganden hjälper dig att skapa en plan för vilka Data Box-alternativ du vill välja och hur många av dem du behöver för att flytta dina NAS-resurser till Azure-filresurser.

Tänk på följande viktiga begränsningar för att avgöra hur många enheter du behöver och deras typer:

• Alla Azure Data Box-installationer kan flytta data till upp till 10 lagringskonton.
• Varje Data Box-alternativ levereras med sin egen användbara kapacitet. Se Alternativ för Data Box.

Läs din migreringsplan för att hitta det antal lagringskonton som du har valt att skapa och resurserna i var och en. Titta sedan på storleken på var och en av resurserna på din NAS. Genom att kombinera den här informationen kan du optimera och bestämma vilken installation som ska skicka data till vilka lagringskonton. Två Data Box-enheter kan flytta filer till samma lagringskonto, men dela inte upp innehållet i en enda filresurs i två datarutor.

Data Box-alternativ

För en standardmigrering väljer du en eller en kombination av dessa Data Box-alternativ:

• Data Box Disk. Microsoft skickar dig mellan en och fem SSD-diskar som har en kapacitet på 8 TiB vardera, för maximalt 40 TiB. Den användbara kapaciteten är cirka 20 procent mindre på grund av kryptering och omkostnader för filsystemet. Mer information finns i Dokumentation om Data Box Disk.
• Data Box. Det här alternativet är det vanligaste. Microsoft skickar en robust Data Box-installation som fungerar ungefär som en NAS. Den har en användbar kapacitet på 80 TiB. Mer information finns i Dokumentation om Data Box.
• Data Box Heavy. Det här alternativet har en robust Data Box-apparat på hjul som fungerar ungefär som en NAS. Den har en kapacitet på 1 PiB. Den användbara kapaciteten är cirka 20 procent mindre på grund av kryptering och omkostnader för filsystemet. Mer information finns i Dokumentation om Data Box Heavy.

Fas 4: Etablera en lämplig Lokal Windows Server-instans

Medan du väntar på att dina Azure Data Box-enheter ska komma kan du börja granska behoven för en eller flera Windows Server-instanser som du använder med Azure File Sync.

• Skapa en Windows Server 2022-instans (minst Windows Server 2012 R2) som en virtuell dator eller fysisk server. Ett Windows Server-redundanskluster stöds också.
• Etablera eller lägg till direktansluten lagring. NAS stöds inte.

Resurskonfigurationen (beräkning och RAM) för den Windows Server-instans som du distribuerar beror främst på antalet filer och mappar som du ska synkronisera. Vi rekommenderar en konfiguration med högre prestanda om du har några problem.

Lär dig hur du ändrar storlek på en Windows Server-instans baserat på antalet objekt som du behöver synkronisera.

Kommentar

Den tidigare länkade artikeln innehåller en tabell med ett intervall för serverminne (RAM). Du kan använda tal i den nedre änden av intervallet för servern, men förvänta dig att den inledande synkroniseringen tar betydligt längre tid.

Fas 5: Kopiera filer till din Data Box

När din Data Box anländer måste du konfigurera den med obehindrat nätverksanslutning till DIN NAS-installation. Följ installationsdokumentationen för den typ av Data Box som du har beställt:

• Konfigurera Data Box.
• Konfigurera Data Box Disk.
• Konfigurera Data Box Heavy.

Beroende på typen av Data Box kan Data Box-kopieringsverktyg vara tillgängliga. I det här läget rekommenderar vi dem inte för migreringar till Azure-filresurser eftersom de inte kopierar dina filer till Data Box med fullständig återgivning. Använd Robocopy i stället.

När din Data Box anländer har den företablerade SMB-resurser tillgängliga för varje lagringskonto som du angav när du beställde det.

• Om dina filer hamnar i en Premium Azure-filresurs finns det en SMB-resurs per premiumlagringskonto för "fillagring".
• Om dina filer går in på ett standardlagringskonto finns det tre SMB-resurser per standardlagringskonto (GPv1 och GPv2). Endast de filresurser som slutar med _AzFiles är relevanta för migreringen. Ignorera alla block- och sidblobresurser.

Följ stegen i Azure Data Box-dokumentationen:

1. Anslut till Data Box.
2. Kopiera data till Data Box.
   Du kan använda Robocopy (följ anvisningarna nedan) eller den nya Data Box-datakopieringstjänsten.
3. Förbered din Data Box för uppladdning till Azure.

Dricks

Som ett alternativ till Robocopy har Data Box skapat en datakopieringstjänst. Du kan använda den här tjänsten för att läsa in filer på din Data Box med fullständig återgivning. Följ den här självstudien om datakopieringstjänsten och se till att ange rätt Azure-filresursmål.

Data Box-dokumentationen anger ett Robocopy-kommando. Det kommandot är inte lämpligt för att bevara den fullständiga fil- och mappåtergivningen. Använd det här kommandot i stället:

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	Innebörd
/MT:n	Gör att Robocopy kan köras multitrådat. Standardvärdet för n är 8. Maxvärdet är 128 trådar. Även om ett högt antal trådar hjälper till att mätta den tillgängliga bandbredden betyder det inte att migreringen alltid kommer att gå snabbare med fler trådar. Tester med Azure Files visar att mellan 8 och 20 visar balanserade prestanda för en första kopieringskörning. Efterföljande /MIR körningar påverkas progressivt av tillgänglig beräkning jämfört med tillgänglig nätverksbandbredd. Vid efterföljande körningar matchar du värdet för antal trådar närmare mot antalet processorkärnor och antalet trådar per kärna. Överväg om kärnor måste reserveras för andra uppgifter som en produktionsserver kan utföra. Tester med Azure Files har visat att upp till 64 trådar ger bra prestanda, men bara om dina processorer kan hålla dem vid liv samtidigt.
/R:n	Maximalt antal omförsök för en fil som inte kan kopieras vid första försöket. Robocopy försöker n gånger innan filen permanent misslyckas med att kopiera i körningen. Du kan optimera körningens prestanda: Välj ett värde på två eller tre om du tror att tidsgränsproblem orsakade fel tidigare. Detta kan vara vanligare via WAN-länkar. Välj inget nytt försök eller ett värde för ett om du tror att filen inte kunde kopieras eftersom den användes aktivt. Om du försöker igen några sekunder senare kanske det inte finns tillräckligt med tid för att filens användningstillstånd ska ändras. Användare eller appar som håller filen öppen kan behöva timmar mer tid. I det här fallet kan godkännandet av filen inte kopierades och fånga den i en av dina planerade, efterföljande Robocopy-körningar, så småningom lyckas kopiera filen. Det hjälper den aktuella körningen att slutföras snabbare utan att förlängas av många återförsök som i slutändan hamnar i en majoritet av kopieringsfelen på grund av att filer fortfarande öppnas efter tidsgränsen för återförsök.
/W:n	Anger hur länge Robocopy ska vänta innan du försöker kopiera en fil som inte gick att kopiera under ett tidigare försök. n är antalet sekunder som ska vänta mellan återförsök. /W:n används ofta tillsammans med /R:n.
/B	Kör Robocopy i samma läge som ett säkerhetskopieringsprogram skulle använda. Med den här växeln kan Robocopy flytta filer som den aktuella användaren inte har behörighet för. Säkerhetskopieringsväxeln är beroende av att du kör Robocopy-kommandot i en upphöjd administratörskonsol eller Ett PowerShell-fönster. Om du använder Robocopy för Azure Files kontrollerar du att du monterar Azure-filresursen med hjälp av lagringskontots åtkomstnyckel jämfört med en domänidentitet. Om du inte gör det kanske felmeddelandena inte intuitivt leder dig till en lösning på problemet.
/MIR	(Segla källan till målet.) Gör att Robocopy bara kan kopiera delta mellan källa och mål. Tomma underkataloger kopieras. Objekt (filer eller mappar) som har ändrats eller inte finns på målet kopieras. Objekt som finns på målet men inte på källan rensas (tas bort) från målet. När du använder den här växeln matchar du källans och målets mappstruktur exakt. Matchning innebär att kopiera från rätt käll- och mappnivå till den matchande mappnivån på målet. Först då kan en ”catch up”-kopiering lyckas. När källan och målet är matchande leder användningen /MIR till storskaliga borttagningar och omkopior.
/IT	Ser till att naturtrogen återgivning bevaras i vissa speglingsscenarier. Om en fil till exempel upplever en ACL-ändring och en attributuppdatering mellan två Robocopy-körningar markeras den som dold. Utan /ITkan ACL-ändringen missas av Robocopy och inte överföras till målplatsen.
/COPY:[copyflags]	Filkopieringens naturtrogna återgivning. Standard: /COPY:DAT. Kopiera flaggor: D= Data, A= Attribut, T= Tidsstämplar, S= Säkerhet = NTFS ACL:er, O= Ägarinformation, U= Auditing information. Granskningsinformation kan inte lagras i en Azure-filresurs.
/DCOPY:[copyflags]	Återgivning för kopian av kataloger. Standard: /DCOPY:DA. Kopiera flaggor: D= Data, A= Attribut, T= Tidsstämplar.
/NP	Anger att kopieringsförloppet för varje fil och mapp inte visas. Om du visar förloppet får du betydligt läge prestanda.
/NFL	Anger att filnamn inte ska loggas. Ger bättre kopieringsprestanda.
/NDL	Anger att katalognamn inte ska loggas. Ger bättre kopieringsprestanda.
/XD	Anger kataloger som ska undantas. När du kör Robocopy i roten på en volym bör du överväga att undanta den dolda System Volume Information mappen. Om den används som den är utformad är all information där inne specifik för den exakta volymen i det här exakta systemet och kan återskapas på begäran. Att kopiera den här informationen är inte användbart i molnet eller när data någonsin kopieras tillbaka till en annan Windows-volym. Att lämna det här innehållet bakom bör inte betraktas som dataförlust.
/UNILOG:<file name>	Skriver status till loggfilen som Unicode. (Skriver över den befintliga loggen.)
/L	Endast för en testkörning ska filer endast visas. De kopieras inte, tas inte bort och får inga tidsstämplar. Används ofta med /TEE för konsolutdata. Flaggor från exempelskriptet, som /NP, /NFLoch /NDL, kan behöva tas bort för att uppnå korrekt dokumenterade testresultat.
/LFSM	Endast för mål med nivåindelad lagring. Stöds inte när målet är en fjärransluten SMB-resurs. Anger att Robocopy fungerar i läget "låg ledigt utrymme". Den här växeln är endast användbar för mål med nivåindelad lagring som kan få slut på lokal kapacitet innan Robocopy slutförs. Den har lagts till specifikt för användning med mål som är aktiverade för molnnivåindelning i Azure File Sync. Den kan användas oberoende av Azure File Sync. I det här läget pausar Robocopy när en filkopiering skulle få målvolymens lediga utrymme att hamna under ett lägsta värde. Det här värdet kan anges i /LFSM:n form av flaggan. Parametern n anges i bas 2: nKB, nMBeller nGB. Om /LFSM anges utan explicit golvvärde anges golvet till 10 procent av målvolymens storlek. Läget låg ledigt utrymme är inte kompatibelt med /MT, /EFSRAWeller /ZB. Stöd för /B lades till i Windows Server 2022. Mer information om en relaterad bugg och lösning finns i avsnittet Windows Server 2022 och RoboCopy LFSM nedan.
/Z	Använd försiktigt Kopierar filer i omstartsläge. Du bör bara använda den här växeln i en instabil nätverksmiljö. Den ber betydligt sämre kopieringsprestanda på grund av den extra loggningen.
/ZB	Använd försiktigt Använder omstartsläge. Om åtkomst nekas använder det här alternativet omstartsläge. Det här alternativet ger betydligt sämre kopieringsprestanda på grund av kontrollpunkterna.

Viktigt!

Vi rekommenderar att du använder en Windows Server 2022. När du använder en Windows Server 2019 ska du se till att den senaste korrigeringsnivån eller minst operativsystemets uppdatering KB5005103 är installerad. Den innehåller viktiga korrigeringar för vissa Robocopy-scenarier.

Fas 6: Distribuera Azure File Sync-molnresursen

Innan du fortsätter med den här guiden väntar du tills alla dina filer har kommit till rätt Azure-filresurser. Det tar tid att skicka och mata in Data Box-data.

För att slutföra det här steget behöver du dina autentiseringsuppgifter för Azure-prenumerationen.

Den kärnresurs som ska konfigureras för Azure File Sync kallas för en synkroniseringstjänst för lagring. Vi rekommenderar att du bara distribuerar en för alla servrar som synkroniserar samma uppsättning filer nu eller i framtiden. Skapa endast flera Storage Sync Services om du har distinkta uppsättningar servrar som aldrig får utbyta data. Du kan till exempel ha servrar som aldrig får synkronisera samma Azure-filresurs. Annars är det bästa sättet att använda en enda tjänst för synkronisering av lagring.

Välj en Azure-region för lagringssynkroniseringstjänsten som är nära din plats. Alla andra molnresurser måste distribueras i samma region. För att förenkla hanteringen skapar du en ny resursgrupp i din prenumeration som innehåller synkroniserings- och lagringsresurser.

Mer information finns i avsnittet om hur du distribuerar Tjänsten för synkronisering av lagring i artikeln om distribution av Azure File Sync. Följ endast det här avsnittet i artikeln. Det kommer att finnas länkar till andra avsnitt i artikeln i senare steg.

Fas 7: Distribuera Azure File Sync-agenten

I det här avsnittet installerar du Azure File Sync-agenten på din Windows Server-instans.

Distributionsguiden förklarar att du måste inaktivera Förbättrad säkerhetskonfiguration i Internet Explorer. Det här säkerhetsmåttet gäller inte för Azure File Sync. Om du inaktiverar det kan du autentisera till Azure utan problem.

Öppna PowerShell. Installera nödvändiga PowerShell-moduler med hjälp av följande kommandon. Se till att installera den fullständiga modulen och NuGet-providern när du uppmanas att göra det.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Om du har problem med att nå Internet från servern är det dags att lösa dem. Azure File Sync använder alla tillgängliga nätverksanslutningar till Internet. Det finns också stöd för att kräva att en proxyserver når Internet. Du kan antingen konfigurera en datoromfattande proxy nu eller, under agentinstallationen, ange en proxy som endast Azure File Sync ska använda.

Om konfigurationen av en proxy innebär att du måste öppna brandväggarna för servern kan den metoden vara acceptabel för dig. I slutet av serverinstallationen, när du har slutfört serverregistreringen, visar en rapport om nätverksanslutning de exakta slutpunkts-URL:er i Azure som Azure File Sync behöver kommunicera med för den region som du har valt. Rapporten visar också varför kommunikation behövs. Du kan använda rapporten för att låsa brandväggarna runt servern till specifika URL:er.

Du kan också använda en mer konservativ metod där du inte öppnar brandväggarna i stort. Du kan i stället begränsa servern till att kommunicera med DNS-namnområden på högre nivå. Mer information finns i Proxy- och brandväggsinställningar för Azure File Sync. Följ dina egna metodtips för nätverk.

I slutet av guiden för serverinstallation öppnas en guide för serverregistrering. Registrera servern till Azure-resursen för Storage Sync Service från tidigare.

De här stegen beskrivs mer detaljerat i distributionsguiden, som innehåller de PowerShell-moduler som du bör installera först: Installation av Azure File Sync-agenten.

Använd den senaste agenten. Du kan ladda ned den från Microsoft Download Center: Azure File Sync Agent.

Efter en lyckad installation och serverregistrering kan du bekräfta att du har slutfört det här steget. Gå till storage sync service-resursen i Azure-portalen. I den vänstra menyn går du till Registrerade servrar. Servern visas där.

Fas 8: Konfigurera Azure File Sync på Windows Server-instansen

Din registrerade lokala Windows Server-instans måste vara klar och ansluten till Internet för den här processen.

Det här steget kopplar samman alla resurser och mappar som du har konfigurerat på din Windows Server-instans under föregående steg.

1. Logga in på Azure-portalen.
2. Leta upp din Storage Sync Service-resurs.
3. Skapa en ny synkroniseringsgrupp i Storage Sync Service-resursen för varje Azure-filresurs. I Azure File Sync-terminologi blir Azure-filresursen en molnslutpunkt i synkroniseringstopologin som du beskriver när du skapar en synkroniseringsgrupp. När du skapar synkroniseringsgruppen ger du den ett bekant namn så att du känner igen vilken uppsättning filer som synkroniseras där. Kontrollera att du refererar till Azure-filresursen med ett matchande namn.
4. När du har skapat synkroniseringsgruppen visas en rad för den i listan över synkroniseringsgrupper. Välj namnet (en länk) för att visa innehållet i synkroniseringsgruppen. Du ser din Azure-filresurs under Molnslutpunkter.
5. Leta upp knappen Lägg till serverslutpunkt. Mappen på den lokala server som du har etablerat blir sökvägen till den här serverslutpunkten.

Aktivera funktionen för molnnivåindelning och välj Endast namnområde i det första nedladdningsavsnittet.

Viktigt!

Molnnivåindelning är funktionen Azure File Sync som gör att den lokala servern kan ha mindre lagringskapacitet än vad som lagras i molnet men som har det fullständiga namnområdet tillgängligt. Lokalt intressanta data cachelagras också lokalt för snabb åtkomstprestanda. Molnnivåindelning är valfritt. Du kan ange den individuellt för varje Azure File Sync-serverslutpunkt. Du måste använda den här funktionen om du inte har tillräckligt med lokal diskkapacitet på Windows Server-instansen för att lagra alla molndata och du vill undvika att ladda ned alla data från molnet.

Upprepa stegen för att skapa synkroniseringsgrupper och lägga till matchande servermappar som serverslutpunkter för alla Azure-filresurser/serverplatser som du behöver konfigurera för synkronisering. Vänta tills synkroniseringen av namnområdet har slutförts. I följande avsnitt beskrivs hur du kan se till att synkroniseringen är klar.

Kommentar

När du har skapat en serverslutpunkt fungerar synkroniseringen. Men synkroniseringen måste räkna upp (identifiera) de filer och mappar som du flyttade via Data Box till Azure-filresursen. Beroende på namnområdets storlek kan det ta lång tid innan namnområdet från molnet visas på servern.

Fas 9: Vänta tills namnområdet visas helt på servern

Innan du fortsätter med nästa steg i migreringen väntar du tills servern har laddat ned namnområdet helt från molnresursen. Om du börjar flytta filer till servern för tidigt riskerar du onödiga uppladdningar och till och med filsynkroniseringskonflikter.

Om du vill ta reda på om servern har slutfört den första nedladdningssynkroniseringen öppnar du Prikazivač događaja på din synkronisering av Windows Server-instansen och använder azure file sync-händelseloggen. Händelseloggen för telemetri finns i Prikazivač događaja under Program och tjänster\Microsoft\FileSync\Agent.

Sök efter den senaste händelsen 9102. Händelse-ID 9102 loggas när en synkroniseringssession slutförs. I händelsetexten finns det ett fält för nedladdningssynkroniseringsriktningen. (HResult måste vara noll och filer måste laddas ned.)

Du vill se två på varandra följande händelser av den här typen, med det här innehållet, för att säkerställa att servern har laddat ned namnområdet. Det är OK om det finns andra händelser mellan de två 9102-händelserna.

Fas 10: Kör Robocopy från din NAS

När servern har slutfört den första synkroniseringen av hela namnområdet från molnresursen kan du fortsätta med det här steget. Den inledande synkroniseringen måste vara klar innan du fortsätter med det här steget. Mer information finns i föregående avsnitt.

I det här steget kör du Robocopy-jobb för att synkronisera dina molnresurser med de senaste ändringarna på din NAS som inträffade sedan du förgrenade dina resurser till Data Box. Den här Robocopy-körningen kan slutföras snabbt eller ta ett tag, beroende på mängden omsättning som inträffade på dina NAS-resurser.

Varning

På grund av ett regresserat Robocopy-beteende i Windows Server 2019 är Robocopy-växeln /MIR inte kompatibel med nivåindelade målkataloger. Du kan inte använda Windows Server 2019- eller Windows 10-klienten för den här fasen av migreringen. Använd Robocopy på en mellanliggande Windows Server 2016-instans.

Här är den grundläggande migreringsmetoden:

• Kör Robocopy från NAS-installationen för att synkronisera Windows Server-instansen.
• Använd Azure File Sync för att synkronisera Azure-filresurserna från Windows Server.

Kör den första lokala kopian till windows server-målmappen:

1. Identifiera den första platsen på DIN NAS-installation.
2. Identifiera den matchande mappen på Den Windows Server-instans som redan har Azure File Sync konfigurerat på den.
3. Starta kopian med robocopy.

Följande Robocopy-kommando kopierar endast skillnaderna (uppdaterade filer och mappar) från NAS-lagringen till din Windows Server-målmapp. Windows Server-instansen synkroniserar dem sedan med Azure-filresurserna.

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	Innebörd
/MT:n	Gör att Robocopy kan köras multitrådat. Standardvärdet för n är 8. Maxvärdet är 128 trådar. Även om ett högt antal trådar hjälper till att mätta den tillgängliga bandbredden betyder det inte att migreringen alltid kommer att gå snabbare med fler trådar. Tester med Azure Files visar att mellan 8 och 20 visar balanserade prestanda för en första kopieringskörning. Efterföljande /MIR körningar påverkas progressivt av tillgänglig beräkning jämfört med tillgänglig nätverksbandbredd. Vid efterföljande körningar matchar du värdet för antal trådar närmare mot antalet processorkärnor och antalet trådar per kärna. Överväg om kärnor måste reserveras för andra uppgifter som en produktionsserver kan utföra. Tester med Azure Files har visat att upp till 64 trådar ger bra prestanda, men bara om dina processorer kan hålla dem vid liv samtidigt.
/R:n	Maximalt antal omförsök för en fil som inte kan kopieras vid första försöket. Robocopy försöker n gånger innan filen permanent misslyckas med att kopiera i körningen. Du kan optimera körningens prestanda: Välj ett värde på två eller tre om du tror att tidsgränsproblem orsakade fel tidigare. Detta kan vara vanligare via WAN-länkar. Välj inget nytt försök eller ett värde för ett om du tror att filen inte kunde kopieras eftersom den användes aktivt. Om du försöker igen några sekunder senare kanske det inte finns tillräckligt med tid för att filens användningstillstånd ska ändras. Användare eller appar som håller filen öppen kan behöva timmar mer tid. I det här fallet kan godkännandet av filen inte kopierades och fånga den i en av dina planerade, efterföljande Robocopy-körningar, så småningom lyckas kopiera filen. Det hjälper den aktuella körningen att slutföras snabbare utan att förlängas av många återförsök som i slutändan hamnar i en majoritet av kopieringsfelen på grund av att filer fortfarande öppnas efter tidsgränsen för återförsök.
/W:n	Anger hur länge Robocopy ska vänta innan du försöker kopiera en fil som inte gick att kopiera under ett tidigare försök. n är antalet sekunder som ska vänta mellan återförsök. /W:n används ofta tillsammans med /R:n.
/B	Kör Robocopy i samma läge som ett säkerhetskopieringsprogram skulle använda. Med den här växeln kan Robocopy flytta filer som den aktuella användaren inte har behörighet för. Säkerhetskopieringsväxeln är beroende av att du kör Robocopy-kommandot i en upphöjd administratörskonsol eller Ett PowerShell-fönster. Om du använder Robocopy för Azure Files kontrollerar du att du monterar Azure-filresursen med hjälp av lagringskontots åtkomstnyckel jämfört med en domänidentitet. Om du inte gör det kanske felmeddelandena inte intuitivt leder dig till en lösning på problemet.
/MIR	(Segla källan till målet.) Gör att Robocopy bara kan kopiera delta mellan källa och mål. Tomma underkataloger kopieras. Objekt (filer eller mappar) som har ändrats eller inte finns på målet kopieras. Objekt som finns på målet men inte på källan rensas (tas bort) från målet. När du använder den här växeln matchar du källans och målets mappstruktur exakt. Matchning innebär att kopiera från rätt käll- och mappnivå till den matchande mappnivån på målet. Först då kan en ”catch up”-kopiering lyckas. När källan och målet är matchande leder användningen /MIR till storskaliga borttagningar och omkopior.
/IT	Ser till att naturtrogen återgivning bevaras i vissa speglingsscenarier. Om en fil till exempel upplever en ACL-ändring och en attributuppdatering mellan två Robocopy-körningar markeras den som dold. Utan /ITkan ACL-ändringen missas av Robocopy och inte överföras till målplatsen.
/COPY:[copyflags]	Filkopieringens naturtrogna återgivning. Standard: /COPY:DAT. Kopiera flaggor: D= Data, A= Attribut, T= Tidsstämplar, S= Säkerhet = NTFS ACL:er, O= Ägarinformation, U= Auditing information. Granskningsinformation kan inte lagras i en Azure-filresurs.
/DCOPY:[copyflags]	Återgivning för kopian av kataloger. Standard: /DCOPY:DA. Kopiera flaggor: D= Data, A= Attribut, T= Tidsstämplar.
/NP	Anger att kopieringsförloppet för varje fil och mapp inte visas. Om du visar förloppet får du betydligt läge prestanda.
/NFL	Anger att filnamn inte ska loggas. Ger bättre kopieringsprestanda.
/NDL	Anger att katalognamn inte ska loggas. Ger bättre kopieringsprestanda.
/XD	Anger kataloger som ska undantas. När du kör Robocopy i roten på en volym bör du överväga att undanta den dolda System Volume Information mappen. Om den används som den är utformad är all information där inne specifik för den exakta volymen i det här exakta systemet och kan återskapas på begäran. Att kopiera den här informationen är inte användbart i molnet eller när data någonsin kopieras tillbaka till en annan Windows-volym. Att lämna det här innehållet bakom bör inte betraktas som dataförlust.
/UNILOG:<file name>	Skriver status till loggfilen som Unicode. (Skriver över den befintliga loggen.)
/L	Endast för en testkörning ska filer endast visas. De kopieras inte, tas inte bort och får inga tidsstämplar. Används ofta med /TEE för konsolutdata. Flaggor från exempelskriptet, som /NP, /NFLoch /NDL, kan behöva tas bort för att uppnå korrekt dokumenterade testresultat.
/LFSM	Endast för mål med nivåindelad lagring. Stöds inte när målet är en fjärransluten SMB-resurs. Anger att Robocopy fungerar i läget "låg ledigt utrymme". Den här växeln är endast användbar för mål med nivåindelad lagring som kan få slut på lokal kapacitet innan Robocopy slutförs. Den har lagts till specifikt för användning med mål som är aktiverade för molnnivåindelning i Azure File Sync. Den kan användas oberoende av Azure File Sync. I det här läget pausar Robocopy när en filkopiering skulle få målvolymens lediga utrymme att hamna under ett lägsta värde. Det här värdet kan anges i /LFSM:n form av flaggan. Parametern n anges i bas 2: nKB, nMBeller nGB. Om /LFSM anges utan explicit golvvärde anges golvet till 10 procent av målvolymens storlek. Läget låg ledigt utrymme är inte kompatibelt med /MT, /EFSRAWeller /ZB. Stöd för /B lades till i Windows Server 2022. Mer information om en relaterad bugg och lösning finns i avsnittet Windows Server 2022 och RoboCopy LFSM nedan.
/Z	Använd försiktigt Kopierar filer i omstartsläge. Du bör bara använda den här växeln i en instabil nätverksmiljö. Den ber betydligt sämre kopieringsprestanda på grund av den extra loggningen.
/ZB	Använd försiktigt Använder omstartsläge. Om åtkomst nekas använder det här alternativet omstartsläge. Det här alternativet ger betydligt sämre kopieringsprestanda på grund av kontrollpunkterna.

Viktigt!

Vi rekommenderar att du använder en Windows Server 2022. När du använder en Windows Server 2019 ska du se till att den senaste korrigeringsnivån eller minst operativsystemets uppdatering KB5005103 är installerad. Den innehåller viktiga korrigeringar för vissa Robocopy-scenarier.

Om du har etablerat mindre lagringsutrymme på din Windows Server-instans än dina filer använder på NAS-installationen har du konfigurerat molnnivåindelning. När den lokala Windows Server-volymen blir full kommer molnnivåindelningen att starta och nivåindela filer som redan har synkroniserats. Molnnivåindelning genererar tillräckligt med utrymme för att fortsätta kopian från NAS-installationen. Molnnivåindelningen kontrolleras en gång i timmen för att avgöra vad som har synkroniserats och frigöra diskutrymme för att nå det lediga utrymmet på 99 procent.

Robocopy kan behöva flytta fler filer än du kan lagra lokalt på Windows Server-instansen. Du kan förvänta dig att Robocopy flyttas snabbare än vad Azure File Sync kan ladda upp dina filer och nivåindela dem från din lokala volym. I det här fallet misslyckas Robocopy. Vi rekommenderar att du går igenom resurserna i en sekvens som förhindrar det här scenariot. Flytta till exempel bara resurser som får plats i det lediga utrymme som är tillgängligt på Windows Server-instansen. Eller undvik att starta Robocopy-jobb för alla resurser samtidigt. Den goda nyheten är att växeln /MIR ser till att endast deltan flyttas. När ett delta har flyttats behöver inte ett omstartat jobb flytta filen igen.

Gör cutover

När du kör Robocopy-kommandot för första gången kommer dina användare och program fortfarande att komma åt filer på NAS och eventuellt ändra dem. Robocopy bearbetar en katalog och går sedan vidare till nästa. En användare på NAS kan sedan lägga till, ändra eller ta bort en fil i den första katalogen som inte bearbetas under den aktuella Robocopy-körningen. Detta är ett förväntat beteende.

Den första körningen handlar om att flytta huvuddelen av dataomsättningen till din Windows Server-instans och till molnet via Azure File Sync. Den här första kopian kan ta lång tid, beroende på:

• Uppladdningsbandbredden.
• Den lokala nätverkshastigheten och hur optimalt antalet Robocopy-trådar matchar det.
• Antalet objekt (filer och mappar) som behöver bearbetas av Robocopy och Azure File Sync.

När den första körningen är klar kör du kommandot igen.

Robocopy avslutas snabbare andra gången du kör den för en resurs. Den behöver bara transportera ändringar som har inträffat sedan den senaste körningen. Du kan köra upprepade jobb för samma resurs.

När du anser att stilleståndstiden är acceptabel måste du ta bort användaråtkomsten till dina NAS-baserade resurser. Du kan göra det på alla sätt som hindrar användare från att ändra fil- och mappstrukturen och innehållet. Du kan till exempel peka ditt DFS-namnområde till en plats som inte finns eller ändra rot-ACL:er på resursen.

Kör Robocopy en sista gång. Det kommer att plocka upp eventuella ändringar som har missats. Hur lång tid det här sista steget tar beror på robocopy-genomsökningens hastighet. Du kan beräkna tiden (som är lika med din stilleståndstid) genom att mäta längden på föregående körning.

Skapa en resurs i Windows Server-mappen och justera eventuellt DFS-N-distributionen så att den pekar på den. Se till att ange samma behörigheter på resursnivå som på din NAS SMB-resurs. Om du hade en domänansluten NAS i företagsklass matchar användar-SID:erna automatiskt eftersom användarna finns i Active Directory och Robocopy kopierar filer och metadata med fullständig återgivning. Om du har använt lokala användare på din NAS måste du:

• Återskapa dessa användare som lokala Windows Server-användare.
• Mappa befintliga SID:er som Robocopy flyttade över till din Windows Server-instans till SID:erna för dina nya lokala Windows Server-användare.

Du har migrerat en resurs eller grupp med resurser till en gemensam rot eller volym (beroende på din mappning från fas 1).

Du kan försöka köra några av dessa kopior parallellt. Vi rekommenderar att du bearbetar omfånget för en Azure-filresurs i taget.

Inaktuellt alternativ: "dataöverföring offline"

Innan Azure File Sync-agenten version 13 släpptes genomfördes Data Box-integreringen genom en process som kallas "dataöverföring offline". Den här processen är inaktuell och du kan inte längre skapa en serverslutpunkt i läget "dataöverföring offline". Med agentversion 13 ersattes den med de mycket enklare och snabbare stegen som beskrivs i den här artikeln.

Felsökning

Det vanligaste problemet är att Robocopy-kommandot misslyckas med "Volym full" på Windows Server-sidan. Molnnivåindelning fungerar en gång i timmen för att evakuera innehåll från den lokala Windows Server-disken som har synkroniserats. Målet är att nå ditt 99-procents lediga utrymme på volymen.

Låt synkroniseringsframsteg och molnnivåindelning frigöra diskutrymme. Du kan observera att i Istraživač datoteka på din Windows Server-instans.

När din Windows Server-instans har tillräckligt med tillgänglig kapacitet kör du kommandot igen för att lösa problemet. Inget går sönder i den här situationen. Du kan gå vidare med tillförsikt. Besväret med att köra kommandot igen är den enda konsekvensen.

Information om hur du felsöker problem med Azure File Sync finns i artikeln i nästa avsnitt.

Nästa steg

Följande artiklar hjälper dig att förstå avancerade alternativ och metodtips för Azure Files och Azure File Sync.

• Migreringsöversikt
• Planera för distribution av Azure File Sync
• Skapa en filresurs
• Felsöka Azure File Sync