Använda RoboCopy för att migrera till Azure-filresurser

  • Artikel

Den här migreringsartikeln beskriver användningen av RoboCopy för att flytta eller migrera filer till en SMB Azure-filresurs. RoboCopy är ett betrott och välkänt filkopieringsverktyg med en funktionsuppsättning som gör den väl lämpad för migreringar. Det använder SMB-protokollet, vilket gör det allmänt tillämpligt för alla käll- och målkombinationer som stöder SMB.

  • Datakällor: Alla källor som stöder SMB-protokollet, till exempel Nätverksansluten lagring (NAS), Windows- eller Linux-servrar, en annan Azure-filresurs och många fler
  • Migreringsväg: Från källlagring ⇒ Windows-dator med RoboCopy ⇒ Azure-filresurs
  • Inga cachelagringsfiler lokalt: Eftersom det slutliga målet är att använda Azure-filresurserna direkt i molnet finns det ingen plan för att använda Azure File Sync.

Det finns många olika migreringsvägar för olika käll- och distributionskombinationer. Se tabellen med migreringsguider för att hitta den migrering som bäst passar dina behov.

Gäller för

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

AzCopy jämfört med RoboCopy

AzCopy och RoboCopy är två fundamentalt olika filkopieringsverktyg. RoboCopy använder valfri version av SMB-protokollet. AzCopy är ett "born-in-the-cloud"-verktyg som kan användas för att flytta data så länge målet finns i Azure Storage. AzCopy är beroende av ett REST-protokoll.

RoboCopy, som ett betrott, Windows-baserat kopieringsverktyg, har hemmagräsfördelen när det gäller att kopiera filer med fullständig återgivning. RoboCopy stöder många migreringsscenarier på grund av dess omfattande uppsättning funktioner och möjligheten att kopiera filer och mappar i fullständig återgivning. Läs avsnittet om filåtergivning i artikeln om migreringsöversikt om du vill veta mer om vikten av att kopiera filer med maximal återgivning.

AzCopy, å andra sidan, har nyligen expanderats för att stödja filkopiering med viss återgivning och lagt till de första funktionerna som måste betraktas som ett migreringsverktyg. Det finns dock fortfarande luckor, och det kan lätt uppstå missförstånd om funktioner när du jämför AzCopy-flaggor med RoboCopy-flaggor.

Ett exempel: RoboCopy /MIR speglar källan till målet – det innebär att tillagda, ändrade och borttagna filer beaktas. En viktig skillnad i att använda AzCopy -sync är att borttagna filer på källan inte tas bort på målet. Det ger en ofullständig funktionsuppsättning för differentiell kopiering. AzCopy fortsätter att utvecklas. För närvarande rekommenderar vi inte att du använder AzCopy för migreringsscenarier med Azure-filresurser som mål.

Migreringsmål

Målet är att flytta data från befintliga filresursplatser till Azure. I Azure lagrar du dina data i interna Azure-filresurser som du kan använda utan att behöva en Windows Server. 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 får plats i eller bara något överskrider regelbundna underhållsperioder.

Migreringsöversikt

Migreringsprocessen består av flera faser. Först måste du distribuera Azure Storage-konton och filresurser. Därefter ska du konfigurera nätverk, överväga en DFS-namnområdesdistribution (DFS-N) eller uppdatera din befintliga. När det är dags för den faktiska datakopian måste du överväga upprepade, differentiella RoboCopy-körningar för att minimera stilleståndstiden och slutligen begränsa användarna till de nyligen skapade Azure-filresurserna. I följande avsnitt beskrivs faserna i migreringsprocessen i detalj.

Fas 1: Distribuera Azure Storage-resurser

I den här fasen etablerar du Azure Storage-kontona och SMB Azure-filresurserna i dem.

Kom ihåg att en Azure-filresurs distribueras i molnet på ett Azure Storage-konto. För standardfilresurser gör det här arrangemanget lagringskontot till ett skalningsmål för prestandanummer som IOPS och dataflöde. Om du placerar flera filresurser i ett enda lagringskonto skapar du en delad pool med IOPS och dataflöde för dessa resurser.

