Migrera data offline till Azure File Sync med Azure Data Box

Artikel
06/24/2024

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

Datakälla: Windows Server 2012 R2 eller senare där Azure File Sync installeras och pekar på den ursprungliga uppsättningen filer.
Migreringsväg: Windows Server 2012 R2 eller senare ⇒ Data Box ⇒ Azure-filresurs ⇒ synkronisera med den ursprungliga Filplatsen för Windows Server
Cachelagring av filer lokalt: Ja, det sista målet är en Azure File Sync-distribution som synkroniserar filerna där de är nu.

Att använda Azure Data Box är en användbar väg för att flytta huvuddelen av data från din lokala Windows Server för att separera Azure-filresurser och sedan, om du vill, lägga till Azure File Sync på den ursprungliga källservern.

Det finns olika migreringsvägar som är tillgängliga för dig. Det är viktigt att du följer rätt:

Dina data finns på en Windows Server 2012 R2 eller senare och du planerar att installera AFS på servern och synkronisera den ursprungliga platsen. I det här scenariot vill du inte ladda upp alla filer och använda Data Box i stället och sedan använda filsynkronisering för pågående ändringar. Om det här är ditt scenario beskriver den här artikeln din migreringssökväg.
Du har data på en källa där du inte vill eller inte kan installera AFS på. En NAS (nätverksansluten lagring) till exempel eller en annan server. Du skapar hellre en ny, tom server och använder Azure File Sync på den servern. Om det är ditt scenario är det inte rätt migreringsguide för dig. Kolla i stället: Migrera från NAS via Data Box till Azure File Sync eller hitta den bästa guiden för ditt scenario på migreringsöversiktssidan.
För alla andra scenarier kontrollerar du tabellen med migreringsguider för Azure-filresurser. Den här översiktssidan är en bra utgångspunkt för alla migreringsscenarier.

Migreringsöversikt

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

Distribuera lagringskonton och filresurser.
Distribuera en eller flera Azure Data Box-enheter för att flytta data från din Windows Server 2012 R2 eller senare.
Konfigurera Azure File Sync med auktoritativ uppladdning.

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

Med den här migreringsguiden måste du fortsätta att använda den lokala direktanslutna lagringen (DAS) som innehåller dina filer. Data Box matas från den platsen och Azure File Sync kommer också att konfigureras på den platsen. NAS (Network Attached Storage) fungerar inte med den här migreringssökvägen.

Du avgör vilka synkroniseringar genom att konfigurera Azure File Sync-synkroniseringsgrupper som var och en avgör var en uppsättning filer synkroniseras mellan. Varje synkroniseringsgrupp har minst en serverplats, kallad serverslutpunkt och en Azure-filresurs, som kallas molnslutpunkt.

Du kan synkronisera undersökvägar för en uppsättning filer till var och en av deras egna Azure-filresurser. Det innebär att du konfigurerar flera synkroniseringsgrupper för att täcka en uppsättning filer helt. Resten av avsnittet beskriver dina alternativ. Om du behöver omstrukturera dina data måste du göra det som ett första steg. Innan du fortsätter med den här guiden beställer du en Data Box- eller konfigurationssynkronisering.

Varning

Det är absolut nödvändigt att din fil- och mappstruktur är hur du vill att den ska vara långsiktig innan du påbörjar migreringen. Undvik onödiga mappomstruktureringar under migreringen. Detta minskar de positiva effekterna av att använda Azure Data Box för inledande masstransport av filer till Azure.

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.

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.

Excel-ikon som anger kontexten för nedladdningen.

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.

Kommentar

För Data Box och Data Box Heavy stöds endast kopiering av data via SMB. Kopiering av data via datakopieringstjänsten stöds inte eftersom det inte bevarar filåtergivningen.

Fas 4: 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:

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:

Anslut till Data Box.
Kopiera data till Data Box.
Förbered din Data Box för uppladdning till Azure.

Den länkade 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 `/IT`kan 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`, `/NFL`och `/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`, `nMB`eller `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`, `/EFSRAW`eller `/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 5: 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 6: 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 7: Konfigurera Azure File Sync på den befintliga Windows Server

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.

Logga in på Azure-portalen.
Leta upp din Storage Sync Service-resurs.
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.
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.
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.

När du är i guiden Skapa serverslutpunkt använder du den angivna kryssrutan under mappsökvägen. Gör bara det här valet om du har angett en sökväg som pekar på samma fil- och mappstruktur som finns i Azure-filresursen (där Data Box flyttade filerna och mapparna till för det här namnområdet).

Om det finns en matchningsfel i mapphierarkin visas den som skillnader som inte kan lösas automatiskt. Undvik ett matchningsfel eller så leder en investering i Data Box-processen till att du inte får någon fördel. Alla data tas bort i Azure-filresursen. Alla data måste laddas upp från den lokala servern. Katalogstrukturerna måste matcha för att kunna dra nytta av en massmigrering med Azure Data Box och en sömlös uppdatering av molnresursen med de senaste ändringarna från servern.

Kommentar

Om du aktiverar den här kryssrutan anges läget För inledande synkronisering till Auktoritativt skriv över filer och mappar i Azure-filresursen med innehåll i serverns sökväg. Det här alternativet är endast tillgängligt för den första serverslutpunkten i en synkroniseringsgrupp.

När du har konfigurerat auktoritativ uppladdning för den nya serverslutpunkten kan du aktivera molnnivåindelning.

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. Använd den här funktionen för att uppnå ett fast lagringsavtryck lokalt, men ändå ge användarna en lokal prestandacache och lagra svalare data i molnet.

Läs mer genom att titta på översikten över molnnivåindelning eller ta en närmare titt på de olika molnnivåprinciper som du kan använda för att finjustera vad som cachelagras/nivåindelats på den lokala servern.

Slutför migreringen

När du har skapat en serverslutpunkt fungerar synkroniseringen. Men synkroniseringen måste räkna upp (identifiera) de filer och mappar som du har flyttat via Azure Data Box till Azure-filresursen. Beroende på namnområdets storlek kan det ta lång tid innan de senaste serverändringarna synkroniseras till molnet. Användarna påverkas inte och kan fortsätta att arbeta med data på servern. Den här strategin uppnår en molnmigrering utan avbrott.

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. Du använde Azure Data Box för att flytta dina filer till flera Azure-filresurser. Migreringen är klar när du har skapat alla serverslutpunkter som ansluter dina lokala data till dessa Azure-filresurser.

Nästa steg

Det finns mer att upptäcka om Azure-filresurser och Azure File Sync. Följande artiklar hjälper dig att förstå avancerade alternativ och metodtips. De ger också hjälp med felsökning. De här artiklarna innehåller länkar till dokumentationen för Azure-filresursen där det är lämpligt.

Dela via

Migrera data offline till Azure File Sync med Azure Data Box

Migreringsöversikt