Som en allmän regel kan du poola flera Azure-filresurser till samma lagringskonto om du har arkivresurser eller om du förväntar dig låg daglig aktivitet i dem. Men om du har mycket aktiva resurser (resurser som används av många användare och/eller program) vill du distribuera lagringskonton med en filresurs var. Dessa begränsningar gäller inte för FileStorage-lagringskonton (premium), där prestanda uttryckligen etableras och garanteras för varje resurs.

Kommentar

Det finns en gräns på 250 lagringskonton per prenumeration per Azure-region. Med en kvotökning kan du skapa upp till 500 lagringskonton per region. Mer information finns i Öka Azure Storage-kontokvoter.

Ett annat att tänka på när du distribuerar ett lagringskonto är redundans. Se Redundans för Azure Files.

Om du har gjort en lista över dina resurser bör du mappa varje resurs till lagringskontot som den skapas i.

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.

Distribuera nu lämpligt antal Azure-lagringskonton med lämpligt antal Azure-filresurser i dem, enligt anvisningarna i Skapa en SMB-filresurs. I de flesta fall vill du se till att regionen för vart och ett av dina lagringskonton är densamma.

Fas 2: Förbereder användning av Azure-filresurser

Med informationen i den här fasen kan du bestämma hur dina servrar och användare i Azure och utanför Azure ska aktiveras för att använda dina Azure-filresurser. De viktigaste besluten är:

  • Nätverk: Aktivera nätverk för att dirigera SMB-trafik.
  • Autentisering: Konfigurera Azure Storage-konton för Kerberos-autentisering. Genom att använda identitetsbaserad autentisering och domänanslutning till ditt lagringskonto kan dina appar och användare använda sin AD-identitet för autentisering.
  • Auktorisering: ACL:er på resursnivå för varje Azure-filresurs ger AD-användare och grupper åtkomst till en viss resurs. I en Azure-filresurs tar interna NTFS-ACL:er över. Auktorisering baserat på fil- och mapp-ACL:er fungerar sedan som den gör för lokala SMB-resurser.
  • Affärskontinuitet: Integrering av Azure-filresurser i en befintlig miljö innebär ofta att befintliga resursadresser bevaras. Om du inte redan använder DFS-Namnområden bör du överväga att etablera det i din miljö. Du kommer att kunna behålla resursadresser som användarna och skripten använder, oförändrade. DFS-N tillhandahåller en namnområdesroutningstjänst för SMB genom att omdirigera klienter till Azure-filresurser.

Den här videon är en guide och demo för hur du på ett säkert sätt exponerar Azure-filresurser direkt för informationsarbetare och appar i fem enkla steg.
Videon refererar till dedikerad dokumentation för följande avsnitt. Observera att Azure Active Directory nu är Microsoft Entra-ID. För mer information, se Nytt namn för Azure AD.

Montera en Azure-filresurs

Innan du kan använda RoboCopy måste du göra Azure-filresursen tillgänglig via SMB. Det enklaste sättet är att montera resursen som en lokal nätverksenhet till den Windows Server som du planerar att använda för RoboCopy.

Viktigt!

Se till att du monterar Azure-filresursen med åtkomstnyckeln för lagringskontot. Använd inte en domänidentitet. Innan du kan montera en Azure-filresurs på en lokal Windows Server måste du ha slutfört fas 2: Förbereder användning av Azure-filresurser.

När du är klar kan du läsa Använda en Azure-filresurs med Windows. Montera sedan den Azure-filresurs som du vill starta RoboCopy för.

Fas 3: RoboCopy

Följande RoboCopy-kommando kopierar endast skillnaderna (uppdaterade filer och mappar) från källlagringen till din Azure-filresurs.

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.
/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.

Dricks

Läs avsnittet Felsökning om RoboCopy påverkar produktionsmiljön, rapporterar många fel eller inte går så snabbt som förväntat.

Fas 4: Användarnedskärning

När du kör RoboCopy-kommandot för första gången kommer dina användare och program fortfarande åt filer på källan för migreringen och kan ändra dem. Det är möjligt att RoboCopy har bearbetat en katalog, gått vidare till nästa och sedan lägger till, ändrar eller tar bort en fil som nu inte kommer att bearbetas i 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 Azure-filresurs. Den här första kopian kan ta en stund. Mer information om vad som kan påverka RoboCopy-hastigheter finns i avsnittet Felsökning.

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

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

När du har övervägt mängden acceptabel stilleståndstid måste du ta bort användaråtkomsten till dina källresurser. Du kan göra det genom alla steg som hindrar användare från att ändra fil- och mappstrukturen och innehållet. Ett exempel är att peka ditt DFS-namnområde till en icke-befintlig plats eller ändra ACL:erna för varje resurs.

Kör en sista RoboCopy-runda. Den kommer att hämta eventuella ändringar som kan ha missats. Hur lång tid det här sista steget tar beror på hastigheten på RoboCopy-genomsökningen. Du kan beräkna tiden (som är lika med din stilleståndstid) genom att mäta hur lång tid den föregående körningen tog.

I fas 2 konfigurerade du användarna att komma åt resursen med sin identitet och borde ha upprättat en strategi för användarna att använda etablerade sökvägar till dina nya Azure-filresurser (DFS-N).

Du kan försöka köra några av dessa kopior mellan olika käll- och målresurser parallellt. När du gör det bör du ha nätverkets dataflöde och kärn-till-trådantal i åtanke för att inte överbeskatta systemet.

Felsöka och optimera

Hastigheten och framgångsgraden för en viss RoboCopy-körning beror på flera faktorer:

  • IOPS på käll- och mållagringen
  • tillgänglig nätverksbandbredd mellan källa och mål
  • möjligheten att snabbt bearbeta filer och mappar i ett namnområde
  • antalet ändringar mellan RoboCopy-körningar
  • storlek och antal filer som du behöver kopiera

Överväganden för IOPS och bandbredd

I den här kategorin måste du överväga funktionerna i källlagringen, mållagringen och nätverket som ansluter dem. Det maximala möjliga dataflödet bestäms av den långsammaste av dessa tre komponenter. Kontrollera att nätverksinfrastrukturen är konfigurerad för att stödja optimala överföringshastigheter efter bästa förmåga.

Varning

Även om det ofta är mest önskvärt att kopiera så snabbt som möjligt bör du överväga användningen av ditt lokala nätverk och NAS-installationen för andra, ofta affärskritiska uppgifter.

Det är kanske inte önskvärt att kopiera så snabbt som möjligt när det finns en risk att migreringen kan monopolisera tillgängliga resurser.

  • Tänk på när det är bäst i din miljö att köra migreringar: under dagen, ledig tid eller under helger.
  • Överväg också att nätverka QoS på en Windows Server för att begränsa RoboCopy-hastigheten.
  • Undvik onödigt arbete för migreringsverktygen.

RoboCopy kan infoga fördröjningar mellan paket genom att ange växeln /IPG:n där n mäts i millisekunder mellan RoboCopy-paket. Med den här växeln kan du undvika monopolisering av resurser på både I/O-begränsade enheter och överfulla nätverkslänkar.

/IPG:n kan inte användas för exakt nätverksbegränsning till en viss Mbit/s. Använd Windows Server Network QoS i stället. RoboCopy är helt beroende av SMB-protokollet för alla nätverksbehov. Att använda SMB är anledningen till att RoboCopy inte kan påverka själva nätverkets dataflöde, men det kan göra användningen långsammare.

En liknande tankelinje gäller för IOPS som observerats på NAS. Klusterstorleken på NAS-volymen, paketstorlekarna och en matris med andra faktorer påverkar den observerade IOPS. Att införa fördröjning mellan paket är ofta det enklaste sättet att styra belastningen på NAS:n. Testa flera värden, till exempel från cirka 20 millisekunder (n=20) till multiplar av det talet. När du har infört en fördröjning kan du utvärdera om dina andra appar nu kan fungera som förväntat. Med den här optimeringsstrategin kan du hitta den optimala RoboCopy-hastigheten i din miljö.

Bearbetningshastighet

RoboCopy bläddrar igenom namnområdet som det pekar på och utvärderar varje fil och mapp för kopiering. Varje fil utvärderas under en första kopia och under upphämtningskopior. Till exempel upprepade körningar av RoboCopy /MIR mot samma käll- och mållagringsplatser. Dessa upprepade körningar är användbara för att minimera stilleståndstiden för användare och appar och för att förbättra den totala framgångsgraden för filer som migreras.

Vi brukar ofta betrakta bandbredd som den mest begränsande faktorn i en migrering – och det kan vara sant. Men möjligheten att räkna upp ett namnområde kan påverka den totala tiden att kopiera ännu mer för större namnområden med mindre filer. Tänk på att kopiering av 1 TiB av små filer tar betydligt längre tid än att kopiera 1 TiB av färre men större filer, förutsatt att alla andra variabler förblir desamma. Därför kan du uppleva långsam överföring om du migrerar ett stort antal små filer. Detta är det förväntade beteendet.

Orsaken till den här skillnaden är den bearbetningskraft som krävs för att gå igenom ett namnområde. RoboCopy stöder flertrådade kopior via parametern /MT:n där n står för antalet trådar som ska användas. När du etablerar en dator specifikt för RoboCopy bör du överväga antalet processorkärnor och deras relation till antalet trådar som de tillhandahåller. De vanligaste är två trådar per kärna. Kärn- och trådantalet för en dator är en viktig datapunkt för att bestämma vilka flertrådsvärden /MT:n du ska ange. Tänk också på hur många RoboCopy-jobb som du planerar att köra parallellt på en viss dator.

Fler trådar kopierar vårt 1 TiB-exempel på små filer betydligt snabbare än färre trådar. Samtidigt kanske den extra resursinvesteringen på vår 1 TiB av större filer inte ger proportionella fördelar. Ett högt antal trådar försöker kopiera fler av de stora filerna över nätverket samtidigt. Den här extra nätverksaktiviteten ökar sannolikheten för att begränsas av dataflöde eller lagrings-IOPS.

Under en första RoboCopy till ett tomt mål eller en differentiell körning med många ändrade filer begränsas du troligen av nätverkets dataflöde. Börja med ett stort antal trådar i den första körningen. Ett högt antal trådar, även utanför dina tillgängliga trådar på datorn, hjälper till att mätta den tillgängliga nätverksbandbredden. Efterföljande /MIR-körningar påverkas progressivt av bearbetningsobjekt. Färre ändringar i en differentiell körning innebär mindre dataöverföring över nätverket. Din hastighet är nu mer beroende av att du kan bearbeta namnområdesobjekt än att flytta dem via nätverkslänken. För efterföljande körningar matchar du värdet för antal trådar med antalet processorkärnor och trådantalet per kärna. Tänk på om kärnor måste reserveras för andra uppgifter som en produktionsserver kan ha.

Dricks

Tumregel: Den första RoboCopy-körningen (som flyttar mycket data i ett nätverk med högre svarstid) drar nytta av överetablering av antalet trådar (/MT:n). Efterföljande körningar kopierar färre skillnader och det är mer troligt att du övergår från nätverksdataflöde som är begränsat till beräkningsbegränsat. Under dessa omständigheter är det ofta bättre att matcha antalet RoboCopy-trådar med de faktiskt tillgängliga trådarna på datorn. Överetablering i det scenariot kan leda till fler kontextförskjutningar i processorn, vilket kan göra kopian långsammare.

Undvik onödigt arbete

Undvik storskaliga ändringar i namnområdet, till exempel att flytta filer mellan kataloger, ändra egenskaper i stor skala eller ändra katalog- och filnivåbehörigheter (NTFS-ACL:er). Särskilt ACL-ändringar kan ha stor inverkan eftersom de ofta har en sammanhängande ändringseffekt på filer längre ned i mapphierarkin. Konsekvenserna kan vara:

  • utökad Körningstid för RoboCopy-jobb eftersom varje fil och mapp som påverkas av en ACL-ändring behöver uppdateras
  • återanvändning av data som flyttats tidigare kan behöva kopieras på nytt. Till exempel måste mer data kopieras när mappstrukturerna ändras efter att filer redan har kopierats tidigare. Ett RoboCopy-jobb kan inte "spela upp" en namnområdesändring. Nästa jobb måste rensa filerna som tidigare transporterats till den gamla mappstrukturen och ladda upp filerna i den nya mappstrukturen igen.

En annan viktig aspekt är att använda RoboCopy-verktyget effektivt. Med det rekommenderade RoboCopy-skriptet skapar och sparar du en loggfil för fel. Kopieringsfel kan inträffa – det är normalt. Dessa fel gör det ofta nödvändigt att köra flera omgångar av ett kopieringsverktyg som RoboCopy: En första körning, till exempel från en NAS till DataBox eller en server till en Azure-filresurs, och en eller flera extra körningar med växeln /MIR för att fånga och försöka igen filer som inte kopierats.

Du bör vara beredd att köra flera rundor av RoboCopy mot ett angivet namnområdesomfång. Efterföljande körningar slutförs snabbare eftersom de har mindre att kopiera, men begränsas i allt högre grad av bearbetningshastigheten för namnområdet. När du kör flera rundor kan du påskynda varje runda genom att inte låta RoboCopy försöka orimligt hårt för att kopiera allt i en viss körning. Dessa RoboCopy-växlar kan göra stor skillnad:

  • /R:n n = hur ofta du försöker kopiera en misslyckad fil igen och
  • /W:n n = hur många sekunder som ska vänta mellan återförsök

/R:5 /W:5 är en rimlig inställning som du kan anpassa efter dina önskemål. I det här exemplet görs ett nytt försök med en misslyckad fil, med fem sekunders väntetid mellan återförsök. Om filen fortfarande inte kan kopieras försöker nästa RoboCopy-jobb igen. Ofta kan filer som misslyckades på grund av att de används eller på grund av tidsgränsproblem så småningom kopieras på det här sättet.

Beräkna avgifter för lagringstransaktioner

När du påbörjar migreringen till Azure Files kopierar RoboCopy dina filer och mappar till Azure. Beroende på din faktureringsmodell för Azure Files kan transaktionsavgifter tillkomma. Se Förstå fakturering.

Om du använder en betala per användning-faktureringsmodell för vanliga Azure-filresurser kan det vara svårt att uppskatta antalet transaktioner som din migrering genererar.

  • Det går inte att beräkna antalet transaktioner baserat på källans använda lagringskapacitet. Antalet transaktioner skalar med antalet namnområdesobjekt (filer och mappar) och deras egenskaper som migreras, inte deras storlek. Fler transaktioner krävs till exempel för att migrera 1 GiB med små filer än 1 GiB av större filer.
  • För att minimera stilleståndstiden kan du behöva köra kopieringsåtgärder flera gånger från källa till mål. Alla käll- och målobjekt bearbetas under varje kopieringsåtgärd, men efterföljande körningar slutförs snabbare. Efter de första åtgärderna transporteras endast skillnaderna mellan kopieringskörningar över nätverket. Det är viktigt att förstå att även om mindre data transporteras kan antalet transaktioner som krävs förbli detsamma.
  • Att kopiera samma fil två gånger kanske inte resulterar i samma antal transaktioner. Bearbetning av ett objekt som migrerats i en tidigare kopieringskörning kan bara resultera i några få lästransaktioner. Ändringar av metadata eller innehåll mellan kopieringskörningar kan däremot kräva ett större antal transaktioner för att uppdatera målet. Varje fil i namnområdet kan ha unika krav, vilket resulterar i ett annat antal transaktioner.

Vi rekommenderar att du kör några inledande tester på dina egna data för att bättre förstå hur många transaktioner som uppstår. Detta ger dig en bättre uppfattning om det totala antalet transaktioner som en filmigrering kan generera.

Nästa steg

Följande artiklar hjälper dig att förstå avancerade alternativ och metodtips.