StorSimple 8100- och 8600-migrering till Azure File Sync

Artikel
03/21/2023

StorSimple 8000-serien innehåller antingen 8100 eller 8600 fysiska, lokala apparater och deras molntjänstkomponenter. StorSimple 8010 och 8020 virtuella installationer beskrivs också i den här migreringsguiden. Det går att migrera data från någon av dessa enheter till Azure-filresurser med valfri Azure File Sync. Azure File Sync är den standardmässiga och strategiska långsiktiga Azure-tjänsten som ersätter de lokala StorSimple-funktionerna. Den här artikeln innehåller nödvändiga bakgrundskunskaper och migreringssteg för en lyckad migrering till Azure File Sync.

Kommentar

StorSimple-tjänsten (inklusive StorSimple-Enhetshanteraren för 8000- och 1200-serien och StorSimple Data Manager) har nått slutet av supporten. Supporten för StorSimple upphörde 2019 på sidorna Microsoft LifeCycle Policy och Azure Communications . Ytterligare meddelanden skickades via e-post och publicerades på Azure-portalen och i Översikt över StorSimple. Kontakta Microsoft Support om du vill ha mer information.

Den här videon ger en översikt över:

Azure Files
Azure File Sync
Jämförelse av StorSimple och Azure Files
Översikt över migreringsverktyg och processer i StorSimple Data Manager

Fas 1: Förbered för migrering

Det här avsnittet innehåller de steg du bör vidta i början av migreringen från StorSimple-volymer till Azure-filresurser.

Följande ingår i den här videon:

Välja lagringsnivå
Välja alternativ för lagringsredundans
Välja direct-share-access jämfört med Azure File Sync
StorSimple-tjänstens datakrypteringsnyckel och serienummer
Migrering av StorSimple-volymsäkerhetskopiering
Mappa StorSimple-volymer och resurser till Azure-filresurser
Gruppera resurser i Azure-filresurser
Mappningsöverväganden
Kalkylblad för migreringsplanering
Kalkylblad för namnområdesmappning

Lager

När du börjar planera migreringen bör du först identifiera alla StorSimple-enheter och volymer som du behöver migrera. Därefter kan du välja den bästa migreringsvägen.

Fysiska StorSimple-installationer (8000-serien) använder den här migreringsguiden.
Virtuella StorSimple-installationer (1200-serien) använder en annan migreringsguide.

Kostnadssammanfattning för migrering

Migreringar till Azure-filresurser från StorSimple-volymer via migreringsjobb i en StorSimple Data Manager-resurs är kostnadsfria. Andra kostnader kan uppstå under och efter en migrering:

Utgående nätverk: Dina StorSimple-filer finns i ett lagringskonto i en specifik Azure-region. Om du etablerar de Azure-filresurser som du migrerar till ett lagringskonto i samma Azure-region uppstår inga utgående kostnader. Men om du flyttar dina filer till ett lagringskonto i en annan region som en del av den här migreringen kommer utgående kostnader att gälla.
Azure-filresurstransaktioner: När filer kopieras till en Azure-filresurs (som en del av en migrering eller utanför en) tillämpas transaktionskostnader när filer och metadata skrivs. Vi rekommenderar att du startar din Azure-filresurs på den transaktionsoptimerade nivån under migreringen. Växla till önskad nivå när migreringen är klar. Faserna som beskrivs i den här artikeln beskriver detta vid lämplig tidpunkt.
Ändra en Azure-filresursnivå: Ändra nivån för en Azure-filresurskostnadstransaktioner. I de flesta fall är det mer kostnadseffektivt att följa råden från föregående punkt.
Lagringskostnad: När den här migreringen börjar kopiera filer till en Azure-filresurs förbrukas och faktureras lagring. Migrerade säkerhetskopior blir ögonblicksbilder av Azure-filresurser. Ögonblicksbilder av filresurser förbrukar bara lagringskapacitet för de skillnader som de innehåller.
StorSimple: Tills du avetablerar StorSimple-enheter och lagringskonton fortsätter StorSimple-kostnaden för lagring, säkerhetskopior och installationer att inträffa.

Azure-filresurser öppnar en ny värld av möjligheter att strukturera distributionen av filtjänster. En Azure-filresurs är en SMB-resurs i molnet som du kan konfigurera så att användarna får åtkomst direkt via SMB-protokollet med den välbekanta Kerberos-autentiseringen och befintliga NTFS-behörigheter (fil- och mapp-ACL:er) som fungerar internt. Läs mer om identitetsbaserad åtkomst till Azure-filresurser.

Ett alternativ till direktåtkomst är Azure File Sync. Azure File Sync är en direkt analog för StorSimples möjlighet att cachelagrar filer som används ofta lokalt.

Azure File Sync är en Microsoft-molntjänst som baseras på två huvudkomponenter:

Filsynkronisering och molnnivåindelning för att skapa en cache för prestandaåtkomst på valfri Windows Server.
Filresurser som intern lagring i Azure som kan nås via flera protokoll som SMB och fil-REST.

Azure-filresurser behåller viktiga filåtergivningsaspekter som attribut, behörigheter och tidsstämplar. Med Azure-filresurser behöver inte längre ett program eller en tjänst tolka de filer och mappar som lagras i molnet. Du kan komma åt dem internt via välbekanta protokoll och klienter. Med Azure-filresurser kan du lagra allmänna filserverdata och programdata i molnet.

Den här artikeln fokuserar på migreringsstegen. Om du vill veta mer om Azure File Sync innan du migrerar kan du läsa följande artiklar:

StorSimple-tjänstens datakrypteringsnyckel

När du först konfigurerade StorSimple-installationen genererade den en krypteringsnyckel för tjänstdata och instruerade dig att lagra nyckeln på ett säkert sätt. Den här nyckeln används för att kryptera alla data i det associerade Azure-lagringskontot där StorSimple-installationen lagrar dina filer.

Krypteringsnyckeln för tjänstdata är nödvändig för en lyckad migrering. Hämta den här nyckeln från dina poster, en för var och en av enheterna i ditt lager.

Om du inte hittar nycklarna i dina poster kan du generera en ny nyckel från installationen. Varje installation har en unik krypteringsnyckel.

Ändra krypteringsnyckeln för tjänstdata

Krypteringsnycklar för tjänstdata används för att kryptera konfidentiella kunddata, till exempel autentiseringsuppgifter för lagringskonton, som skickas från StorSimple Manager-tjänsten till StorSimple-enheten. Du måste ändra dessa nycklar regelbundet om IT-organisationen har en princip för nyckelrotation på lagringsenheterna. Nyckeländringsprocessen kan skilja sig något beroende på om det finns en enda enhet eller flera enheter som hanteras av StorSimple Manager-tjänsten. Mer information finns i StorSimple-säkerhet och dataskydd.

Att ändra krypteringsnyckeln för tjänstdata är en trestegsprocess:

Använd Windows PowerShell-skript för Azure Resource Manager och ge en enhet behörighet att ändra krypteringsnyckeln för tjänstdata.
Med Hjälp av Windows PowerShell för StorSimple initierar du ändringen av tjänstens datakrypteringsnyckel.
Om du har fler än en StorSimple-enhet uppdaterar du krypteringsnyckeln för tjänstdata på de andra enheterna.

Steg 1: Använd Windows PowerShell-skript för att auktorisera en enhet för att ändra krypteringsnyckeln för tjänstdata

Vanligtvis begär enhetsadministratören att tjänstadministratören ger en enhet behörighet att ändra krypteringsnycklar för tjänstdata. Tjänstadministratören ger sedan enheten behörighet att ändra nyckeln.

Det här steget utförs med hjälp av det Azure Resource Manager-baserade skriptet. Tjänstadministratören kan välja en enhet som är berättigad att auktoriseras. Enheten har sedan behörighet att starta processen för ändring av tjänstens datakrypteringsnyckel.

Mer information om hur du använder skriptet finns i Authorize-ServiceEncryptionRollover.ps1

Vilka enheter kan ha behörighet att ändra krypteringsnycklar för tjänstdata?

En enhet måste uppfylla följande villkor innan den kan ha behörighet att initiera ändringar i tjänstens datakrypteringsnyckel:

Enheten måste vara online för att vara berättigad till ändringsauktorisering för tjänstdatakrypteringsnyckel.
Du kan auktorisera samma enhet igen efter 30 minuter om nyckeländringen inte har initierats.
Du kan auktorisera en annan enhet, förutsatt att nyckeländringen inte har initierats av den tidigare auktoriserade enheten. När den nya enheten har godkänts kan den gamla enheten inte initiera ändringen.
Du kan inte auktorisera en enhet medan återställningen av krypteringsnyckeln för tjänstdata pågår.
Du kan auktorisera en enhet när vissa av de enheter som registrerats med tjänsten har rullat över krypteringen medan andra inte har gjort det.

Steg 2: Använd Windows PowerShell för StorSimple för att initiera nyckeländringen för tjänstdatakryptering

Det här steget utförs i Windows PowerShell för StorSimple-gränssnittet på den auktoriserade StorSimple-enheten.

Kommentar

Inga åtgärder kan utföras i Azure-portalen för StorSimple Manager-tjänsten förrän nyckelåterställning har slutförts.

Om du använder enhetens seriekonsol för att ansluta till Windows PowerShell-gränssnittet utför du följande steg.

Så här initierar du ändringen av krypteringsnyckeln för tjänstdata

Välj alternativ 1 för att logga in med fullständig åtkomst.
Skriv i kommandotolken:

Invoke-HcsmServiceDataEncryptionKeyChange
När cmdleten har slutförts får du en ny krypteringsnyckel för tjänstdata. Kopiera och spara den här nyckeln för användning i steg 3 i den här processen. Den här nyckeln används för att uppdatera alla återstående enheter som registrerats med StorSimple Manager-tjänsten.

Kommentar

Den här processen måste initieras inom fyra timmar efter att en StorSimple-enhet har auktoriserats.

Den här nya nyckeln skickas sedan till tjänsten för push-överföring till alla enheter som är registrerade med tjänsten. En avisering visas sedan på instrumentpanelen för tjänsten. Tjänsten inaktiverar alla åtgärder på de registrerade enheterna och enhetsadministratören måste sedan uppdatera krypteringsnyckeln för tjänstdata på de andra enheterna. I/Os (värdar som skickar data till molnet) kommer dock inte att störas.

Om du har en enda enhet registrerad i din tjänst är processen nu klar och du kan hoppa över nästa steg. Om du har flera enheter registrerade i tjänsten fortsätter du till steg 3.

Steg 3: Uppdatera krypteringsnyckeln för tjänstdata på andra StorSimple-enheter

De här stegen måste utföras i Windows PowerShell-gränssnittet för din StorSimple-enhet om du har flera enheter registrerade i StorSimple Manager-tjänsten. Nyckeln som du fick i steg 2 måste användas för att uppdatera alla återstående StorSimple-enheter som registrerats med StorSimple Manager-tjänsten.

Utför följande steg för att uppdatera tjänstens datakryptering på enheten.

Uppdatera krypteringsnyckeln för tjänstdata på fysiska enheter

Använd Windows PowerShell för StorSimple för att ansluta till konsolen. Välj alternativ 1 för att logga in med fullständig åtkomst.
Skriv Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey i kommandotolken
Ange krypteringsnyckeln för tjänstdata som du fick i steg 2: Använd Windows PowerShell för StorSimple för att initiera ändringen av tjänstens datakrypteringsnyckel.

Uppdatera krypteringsnyckeln för tjänstdata på alla 8010/8020-molninstallationer

Ladda ned och konfigurera PowerShell-skriptet Update-CloudApplianceServiceEncryptionKey.ps1 .
Öppna PowerShell och skriv följande i kommandotolken: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Det här skriptet säkerställer att krypteringsnyckeln för tjänstdata anges på alla 8010/8020-molninstallationer under enhetshanteraren.

Varning

När du bestämmer dig för hur du ska ansluta till storSimple-installationen bör du tänka på följande:

Anslut genom en HTTPS-session är det säkraste och rekommenderade alternativet.
Anslut direkt till enhetens seriekonsol är säkert, men det är inte att ansluta till seriekonsolen via nätverksväxlar.
HTTP-sessionsanslutningar är ett alternativ men är inte krypterade. De rekommenderas inte om de inte används i ett stängt, betrott nätverk.

Kända begränsningar

StorSimple Data Manager- och Azure-filresurserna har några begränsningar som du bör tänka på innan du börjar, eftersom de kan förhindra en migrering:

Endast NTFS-volymer från StorSimple-installationen stöds. ReFS-volymer stöds inte.
Volymer som placeras på dynamiska Windows Server-diskar stöds inte.
Tjänsten fungerar inte med volymer som är BitLocker-krypterade eller har Datadeduplicering aktiverat.
Skadade StorSimple-säkerhetskopior kan inte migreras.
Särskilda nätverksalternativ, till exempel brandväggar eller kommunikation med endast privat slutpunkt, kan inte aktiveras på det källlagringskonto där StorSimple-säkerhetskopior lagras eller på mållagringskontot som innehåller dina Azure-filresurser.

Filåtergivning

Om ingen av begränsningarna i Kända begränsningar förhindrar en migrering finns det fortfarande begränsningar för vad som kan lagras i Azure-filresurser.

Filåtergivning refererar till de många attribut, tidsstämplar och data som utgör en fil. Vid en migrering är filåtergivning ett mått på hur väl informationen på källan (StorSimple-volymen) kan översättas (migreras) till Azure-målfilresursen.

Azure Files stöder en delmängd av NTFS-filegenskaperna. Windows-ACL:er, vanliga metadata och vissa tidsstämplar migreras.

Följande objekt förhindrar inte en migrering, men orsakar problem per objekt under en migrering:

Tidsstämplar: Filändringstiden anges inte. Det är för närvarande skrivskyddat via REST-protokollet. Tidsstämpeln för senaste åtkomst i en fil flyttas inte eftersom det inte är ett attribut som stöds för filer som lagras i en Azure-filresurs.
Alternativa data Flöden kan inte lagras i Azure-filresurser. Filer som innehåller alternativa data Flöden kopieras, men alternativa data Flöden tas bort från filen i processen.
Symboliska länkar, hårda länkar, knutpunkter och referenspunkter hoppas över under en migrering. Migreringskopieringsloggarna visar varje överhoppat objekt och en orsak.
EFS-krypterade filer kan inte kopieras. Kopieringsloggar visar att objektet inte kunde kopieras med "Åtkomst nekas".
Skadade filer hoppas över. Kopieringsloggarna kan visa olika fel för varje objekt som är skadat på StorSimple-disken: "Begäran misslyckades på grund av ett allvarligt maskinvarufel för enheten" eller "Filen eller katalogen är skadad eller oläslig" eller "Strukturen för åtkomstkontrollistan (ACL) är ogiltig".
Enskilda filer som är större än 4 TiB hoppas över.
Filsökvägslängden måste vara lika med eller mindre än 2 048 tecken. Filer och mappar med längre sökvägar hoppas över.
Referenspunkter hoppas över. Alla Microsoft Data Deduplicerings-/SIS-referenspunkter eller sådana från tredje part kan inte lösas av migreringsmotorn och förhindrar migrering av de berörda filerna och mapparna.

I felsökningsavsnittet i slutet av den här artikeln finns mer information om felkoder på objektnivå och migreringsjobbnivå och, där det är möjligt, deras åtgärdsalternativ.

StorSimple-volymsäkerhetskopior

StorSimple erbjuder differentiella säkerhetskopior på volymnivå. Azure-filresurser har också den här möjligheten, som kallas resursögonblicksbilder.

Dina migreringsjobb kan bara flytta säkerhetskopior, aldrig data från livevolymen. Därför är den senaste säkerhetskopieringen närmast realtidsdata och bör därför alltid ingå i listan över säkerhetskopior som ska flyttas i en migrering.

Bestäm om du behöver flytta äldre säkerhetskopior under migreringen. Det är bästa praxis att hålla listan så liten som möjligt så att dina migreringsjobb slutförs snabbare.

Om du vill identifiera kritiska säkerhetskopior som måste migreras gör du en checklista för dina säkerhetskopieringsprinciper. Till exempel:

Den senaste säkerhetskopieringen.
En säkerhetskopia i månaden i 12 månader.
En säkerhetskopia om året i tre år.

När du skapar dina migreringsjobb kan du använda den här listan för att identifiera de exakta StorSimple-volymsäkerhetskopieringar som måste migreras för att uppfylla dina krav.

Det är bäst att pausa alla kvarhållningsprinciper för StorSimple-säkerhetskopiering innan du väljer en säkerhetskopia för migrering. Det kan ta flera dagar eller veckor att migrera dina säkerhetskopior. StorSimple erbjuder principer för kvarhållning av säkerhetskopior som tar bort säkerhetskopior. Säkerhetskopior som du har valt för den här migreringen kan tas bort innan de har haft en chans att migreras.

Varning

Det går inte att välja fler än 50 StorSimple-volymsäkerhetskopior.

Mappa dina befintliga StorSimple-volymer till Azure-filresurser

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.

Antal lagringskonton

Migreringen kommer sannolikt att ha nytta av att distribuera flera lagringskonton som var och en har ett mindre antal Azure-filresurser.

Om dina filresurser är mycket aktiva (används av många användare eller program) kan två Azure-filresurser nå prestandagränsen för ditt lagringskonto. På grund av detta är det ofta bättre att migrera till flera lagringskonton, var och en med sina egna enskilda filresurser, och vanligtvis inte mer än två eller tre resurser per 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 i dem.

Dessa överväganden gäller mer för direkt molnåtkomst (via en virtuell Azure-dator eller tjänst) än för Azure File Sync. Om du planerar att uteslutande använda Azure File Sync på dessa resurser är det bra att gruppera flera till ett enda Azure Storage-konto. I framtiden kanske du vill lyfta och flytta en app till molnet som sedan skulle ha direkt åtkomst till en filresurs, eftersom det här scenariot skulle ha nytta av att ha högre IOPS och dataflöde. Eller så kan du börja använda en tjänst i Azure som också skulle ha nytta av högre IOPS och dataflöde.

När du har gjort en lista över dina resurser mappar du varje resurs till lagringskontot där den finns. Bestäm en Azure-region och se till att varje lagringskonto och Azure File Sync-resurs matchar den region som du har valt.

Viktigt!

Konfigurera inte nätverks- och brandväggsinställningar för lagringskontona nu. Att göra dessa konfigurationer i det här läget skulle göra en migrering omöjlig. Konfigurera dessa Azure Storage-inställningar när migreringen är klar.

Inställningar för lagringskonto

Det finns många konfigurationer som du kan göra på ett lagringskonto. Använd följande checklista för att bekräfta konfigurationerna av lagringskontot. Du kan ändra nätverkskonfigurationen när migreringen är klar.

Stora filresurser: Aktiverad – Stora filresurser förbättrar prestandan och gör att du kan lagra upp till 100 TiB i en resurs. Den här inställningen gäller för mållagringskonton med Azure-filresurser.
Brandvägg och virtuella nätverk: Inaktiverat – konfigurera inga IP-begränsningar eller begränsa åtkomsten till lagringskontot till ett specifikt virtuellt nätverk. Lagringskontots offentliga slutpunkt används under migreringen. Alla IP-adresser från virtuella Azure-datorer måste tillåtas. Det är bäst att konfigurera brandväggsregler för lagringskontot efter migreringen. Konfigurera både käll- och mållagringskonton på det här sättet.
Privata slutpunkter: Stöds – Du kan aktivera privata slutpunkter, men den offentliga slutpunkten används för migreringen och måste vara tillgänglig. Detta gäller både käll- och mållagringskonton.

Sammanfattning av fas 1

I slutet av fas 1:

Du har en bra översikt över dina StorSimple-enheter och -volymer.
Data Manager-tjänsten är redo att komma åt dina StorSimple-volymer i molnet eftersom du har hämtat krypteringsnyckeln för tjänstdata för varje StorSimple-enhet.
Du har en plan för vilken volymer och säkerhetskopior (om några utöver de senaste) måste migreras.
Du vet hur du mappar dina volymer till rätt antal Azure-filresurser och lagringskonton.

Fas 2: Distribuera Azure Storage- och migreringsresurser

I det här avsnittet beskrivs överväganden kring distribution av de olika resurstyper som behövs i Azure. Vissa kommer att lagra dina data efter migreringen, och vissa behövs enbart för migreringen. Börja inte distribuera resurser förrän du har slutfört distributionsplanen. Det är svårt, ibland omöjligt, att ändra vissa aspekter av dina Azure-resurser när de har distribuerats.

Den här videon beskriver distributionen av:

Lagringskonton
Prenumerationer och resursgrupper
Lagringskonton
Typer och namn
Prestanda och resursstorlek
Plats- och replikeringstyper
Azure-filresurser
StorSimple Data Manager-tjänsten

Distribuera lagringskonton

Du behöver förmodligen distribuera flera Azure Storage-konton. Var och en har ett mindre antal Azure-filresurser enligt distributionsplanen. Gå till Azure-portalen för att distribuera dina planerade lagringskonton. Överväg att följa följande grundläggande inställningar för alla nya lagringskonton.

Viktigt!

Konfigurera inte nätverks- och brandväggsinställningar för dina lagringskonton nu. Att göra dessa konfigurationer i det här läget skulle göra en migrering omöjlig. Konfigurera dessa Azure Storage-inställningar när migreringen är klar.

Prenumeration

Du kan använda samma prenumeration som du använde för StorSimple-distributionen, eller så kan du använda en annan. Den enda begränsningen är att din prenumeration måste finnas i samma Microsoft Entra-klientorganisation som StorSimple-prenumerationen. Överväg att flytta StorSimple-prenumerationen till rätt klientorganisation innan du påbörjar en migrering. Du kan bara flytta hela prenumerationen eftersom enskilda StorSimple-resurser inte kan flyttas till en annan klient eller prenumeration.

Resursgrupp

Resursgrupper i Azure hjälper till med att organisera resurser och administratörshanteringsbehörigheter. Få reda på mer.

Lagringskontonamn

Namnet på ditt lagringskonto blir en del av en URL som används för att komma åt filresursen och har vissa teckenbegränsningar. I namngivningskonventionen bör du tänka på att lagringskontonamn måste vara unika i världen, endast tillåta gemener och siffror, kräva mellan 3 och 24 tecken och inte tillåta specialtecken som bindestreck eller understreck. Se Namngivningsregler för Azure Storage-resurser.

Plats

Azure-regionen för ett lagringskonto är viktig. Om du använder Azure File Sync måste alla dina lagringskonton finnas i samma region som din Storage Sync Service-resurs. Den Azure-region som du väljer bör vara nära eller central för dina lokala servrar och användare. När du har distribuerat resursen kan du inte ändra dess region.

Du kan välja en annan region än där dina StorSimple-data (lagringskonto) för närvarande finns, men om du gör det tillkommer utgående avgifter under migreringen. Data lämnar StorSimple-regionen och anger din nya lagringskontoregion. Inga bandbreddsavgifter tillämpas om du stannar i samma Azure-region.

Prestanda

Du kan välja premiumlagring (SSD) för Azure-filresurser eller standardlagring. Standardlagring innehåller flera nivåer för en filresurs. Standardlagring är rätt alternativ för de flesta kunder som migrerar från StorSimple.

Välj Premium Storage om du behöver prestanda för en Premium Azure-filresurs.
Välj standardlagring för arbetsbelastningar för allmän filserver, som innehåller frekventa data och arkivdata. Välj även standardlagring om den enda arbetsbelastningen på resursen i molnet är Azure File Sync.
För Premium-filresurser väljer du Filresurser i guiden Skapa lagringskonto.

Replikering

Det finns flera tillgängliga replikeringsinställningar. Välj endast följande två alternativ:

Lokalt redundant lagring (LRS).
Zonredundant lagring (ZRS) som inte är tillgänglig i alla Azure-regioner.

Kommentar

Geo-redundant lagring (GRS) och geo-zonredundant lagring stöds inte.

Aktivera 100 TiB-kapacitetsfilresurser

Under avsnittet Avancerat i guiden för det nya lagringskontot i Azure-portalen kan du aktivera stöd för stora filresurser i det här lagringskontot. Om det här alternativet inte är tillgängligt har du förmodligen valt fel redundanstyp. Se till att du bara väljer LRS eller ZRS för att det här alternativet ska bli tillgängligt.

Det finns flera fördelar med att använda stora filresurser:

Prestandan ökar kraftigt jämfört med de mindre 5 TiB-filresurserna (till exempel 10 gånger IOPS).
Migreringen slutförs snabbare.
Du ser till att en filresurs har tillräckligt med kapacitet för att lagra alla data som du migrerar till den, inklusive den lagringskapacitet som differentiella säkerhetskopior kräver.
Framtida tillväxt täcks.

Viktigt!

Använd inte särskilda nätverk på ditt lagringskonto före eller under migreringen. Den offentliga slutpunkten måste vara tillgänglig för käll- och mållagringskonton. Det går inte att begränsa till specifika IP-intervall eller virtuella nätverk. Du kan ändra nätverkskonfigurationerna för lagringskontot efter migreringen.

Azure-filresurser

När du har skapat dina lagringskonton går du till avsnittet Filresurs i lagringskontona och distribuerar lämpligt antal Azure-filresurser enligt migreringsplanen från fas 1. Överväg att följa följande grundläggande inställningar för dina nya filresurser i Azure.

Namn, gemener, siffror och bindestreck stöds.

Kvotkvoten
här är jämförbar med en hård SMB-kvot på en Windows Server-instans. Det bästa sättet är att inte ange en kvot här eftersom migreringen och andra tjänster misslyckas när kvoten nås.

Nivåer Välj transaktionsoptimerad för den nya filresursen. Under migreringen sker många transaktioner. Det är mer kostnadseffektivt att ändra nivån senare till den nivå som passar bäst för din arbetsbelastning.

StorSimple-datahanterare

Den Azure-resurs som innehåller dina migreringsjobb kallas StorSimple Data Manager. Välj Ny resurs och sök efter den. Välj sedan Skapa.

Den här tillfälliga resursen används för orkestrering. Du avetablerar den när migreringen har slutförts. Se till att distribuera den i samma prenumeration, resursgrupp och region som ditt StorSimple-lagringskonto.

Azure File Sync

Med Azure File Sync kan du lägga till lokal cachelagring av de filer som används oftast. På samma sätt som cachelagringsfunktionerna i StorSimple erbjuder Azure File Sync-molnnivåindelningsfunktionen svarstid för lokal åtkomst i kombination med förbättrad kontroll över den tillgängliga cachekapaciteten på Windows Server-instansen och synkronisering av flera platser. Om det är ditt mål att ha en lokal cache kan du i ditt lokala nätverk förbereda en virtuell Windows Server-dator (fysiska servrar och redundanskluster stöds också) med tillräcklig direktansluten lagringskapacitet.

Viktigt!

Konfigurera inte Azure File Sync än. Distribution av Azure File Sync bör inte starta före fas 4 av en migrering.

Sammanfattning av fas 2

I slutet av fas 2 har du distribuerat dina lagringskonton och alla Azure-filresurser i dem. Du har också en StorSimple Data Manager-resurs. Du använder det senare i fas 3 när du konfigurerar dina migreringsjobb.

Fas 3: Skapa och köra ett migreringsjobb

I det här avsnittet beskrivs hur du konfigurerar ett migreringsjobb och mappar katalogerna på en StorSimple-volym som ska kopieras till den Azure-målfilresurs som du väljer.

Följande ingår i den här videon:

Skapa ett migreringsjobb
Sammanfattning
Källa
Välja volymsäkerhetskopior som ska migreras
Mål
Katalogmappning
Semantiska regler
Köra ett migreringsjobb
Körningsjobbdefinition
Visa jobbets tillstånd
Köra jobb parallellt
Tolka loggfilerna

Kom igång genom att gå till StorSimple Data Manager, hitta jobbdefinitioner på menyn och välja + Jobbdefinition. Rätt mållagringstyp är standard: Azure-filresurs.

Migreringsjobbtyper i StorSimple 8000-serien.

Skärmbild av det nya formuläret för att skapa jobb för ett migreringsjobb.

Namn på jobbdefinition
Det här namnet bör ange den uppsättning filer som du flyttar. Att ge den ett liknande namn som din Azure-filresurs är en bra idé.

Plats där jobbet körs
När du väljer en region måste du välja samma region som ditt StorSimple-lagringskonto eller, om det inte är tillgängligt, en region nära det.

Källa

Källprenumeration
Välj den prenumeration där du lagrar din StorSimple-Enhetshanteraren resurs.

StorSimple-resurs
Välj din StorSimple-Enhetshanteraren enheten är registrerad med.

Krypteringsnyckel
för tjänstdata Kontrollera det här föregående avsnittet i den här artikeln om du inte kan hitta nyckeln i dina poster.

Enhet
Välj din StorSimple-enhet som innehåller volymen där du vill migrera.

Volym
Välj källvolymen. Senare bestämmer du om du vill migrera hela volymen eller underkatalogerna till Azure-målfilresursen.

Volymsäkerhetskopior
Du kan välja Välj volymsäkerhetskopior för att välja specifika säkerhetskopior som ska flyttas som en del av det här jobbet. Ett kommande, dedikerat avsnitt i den här artikeln beskriver processen i detalj.

Mål

Välj prenumerationen, lagringskontot och Azure-filresursen som mål för det här migreringsjobbet.

Katalogmappning

I ett dedikerat avsnitt i den här artikeln beskrivs all relevant information.

Välja volymsäkerhetskopior som ska migreras

Det finns viktiga aspekter när det gäller att välja säkerhetskopior som måste migreras:

Dina migreringsjobb kan bara flytta säkerhetskopior, inte direktvolymdata. Den senaste säkerhetskopieringen är alltså närmast livedata och bör alltid finnas med i listan över säkerhetskopior som flyttas under en migrering. När du öppnar dialogrutan Markering av säkerhetskopiering är den markerad som standard.
Se till att den senaste säkerhetskopieringen är ny för att hålla deltat till liveresursen så litet som möjligt. Det kan vara värt att utlösa och slutföra en annan volymsäkerhetskopia manuellt innan du skapar ett migreringsjobb. Ett litet delta i liveresursen förbättrar migreringsupplevelsen. Om det här deltat kan vara noll, vilket innebär att inga fler ändringar av StorSimple-volymen har gjorts efter att den senaste säkerhetskopieringen har tagits i listan, kommer användarens nedskärning att förenklas drastiskt och påskyndas.
Säkerhetskopior måste spelas upp i Azure-filresursen från äldsta till senaste. En äldre säkerhetskopia kan inte "sorteras in" i listan över säkerhetskopior på Azure-filresursen när du har kört ett migreringsjobb. Därför måste du se till att listan över säkerhetskopior är klar innan du skapar ett jobb.
Den här listan över säkerhetskopior i ett jobb kan inte ändras när jobbet har skapats, även om jobbet aldrig kördes.
För att kunna välja säkerhetskopior måste den StorSimple-volym som du vill migrera vara online.

Om du vill välja säkerhetskopior av StorSimple-volymen för migreringsjobbet väljer du Välj volymsäkerhetskopior i formuläret för att skapa jobb.

När bladet för markering av säkerhetskopior öppnas är det uppdelat i två listor. I den första listan visas alla tillgängliga säkerhetskopior. Du kan expandera och begränsa resultatuppsättningen genom att filtrera för ett visst tidsintervall. (se nästa avsnitt)

En vald säkerhetskopia visas som nedtonad och läggs till i en andra lista på den nedre halvan av bladet. Den andra listan visar alla säkerhetskopior som valts för migrering. En säkerhetskopia som valts i fel kan också tas bort igen.

Varning

Du måste välja alla säkerhetskopior som du vill migrera. Du kan inte lägga till äldre säkerhetskopior senare. Du kan inte ändra jobbet för att ändra ditt val när jobbet har skapats.

Som standard filtreras listan för att visa StorSimple-volymsäkerhetskopieringar under de senaste sju dagarna. Den senaste säkerhetskopieringen är vald som standard, även om den inte har inträffat under de senaste sju dagarna. För äldre säkerhetskopior använder du tidsintervallfiltret överst på bladet. Du kan antingen välja från ett befintligt filter eller ange ett anpassat tidsintervall för att endast filtrera de säkerhetskopior som gjorts under den här perioden.

Varning

Det går inte att välja fler än 50 StorSimple-volymsäkerhetskopior. Jobb med ett stort antal säkerhetskopior kan misslyckas. Se till att kvarhållningsprinciperna för säkerhetskopior inte tar bort en vald säkerhetskopia innan den kan migreras!

Katalogmappning

Katalogmappning är valfritt för migreringsjobbet. Om du lämnar avsnittet tomt flyttas alla filer och mappar i roten på StorSimple-volymen till roten för din Azure-målfilresurs. I de flesta fall är det inte den bästa metoden att lagra en hel volyms innehåll i en Azure-filresurs. Det är ofta bättre att dela upp en volyms innehåll över flera filresurser i Azure. Om du inte redan har gjort en plan kan du läsa Mappa din StorSimple-volym till Azure-filresurser först.

Som en del av migreringsplanen kanske du har bestämt dig för att mapparna på en StorSimple-volym måste delas över flera Azure-filresurser. Om så är fallet kan du utföra den uppdelningen genom att:

Definiera flera jobb för att migrera mapparna på en volym. Var och en har samma StorSimple-volymkälla men en annan Azure-filresurs som mål.
Ange exakt vilka mappar från StorSimple-volymen som måste migreras till den angivna filresursen med hjälp av avsnittet Katalogmappning i formuläret för att skapa jobb och följa den specifika mappningssemantiken.

Viktigt!

Sökvägar och mappningsuttryck i det här formuläret kan inte verifieras när formuläret skickas. Om mappningar anges felaktigt kan ett jobb antingen misslyckas helt eller generera ett oönskat resultat. I så fall är det vanligtvis bäst att ta bort Azure-filresursen, återskapa den och sedan åtgärda mappningsuttrycken i ett nytt migreringsjobb för resursen. Om du kör ett nytt jobb med fasta mappningsuttryck kan du åtgärda utelämnade mappar och föra in dem i den befintliga resursen. Men endast mappar som utelämnades på grund av felstavningar av sökvägar kan åtgärdas på det här sättet.

Semantiska element

En mappning uttrycks från vänster till höger: [\källsökväg] > [\målsökväg].

Semantiskt tecken	Innebörd
\	Indikator på rotnivå.
>	[Källa] och [målmappning] operator.
\| eller RETUR (ny rad)	Avgränsare för två mappmappningsinstruktioner. Du kan också utelämna det här tecknet och välja Retur för att hämta nästa mappningsuttryck på sin egen rad.

Exempel

Flyttar innehållet i mappen Användardata till roten för målfilresursen:

\User data > \

Flyttar hela volyminnehållet till en ny sökväg på målfilresursen:

\ > \Apps\HR tracker

Flyttar källmappens innehåll till en ny sökväg på målfilresursen:

\HR resumes-Backup > \Backups\HR\resumes

Sorterar flera källplatser i en ny katalogstruktur:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Semantiska regler

Ange alltid mappsökvägar i förhållande till rotnivån.
Börja varje mappsökväg med en rotnivåindikator "\".
Ta inte med enhetsbeteckningar.
När du anger flera sökvägar kan käll- eller målsökvägar inte överlappa varandra:
Exempel på ogiltig källsökväg överlappning:
\mapp\1 > \mapp
\1\2 > \mapp2
Exempel på ogiltig överlappning av målsökväg:
\mapp > \
\mapp2 \>
Källmappar som inte finns ignoreras.
Mappstrukturer som inte finns på målet skapas.
Liksom Windows är mappnamn skiftlägesokänsliga men skiftlägesbevarande.

Kommentar

Innehållet i mappen \System Volume Information och $Recycle.Bin på StorSimple-volymen kopieras inte av migreringsjobbet.

Köra ett migreringsjobb

Dina migreringsjobb visas under Jobbdefinitioner i den Data Manager-resurs som du har distribuerat till en resursgrupp. I listan över jobbdefinitioner väljer du det jobb som du vill köra.

På jobbbladet som öppnas kan du se jobbets aktuella status och en lista över säkerhetskopior som du har valt. Listan över säkerhetskopior sorteras efter äldsta till nyaste och migreras till din Azure-filresurs i den här ordningen.

Till en början har migreringsjobbet statusen: Kördes aldrig.
Starta migreringsjobbet när du är klar. Välj avbildningen för en version med högre upplösning.
När en säkerhetskopiering har migrerats tas en automatisk ögonblicksbild av Azure-filresursen. Det ursprungliga säkerhetskopieringsdatumet för StorSimple-säkerhetskopieringen placeras i avsnittet Kommentarer i Azure-filresursögonblicksbilden. Med det här fältet kan du se när data ursprungligen säkerhetskopierades jämfört med den tid då ögonblicksbilden av filresursen togs.

Varning

Säkerhetskopior måste bearbetas från äldsta till nyaste. När ett migreringsjobb har skapats kan du inte ändra listan över valda StorSimple-volymsäkerhetskopior. Starta inte jobbet om listan över säkerhetskopior är felaktig eller ofullständig. Ta bort jobbet och skapa ett nytt med rätt säkerhetskopior valda. Kontrollera dina kvarhållningsscheman för varje vald säkerhetskopia. Säkerhetskopior kan tas bort av en eller flera av dina kvarhållningsprinciper innan de kan migreras!

Fel per objekt

Migreringsjobben har två kolumner i listan över säkerhetskopior som visar eventuella problem som kan ha inträffat under kopieringen:

Kopieringsfel
Den här kolumnen visar filer eller mappar som borde ha kopierats men inte har kopierats. Dessa fel kan ofta återställas. När en säkerhetskopia visar objektproblem i den här kolumnen granskar du kopieringsloggarna. Om du behöver migrera dessa filer väljer du Försök säkerhetskopiera igen. Det här alternativet blir tillgängligt när säkerhetskopieringen har slutfört bearbetningen. I avsnittet Hantera ett migreringsjobb beskrivs dina alternativ mer detaljerat.
Filer
som inte stöds Den här kolumnen visar filer eller mappar som inte kan migreras. Azure Storage har begränsningar i filnamn, sökvägslängder och filtyper som för närvarande eller logiskt inte kan lagras i en Azure-filresurs. Ett migreringsjobb pausar inte för den här typen av fel. Om du försöker migrera säkerhetskopian igen ändras inte resultatet. När en säkerhetskopia listar objektproblem i den här kolumnen granskar du kopieringsloggarna och noterar det. Om sådana problem uppstår i den senaste säkerhetskopieringen och du i kopieringsloggen upptäckte att felet berodde på ett filnamn, sökvägslängd eller annat problem som du har inflytande över, kanske du vill åtgärda problemet i storSimple-livevolymen, göra en StorSimple-volymsäkerhetskopia och skapa ett nytt migreringsjobb med just den säkerhetskopian. Du kan sedan migrera det här reparerade namnområdet och det blir den senaste/live-versionen av Azure-filresursen. Det här är en manuell och tidskrävande process. Granska kopieringsloggarna noggrant och utvärdera om det är värt det.

Dessa kopieringsloggar är *.csv filer som visar namnområdesobjekt lyckades och objekt som inte kunde kopieras. Felen delas ytterligare upp i de tidigare diskuterade kategorierna. Från loggfilens plats kan du hitta loggar för misslyckade filer genom att söka efter "failed". Resultatet bör vara en uppsättning loggar för filer som inte kunde kopieras. Sortera loggarna efter storlek. Det kan finnas extra loggar som genereras med 17 byte i storlek. De är tomma och kan ignoreras. Med en sortering kan du fokusera på loggarna med innehåll.

Samma process gäller för loggfiler som registrerar lyckade kopior.

Hantera ett migreringsjobb

Migreringsjobb har följande tillstånd:

Körde aldrig Ett nytt jobb som har definierats men aldrig körts.
Väntar Ett
jobb i det här tillståndet väntar på att resurser ska etableras i migreringstjänsten. Den växlar automatiskt till ett annat tillstånd när den är klar.
Misslyckades
Ett misslyckat jobb stötte på ett allvarligt fel som hindrar det från att bearbeta fler säkerhetskopior. Ett jobb förväntas inte ange det här tillståndet. En supportbegäran är den bästa åtgärden.
Avbrutna avbrutna /
endera och hela migreringsjobbet eller enskilda säkerhetskopior i jobbet kan avbrytas. Avbrutna säkerhetskopieringar bearbetas inte eftersom ett avbrutet migreringsjobb slutar bearbeta säkerhetskopior. Räkna med att det tar lång tid att avbryta ett jobb. Detta hindrar dig inte från att skapa ett nytt jobb. Det bästa sättet är att låta ett jobb komma in helt i tillståndet Avbrutet. Du kan antingen ignorera misslyckade/avbrutna jobb eller ta bort dem senare. Du behöver inte ta bort jobb innan du kan ta bort Data Manager-resursen i slutet av StorSimple-migreringen.

Att köra

ett jobb som körs bearbetar för närvarande en säkerhetskopia. Se tabellen på den nedre halvan av bladet för att se vilken säkerhetskopiering som bearbetas för närvarande och vilka som kan ha migrerats redan.
Redan migrerade säkerhetskopior har en kolumn med en länk till en kopieringslogg. Om en säkerhetskopia rapporterar några fel bör du granska dess kopieringslogg.

Pausad

Ett migreringsjobb pausas när ett beslut behövs. Det här villkoret aktiverar två kommandoknappar överst på bladet:
Välj Försök att säkerhetskopiera igen när säkerhetskopian visar filer som skulle flyttas men inte gjorde det (kolumnen Kopiera fel ).
Välj Hoppa över säkerhetskopiering när säkerhetskopieringen saknas (togs bort av principen sedan du skapade migreringsjobbet) eller när säkerhetskopian är skadad. Du hittar detaljerad felinformation på bladet som öppnas när du klickar på den misslyckade säkerhetskopieringen.

När du hoppar över eller försöker utföra den aktuella säkerhetskopieringen igen skapar migreringstjänsten en ny ögonblicksbild i din Azure-målfilresurs. Du kanske vill ta bort den föregående senare, eftersom den troligen är ofullständig.

Slutför och slutför med varningar Ett migreringsjobb

visas som Slutfört när alla säkerhetskopior i jobbet har bearbetats.
Komplett med varningar är ett tillstånd som inträffar när:

En säkerhetskopia stötte på ett återställningsbart problem. Den här säkerhetskopieringen markeras som delvis lyckad eller misslyckad.
Du bestämde dig för att fortsätta med det pausade jobbet genom att hoppa över säkerhetskopieringen med nämnda problem. (Du valde Hoppa över säkerhetskopiering i stället för att försöka säkerhetskopiera igen)

Om migreringsjobbet slutförs med varningar bör du alltid granska kopieringsloggen för relevanta säkerhetskopior.

Köra jobb parallellt

Du kommer förmodligen att ha flera StorSimple-volymer, var och en med sina egna resurser som måste migreras till en Azure-filresurs. Det är viktigt att du förstår hur mycket du kan göra parallellt. Det finns begränsningar som inte tillämpas i användarupplevelsen och som antingen försämrar eller hämmar en fullständig migrering om jobb körs samtidigt.

Det finns inga gränser för att definiera migreringsjobb. Du kan definiera samma StorSimple-källvolym, samma Azure-filresurs, på samma eller olika StorSimple-enheter. Att köra dem har dock begränsningar:

Endast ett migreringsjobb med samma StorSimple-källvolym kan köras samtidigt.
Endast ett migreringsjobb med samma Azure-målfilresurs kan köras samtidigt.
Innan du startar nästa jobb kontrollerar du att något av de tidigare jobben copy stage finns i och visar förloppet för att flytta filer i minst 30 minuter.
Du kan köra upp till fyra migreringsjobb parallellt per StorSimple-enhetshanterare, så länge du följer de tidigare reglerna.

När du försöker starta ett migreringsjobb kontrolleras de tidigare reglerna. Om det finns jobb som körs kanske du inte kan starta ett nytt jobb. Du får en avisering som visar namnet på jobb som körs och som måste slutföras innan du kan starta det nya jobbet.

Dricks

Det är en bra idé att regelbundet kontrollera dina migreringsjobb på fliken Jobbdefinition för din Data Manager-resurs för att se om någon av dem har pausats och behöver dina indata för att slutföras.

Sammanfattning av fas 3

I slutet av fas 3 har du kört minst ett av dina migreringsjobb från StorSimple-volymer till Azure-filresurser. Med körningen har du migrerat dina angivna säkerhetskopior till ögonblicksbilder av Azure-filresurser. Nu kan du fokusera på att antingen konfigurera Azure File Sync för resursen (när migreringsjobben för en resurs har slutförts) eller direktåtkomst för informationsarbetare och appar till Azure-filresursen.

Fas 4: Få åtkomst till dina Azure-filresurser

Det finns två huvudsakliga strategier för att komma åt dina Azure-filresurser:

Azure File Sync: Distribuera Azure File Sync till en lokal Windows Server-instans. Azure File Sync har alla fördelar med en lokal cache, precis som StorSimple.
Direct-share-access: Distribuera direct-share-access. Använd den här strategin om ditt åtkomstscenario för en viss Azure-filresurs inte drar nytta av lokal cachelagring, eller om du inte längre har möjlighet att vara värd för en lokal Windows Server-instans. Här fortsätter dina användare och appar att få åtkomst till SMB-resurser via SMB-protokollet. Dessa resurser finns inte längre på en lokal server utan direkt i molnet.

Du bör redan ha bestämt vilket alternativ som är bäst för dig i fas 1 i den här guiden.

Resten av det här avsnittet fokuserar på distributionsinstruktioner.

Följande ingår i den här videon:

Metoder för att komma åt Azure-filresurser
Azure File Sync
Direct-share-access
Distribuera Azure File Sync
Distribuera Azure File Sync-molnresursen
Distribuera en lokal Windows Server-instans
Förbereda Windows Server-instansen för Azure File Sync
Konfigurera Azure File Sync på Windows Server-instansen
Övervaka inledande synkronisering
Testa Azure File Sync
Skapa SMB-resurser

Distribuera Azure File Sync

Det är dags att distribuera en del av Azure File Sync.

Skapa Azure File Sync-molnresursen.
Distribuera Azure File Sync-agenten på din lokala server.
Registrera servern med molnresursen.

Skapa inga synkroniseringsgrupper än. Att konfigurera synkronisering med en Azure-filresurs bör endast ske efter att dina migreringsjobb till en Azure-filresurs har slutförts. Om du börjar använda Azure File Sync innan migreringen är klar blir migreringen onödigt svår eftersom du inte enkelt kan avgöra när det var dags att initiera en cut-over.

Distribuera Azure File Sync-molnresursen

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.

Dricks

Om du vill ändra den Azure-region som dina data finns i när migreringen är klar distribuerar du Tjänsten för synkronisering av lagring i samma region som mållagringskontona för den här migreringen.

Distribuera en lokal Windows Server-instans

Skapa Windows Server 2019 (minst 2012R2) som en virtuell dator eller fysisk server. Ett Windows Server-redundanskluster stöds också. Återanvänd inte servern som frontar StorSimple 8100 eller 8600.
Etablera eller lägga till direktansluten lagring. Nätverksansluten lagring stöds inte.

Det är bästa praxis att ge din nya Windows Server-instans lika med eller större lagringsutrymme än vad storSimple 8100 eller 8600-installationen har lokalt tillgänglig för cachelagring. Du använder Windows Server-instansen på samma sätt som du använde StorSimple-installationen. Om den har samma mängd lagringsutrymme som installationen bör cachelagringsupplevelsen vara liknande, om inte densamma. Du kan lägga till eller ta bort lagring från din Windows Server-instans efter be vilja. Med den här funktionen kan du skala din lokala volymstorlek och mängden lokal lagring som är tillgänglig för cachelagring.

Förbereda Windows Server-instansen för filsynkronisering

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.

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.

Viktigt!

StorSimple-migreringen av filer och mappar till Azure-filresursen måste vara klar innan du fortsätter. Kontrollera att inga fler ändringar görs i filresursen.

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.

Viktigt!

Se till att 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 ändå har det fullständiga namnområdet tillgängligt. Lokalt intressanta data cachelagras också lokalt för snabba prestanda. En annan anledning till att aktivera molnnivåindelning i det här steget är att vi inte vill synkronisera filinnehåll i det här skedet. Det är bara namnområdet som ska flyttas just nu.

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. Mer information finns i Nytt namn för Azure AD.

Sammanfattning av fas 4

I slutet av den här fasen har du skapat och kört flera migreringsjobb i StorSimple Data Manager. Dessa jobb har migrerat dina filer och mappar och deras säkerhetskopior till Azure-filresurser. Du har också distribuerat Azure File Sync eller förberett dina nätverks- och lagringskonton för direkt åtkomst till resurser.

Fas 5: Användarnedskärning

I den här fasen slutför du migreringen:

Planera din stilleståndstid.
Kom ikapp med eventuella ändringar som dina användare och appar har skapat på StorSimple-sidan medan migreringsjobben i fas 3 har körts.
Redundansväxla dina användare till den nya Windows Server-instansen med Azure File Sync eller till Azure-filresurserna via direkt resursåtkomst.

Följande ingår i den här videon:

Steg att vidta innan arbetsbelastningen skärs ned
Köra din cut-over
Efter cut-over-steg

Planera din stilleståndstid

Den här migreringsmetoden kräver viss stilleståndstid för dina användare och appar. Målet är att hålla stilleståndstiden till ett minimum. Följande överväganden kan vara till hjälp:

Håll dina StorSimple-volymer tillgängliga när du kör migreringsjobben.
När du har kört dina datamigreringsjobb för en resurs är det dags att ta bort användaråtkomst (minst skrivåtkomst) från StorSimple-volymerna eller resurserna. En slutlig RoboCopy kommer att fånga upp din Azure-filresurs. Sedan kan du skära över dina användare. Var du kör RoboCopy beror på om du valde att använda Azure File Sync eller direct-share-access. Det kommande avsnittet beskriver det ämnet.
När du har slutfört RoboCopy-kom ikapp är du redo att exponera den nya platsen för dina användare genom antingen Azure-filresursen direkt eller en SMB-resurs på en Windows Server-instans med Azure File Sync. Ofta hjälper en DFS-N-distribution till att snabbt och effektivt utföra en cut-over. Den håller dina befintliga resursadresser konsekventa och pekar om till en ny plats som innehåller dina migrerade filer och mappar.

För arkiveringsdata är det en fullt fungerande metod att ta stilleståndstid på StorSimple-volymen (eller undermappen), ta ytterligare en StorSimple-volymsäkerhetskopia, migrera och sedan öppna migreringsmålet för åtkomst av användare och appar. Detta besparar dig behovet av en catch-up RoboCopy. Den här metoden sker dock på bekostnad av ett långvarigt stilleståndstidsfönster som kan sträcka sig till flera dagar eller längre beroende på antalet filer och säkerhetskopior som du behöver migrera. Detta är förmodligen bara ett alternativ för arkiveringsarbetsbelastningar som kan göra utan skrivåtkomst under längre tidsperioder.

Ta reda på när namnområdet har synkroniserats fullständigt med servern

När du använder Azure File Sync för en Azure-filresurs är det viktigt att fastställa att hela namnområdet har laddats ned till servern innan du startar någon lokal RoboCopy. Hur mycket tid det tar att ladda ned namnområdet beror på antalet objekt i din Azure-filresurs. Det finns två metoder för att avgöra om namnområdet har kommit till servern.

Azure Portal

Du kan använda Azure-portalen för att se när ditt namnområde har anlänt helt.

Logga in på Azure-portalen och gå till synkroniseringsgruppen. Kontrollera synkroniseringsstatusen för synkroniseringsgruppen och serverslutpunkten.
Den intressanta riktningen är nedladdning. Om serverslutpunkten nyligen har etablerats visas inledande synkronisering, vilket indikerar att namnområdet fortfarande är nere. När tillståndet har ändrats till allt annat än Inledande synkronisering fylls namnområdet i helt på servern.

Nu kan du fortsätta med en lokal RoboCopy.

Windows Server Loggboken

Du kan också använda Loggboken på din Windows Server-instans för att se när namnområdet har anlänt helt.

Öppna Loggboken och gå till Program och tjänster.
Gå till och öppna Microsoft\FileSync\Agent\Telemetry.
Leta efter den senaste händelsen 9102, som motsvarar en slutförd synkroniseringssession.
Välj Information och bekräfta att du tittar på en händelse där SyncDirection-värdet är Ladda ned.
För den tid då namnområdet har laddats ned till servern kommer det att finnas en enda händelse med Scenario, värdet FullGhostedSync och HResult = 0.
Om du missar händelsen kan du även leta efter andra 9102-händelser med SyncDirection = Download and Scenario = "RegularSync". Att hitta en av dessa händelser indikerar också att namnområdet har laddats ned och synkroniseringen har slutförts till regelbundna synkroniseringssessioner, oavsett om det finns något att synkronisera eller inte just nu.

En sista RoboCopy

I det här läget finns det skillnader mellan din lokala Windows Server-instans och StorSimple 8100 eller 8600-installationen.

Du måste komma ikapp med de ändringar som användare eller appar som skapats på StorSimple-sidan medan migreringen pågick.
För fall där du använder Azure File Sync: StorSimple-installationen har en ifylld cache jämfört med Windows Server-instansen med bara ett namnområde utan filinnehåll som lagras lokalt just nu. Den sista RoboCopy kan hjälpa dig att få igång din lokala Azure File Sync-cache genom att hämta lokalt cachelagrat filinnehåll så mycket som är tillgängligt och får plats på Azure File Sync-servern.
Vissa filer kan ha lämnats kvar av migreringsjobbet på grund av ogiltiga tecken. I så fall kopierar du dem till Den Azure File Sync-aktiverade Windows Server-instansen. Senare kan du justera dem så att de synkroniseras. Om du inte använder Azure File Sync för en viss resurs är det bättre att byta namn på filerna med ogiltiga tecken på StorSimple-volymen. Kör sedan RoboCopy direkt mot Azure-filresursen.

Varning

Robocopy i Windows Server 2019 drabbades av ett problem som gjorde att filer nivåindelade av Azure File Sync på målservern kopierades från källan och laddades upp på nytt till Azure när funktionen används /MIR . Vi rekommenderar att du kör Robocopy på en annan Windows Server än 2019, till exempel Windows Server 2016.

Varning

Du får inte starta RoboCopy innan servern har hämtat namnområdet för en Azure-filresurs helt. Mer information finns i Ta reda på när ditt namnområde har laddats ned helt till servern.

Du vill bara kopiera filer som har ändrats efter att migreringsjobbet senast kördes och filer som inte har flyttats genom de här jobben tidigare. Du kan lösa problemet med varför de inte flyttades senare på servern när migreringen är klar. Mer information finns i Felsökning av Azure File Sync.

RoboCopy har flera parametrar. I följande exempel visas ett slutfört kommando och en lista över orsaker till att välja dessa parametrar.

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.

När du konfigurerar käll- och målplatser för RoboCopy-kommandot kontrollerar du att du granskar strukturen för källan och målet för att säkerställa att de matchar. Om du använde katalogmappningsfunktionen i migreringsjobbet kan rotkatalogstrukturen skilja sig från strukturen för din StorSimple-volym. Om så är fallet kan du behöva flera RoboCopy-jobb, ett för varje underkatalog. Om du är osäker på om kommandot fungerar som förväntat kan du använda parametern /L , som simulerar kommandot utan att göra några ändringar.

Det här RoboCopy-kommandot använder /MIR, så att det inte flyttar filer som är samma (nivåindelade filer, till exempel). Men om du får fel käll- och målsökväg rensar /MIR även katalogstrukturer på din Windows Server-instans eller Azure-filresurs som inte finns på StorSimple-källsökvägen. De måste matcha exakt för att RoboCopy-jobbet ska nå sitt avsedda mål att uppdatera ditt migrerade innehåll med de senaste ändringarna som gjorts medan migreringen pågår.

Läs RoboCopy-loggfilen för att se om filer har lämnats kvar. Om det finns problem kan du åtgärda dem och köra RoboCopy-kommandot igen. Avetablera inte några StorSimple-resurser innan du åtgärdar utestående problem för filer eller mappar som du bryr dig om.

Om du inte använder Azure File Sync för att cachelagrade den aktuella Azure-filresursen utan i stället valde direkt-resursåtkomst:

Montera din Azure-filresurs som en nätverksenhet på en lokal Windows-dator.
Utför RoboCopy mellan StorSimple och den monterade Azure-filresursen. Om filerna inte kopieras korrigerar du deras namn på StorSimple-sidan för att ta bort ogiltiga tecken. Försök sedan med RoboCopy igen. Det tidigare angivna RoboCopy-kommandot kan köras flera gånger utan att orsaka onödiga återkallanden till StorSimple.

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 du är mer benägna att flytta från nätverksdataflöde 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 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 /MIR-växeln för att fånga och försöka igen filer som inte kopieras.

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.

Windows Server 2022 och RoboCopy LFSM

RoboCopy-växeln /LFSM kan användas för att undvika att ett RoboCopy-jobb misslyckas med ett fullständigt volymfel. RoboCopy pausar när en filkopia gör att målvolymens lediga utrymme hamnar under ett "golv"-värde.

Använd RoboCopy med Windows Server 2022. Endast den här versionen av RoboCopy innehåller viktiga felkorrigeringar och funktioner som gör växeln kompatibel med ytterligare flaggor som behövs i de flesta migreringar. Till exempel kompatibilitet med /B flaggan.

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

Normalt kan RoboCopy köras på källan, målet eller en tredje dator.

Viktigt!

Om du tänker använda /LFSMmåste RoboCopy köras på Azure File Sync-målservern för Windows Server 2022.

Observera också att med /LFSM måste du också använda en lokal sökväg för målet, inte en UNC-sökväg. Som målsökväg bör du till exempel använda E:\Mappnamn i stället för en UNC-sökväg som \\ServerName\FolderName.

Varning

Den tillgängliga versionen av RoboCopy på Windows Server 2022 har en bugg som gör att pauserna räknas mot antalet fel per fil. Använd följande lösning.

De rekommenderade /R:2 /W:1 flaggorna ökar sannolikheten för att en fil misslyckas på grund av en /LFSM inducerad paus. I det här exemplet kommer en fil som inte kopierats efter 3 pauser på grund av /LFSM att pausen orsakades felaktigt att RoboCopy misslyckas med filen. Lösningen för detta är att använda högre värden för /R:n och /W:n. Ett bra exempel är /R:10 /W:1800 (10 återförsök på 30 minuter vardera). Detta bör ge Azure File Sync-nivåindelningsalgoritmen tid att skapa utrymme på målvolymen.

Den här buggen har åtgärdats men korrigeringen är ännu inte offentligt tillgänglig. I det här stycket finns uppdateringar om tillgängligheten för korrigeringen och hur du distribuerar den.

Klipp ut användare

Om du använder Azure File Sync måste du förmodligen skapa SMB-resurserna på den Azure File Sync-aktiverade Windows Server-instansen som matchar de resurser du hade på StorSimple-volymerna. Du kan läsa in det här steget i förväg och göra det tidigare för att inte förlora tid här. Men du måste se till att ingen tidigare har åtkomst till att orsaka ändringar i Windows Server-instansen.

Om du har en DFS-N-distribution kan du peka DFN-Namespaces till de nya servermappplatserna. Om du inte har någon DFS-N-distribution och du frontade din 8100- eller 8600-installation lokalt med en Windows Server-instans kan du ta bort servern från domänen. Domänanslut sedan din nya Azure File Sync-aktiverade Windows Server-instans. Under den processen ger du servern samma servernamn och resursnamn som den gamla servern så att cut-over förblir transparent för dina användare, grupprinciper och skript.

Läs mer om DFS-N.

Fas 6: Avetablering

När du avetablera en resurs förlorar du åtkomsten till konfigurationen av resursen och dess data. Det går inte att ångra avetablering. Fortsätt inte förrän du har bekräftat att:

Migreringen är klar.
Det finns inga som helst beroenden av StorSimple-filer, mappar eller volymsäkerhetskopior som du håller på att avetablera.

Innan du börjar är det bästa praxis att observera din nya Azure File Sync-distribution i produktion ett tag. Den tiden ger dig möjlighet att åtgärda eventuella problem som du kan stöta på. När du har observerat din Azure File Sync-distribution i minst några dagar kan du börja avetablera resurser i den här ordningen:

Avetablera din StorSimple Data Manager-resurs via Azure-portalen. Alla dina DTS-jobb tas bort med det. Du kan inte enkelt hämta kopieringsloggarna. Om de är viktiga för dina poster hämtar du dem innan du avetableras.
Kontrollera att dina fysiska StorSimple-enheter har migrerats och avregistrera dem. Om du inte är säker på att de har migrerats ska du inte fortsätta. Om du avetablera dessa resurser medan de fortfarande är nödvändiga kan du inte återställa data eller deras konfiguration.
Du kan också först avetablera StorSimple-volymresursen, som rensar data på enheten. Den här processen kan ta flera dagar och kommer inte att nollställa data på enheten. Om detta är viktigt för dig hanterar du disknollning separat från resursavetablering och enligt dina principer.
Om det inte finns fler registrerade enheter kvar i en StorSimple-Enhetshanteraren kan du fortsätta med att ta bort den Enhetshanteraren själva resursen.
Nu är det dags att ta bort StorSimple-lagringskontot i Azure. Stoppa och bekräfta att migreringen är klar och att ingenting och ingen är beroende av dessa data innan du fortsätter.
Koppla bort den fysiska StorSimple-installationen från ditt datacenter.
Om du äger StorSimple-apparaten kan du återanvända den. Om enheten hyrs ut informerar du uthyraren och returnerar enheten efter behov.

Migreringen är klar.

Kommentar

Har du fortfarande frågor eller har du stött på några problem?
Vi är här för att hjälpa dig: E-postadress med ett ord: Azure Files-migrering på microsoft dot com

Felsökning

När du använder StorSimple Data Manager-migreringstjänsten kan antingen ett helt migreringsjobb eller enskilda filer misslyckas av olika skäl. Avsnittet filåtergivning innehåller mer information om scenarier som stöds/som inte stöds. I följande tabeller listas felkoder, felinformation och, där det är möjligt, alternativ för minskning.

Fel på jobbnivå

Fas	Fel	Information/åtgärd
Säkerhetskopiering	Det gick inte att hitta en säkerhetskopia för de angivna parametrarna	Den säkerhetskopia som valts för jobbkörningen hittades inte vid tidpunkten för "Uppskattning" eller "Kopiera". Kontrollera att säkerhetskopieringen fortfarande finns i StorSimple-säkerhetskopieringskatalogen. Ibland tar principer för automatisk kvarhållning av säkerhetskopior bort säkerhetskopior mellan att välja dem för migrering och faktiskt köra migreringsjobbet för den här säkerhetskopieringen. Överväg att inaktivera eventuella scheman för kvarhållning av säkerhetskopior innan du påbörjar en migrering.
Beräkningsberäkning Konfigurera beräkning	Installationen av krypteringsnycklar misslyckades	Krypteringsnyckeln för tjänstdata är felaktig. Läs avsnittet med krypteringsnyckeln i den här artikeln för mer information och hjälp med att hämta rätt nyckel.
	Batch-fel	Det är möjligt att det uppstår ett problem när du startar all intern infrastruktur som krävs för att utföra en migrering. Flera andra tjänster är inblandade i den här processen. De här problemen löser sig vanligtvis när du försöker köra jobbet igen.
	Ett internt fel uppstod i StorSimple Manager. Vänta några minuter och försök sedan igen. Kontakta Microsoft Support om problemet kvarstår. (Felkod: 1074161829)	Det här allmänna felet har flera orsaker, men en möjlighet som påträffas är att StorSimple-enhetshanteraren har nått gränsen på 50 enheter. Kontrollera om de senaste körningsjobben i enhetshanteraren plötsligt har börjat misslyckas med det här felet, vilket tyder på att det här är problemet. Lösningen för det här problemet är att ta bort alla StorSimple 8001-enheter offline som skapats och används av Data Manager-tjänsten. Du kan skicka ett supportärende eller ta bort dem manuellt i portalen. Se till att endast ta bort offlineinstallationer i 8001-serien.
Beräkna filer	Det gick inte att klona volymjobbet	Det här felet indikerar troligen att du angav en säkerhetskopia som på något sätt var skadad. Migreringstjänsten kan inte montera eller läsa den. Du kan prova säkerhetskopieringen manuellt eller öppna ett supportärende.
	Det går inte att fortsätta eftersom volymen är i icke-NTFS-format	Endast NTFS-volymer, som inte är deduplicerade, kan användas av migreringstjänsten. Om du har en annan formaterad volym, till exempel ReFS eller ett format från tredje part, kan migreringstjänsten inte migrera den här volymen. Se avsnittet Kända begränsningar.
	Kontakta supporten. Ingen lämplig partition hittades på disken	Den StorSimple-disk som ska ha den angivna volymen för migrering verkar inte ha någon partition för den aktuella volymen. Det är ovanligt och kan tyda på en felaktig justering av hanteringen. Ditt enda alternativ för att undersöka problemet ytterligare är att skicka in ett supportärende.
	Tidsgränsen överskrids	Uppskattningsfasen misslyckas med en timeout är vanligtvis ett problem med antingen StorSimple-installationen eller att källvolymens säkerhetskopiering är långsam och ibland till och med skadad. Om det inte fungerar att köra säkerhetskopieringen igen är det bästa sättet att skicka in en supportbegäran.
	Det gick inte att hitta filsökvägen <> Det gick inte att hitta en del av sökvägen	Med jobbdefinitionen kan du ange en källundersökväg. Det här felet visas när den sökvägen inte finns. Till exempel: \Share1 > \Share\Share1 I det här exemplet har du angett \Share1 som en undersökväg i källan och mappa till en annan undersökväg i målet. Källsökvägen finns dock inte (var felstavad?). Obs! Windows är skiftlägesbevarande men inte skiftlägesberoende. Det innebär att ange \Share1 och \share1 är likvärdigt. Dessutom: Målsökvägar som inte finns skapas automatiskt.
	Den här begäran har inte behörighet att utföra den här åtgärden	Det här felet visar när lagringskontot för StorSimple-källan eller mållagringskontot med Azure-filresursen har en brandväggsinställning aktiverad. Du måste tillåta trafik över den offentliga slutpunkten och inte begränsa den med ytterligare brandväggsregler. Annars kommer datatransformeringstjänsten inte att kunna komma åt något lagringskonto, även om du har godkänt det. Inaktivera eventuella brandväggsregler och kör jobbet igen.
Kopiera filer	Det konto som används stöder inte HTTP	Inaktivera Internetroutning på mållagringskontot eller använd Microsofts routningsslutpunkt.
	Den angivna resursen är full	Om målet är en Premium Azure-filresurs kontrollerar du att du har etablerat tillräckligt med kapacitet för resursen. Tillfällig överetablering är en vanlig metod. Om målet är en Azure-standardfilresurs kontrollerar du att målresursen har funktionen "stor filresurs" aktiverad. Standardlagringen växer när du använder resursen. Men om du använder ett äldre lagringskonto som mål kan du stöta på en resursgräns på 5 TiB. Du måste aktivera funktionen "Stor filresurs" manuellt. Åtgärda gränserna för målet och kör jobbet igen.

Fel på objektnivå

Under kopieringsfasen för en migreringsjobbkörning kan enskilda namnområdesobjekt (filer och mappar) stöta på fel. I följande tabell visas de vanligaste felen och förslag på åtgärdsalternativ när det är möjligt.

Fas	Fel	Åtgärd
Kopiera	-2146233088 Servern är upptagen.	Kör jobbet igen om det finns för många fel. Om det bara finns mycket få fel kan du försöka köra jobbet igen, men ofta kan en manuell kopia av de misslyckade objekten gå snabbare. Återuppta sedan migreringen genom att hoppa över för att bearbeta nästa säkerhetskopia.
	-2146233088 åtgärden kunde inte slutföras inom den angivna tiden.	Kör jobbet igen om det finns för många fel. Om det bara finns mycket få fel kan du försöka köra jobbet igen, men ofta kan en manuell kopia av de misslyckade objekten gå snabbare. Återuppta sedan migreringen genom att hoppa över för att bearbeta nästa säkerhetskopia.
	Tidsgränsen för uppladdning eller kopiering har inte startats	Kör jobbet igen om det finns för många fel. Om det bara finns mycket få fel kan du försöka köra jobbet igen, men ofta kan en manuell kopia av de misslyckade objekten gå snabbare. Återuppta sedan migreringen genom att hoppa över för att bearbeta nästa säkerhetskopia.
	-2146233029 Åtgärden avbröts.	Kör jobbet igen om det finns för många fel. Om det bara finns mycket få fel kan du försöka köra jobbet igen, men ofta kan en manuell kopia av de misslyckade objekten gå snabbare. Återuppta sedan migreringen genom att hoppa över för att bearbeta nästa säkerhetskopia.
	1920 Filen kan inte nås av systemet.	Det här är ett vanligt fel när migreringsmotorn stöter på en referenspunkt, länk eller korsning. De stöds inte. Dessa typer av filer kan inte kopieras. Läs avsnittet Kända begränsningar och avsnittet Filåtergivning i den här artikeln.
	-2147024891 Åtkomst nekas	Det här är ett fel för filer som krypteras på ett sätt som de inte kan nås på disken. Filer som kan läsas från disken men helt enkelt har krypterat innehåll påverkas inte och kan kopieras. Det enda alternativet är att kopiera dem manuellt. Du kan hitta sådana objekt genom att montera den berörda volymen och köra följande kommando: `get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue \| Where-Object {$_.Attributes -ge "Encrypted"} \| format-list fullname, attributes`
	Inte en giltig Win32 FileTime. Parameternamn: fileTime	I det här fallet kan filen nås men kan inte utvärderas för kopiering eftersom en tidsstämpel som migreringsmotorn är beroende av antingen är skadad eller har skrivits av ett program i ett felaktigt format. Det finns inte mycket du kan göra eftersom du inte kan ändra tidsstämpeln i säkerhetskopian. Om det är viktigt att behålla den här filen, kanske i den senaste versionen (den senaste säkerhetskopian som innehåller den här filen) kopierar du filen manuellt, åtgärdar tidsstämpeln och flyttar den sedan till Azure-målfilresursen. Det här alternativet skalas inte särskilt bra, men är ett alternativ för filer med högt värde där du vill att minst en version ska behållas i målet.
	-2146232798 Valv handtag har stängts	Ofta ett tillfälligt fel. Kör jobbet igen om det finns för många fel. Om det bara finns mycket få fel kan du försöka köra jobbet igen, men ofta kan en manuell kopia av de misslyckade objekten gå snabbare. Återuppta sedan migreringen genom att hoppa över för att bearbeta nästa säkerhetskopia.
	-2147024413 Allvarligt maskinvarufel för enheten	Det här är ett sällsynt fel och rapporteras inte för en fysisk enhet, utan snarare virtualiserade 8001-seriens virtualiserade enheter som används av migreringstjänsten. Installationen stötte på ett problem. Filer med det här felet hindrar inte migreringen från att fortsätta till nästa säkerhetskopia. Det gör det svårt för dig att utföra en manuell kopiering eller försöka utföra säkerhetskopieringen igen som innehåller filer med det här felet. Om filerna som lämnas kvar är mycket viktiga eller om det finns ett stort antal filer kan du behöva starta migreringen av alla säkerhetskopior igen. Öppna ett supportärende för ytterligare undersökning.
Ta bort (speglingsrensning)	Den angivna katalogen är inte tom.	Det här felet uppstår när migreringsläget är inställt på spegling och processen som tar bort objekt från Azure-filresursen stötte på ett problem som hindrade den från att ta bort objekt. Borttagning sker endast i den aktiva resursen, inte från tidigare ögonblicksbilder. Borttagningen är nödvändig eftersom de berörda filerna inte finns i den aktuella säkerhetskopieringen och därför måste tas bort från den aktiva resursen före nästa ögonblicksbild. Det finns två alternativ: Alternativ 1: Montera Azure-målfilresursen och ta bort filerna med det här felet manuellt. Alternativ 2: Du kan ignorera dessa fel och fortsätta bearbeta nästa säkerhetskopia med en förväntan att målet inte är identiskt med källan och har några extra objekt som inte fanns i den ursprungliga StorSimple-säkerhetskopieringen.
	Felaktig begäran	Det här felet anger att källfilen har vissa egenskaper som inte kunde kopieras till Azure-filresursen. Framför allt kan det finnas osynliga kontrolltecken i ett filnamn eller 1 byte med ett dubbelt bytetecken i filnamnet eller filsökvägen. Du kan använda kopieringsloggarna för att hämta sökvägsnamn, kopiera filerna till en tillfällig plats, byta namn på sökvägarna för att ta bort de tecken som inte stöds och sedan robocopy igen till Azure-filresursen. Du kan sedan återuppta migreringen genom att hoppa över till nästa säkerhetskopiering som ska bearbetas.

Nästa steg

Förstå flexibiliteten i principer för molnnivåindelning .
Aktivera Azure Backup på dina Azure-filresurser för att schemalägga ögonblicksbilder och definiera scheman för kvarhållning av säkerhetskopior.
Om du ser att vissa filer inte synkroniseras permanent i Azure-portalen kan du läsa felsökningsguiden för steg för att lösa dessa problem.

StorSimple 8100- och 8600-migrering till Azure File Sync

Fas 1: Förbered för migrering

Lager

Kostnadssammanfattning för migrering

Direct-share-access jämfört med Azure File Sync

StorSimple-tjänstens datakrypteringsnyckel

Ändra krypteringsnyckeln för tjänstdata

Steg 1: Använd Windows PowerShell-skript för att auktorisera en enhet för att ändra krypteringsnyckeln för tjänstdata

Vilka enheter kan ha behörighet att ändra krypteringsnycklar för tjänstdata?

Steg 2: Använd Windows PowerShell för StorSimple för att initiera nyckeländringen för tjänstdatakryptering

Så här initierar du ändringen av krypteringsnyckeln för tjänstdata

Steg 3: Uppdatera krypteringsnyckeln för tjänstdata på andra StorSimple-enheter

Uppdatera krypteringsnyckeln för tjänstdata på fysiska enheter

Uppdatera krypteringsnyckeln för tjänstdata på alla 8010/8020-molninstallationer

Kända begränsningar

Filåtergivning

StorSimple-volymsäkerhetskopior

Mappa dina befintliga StorSimple-volymer till Azure-filresurser

Dela gruppering

Volymsynkronisering

En strukturerad metod för en distributionskarta

Vanliga scenarier och överväganden för filsynkronisering

Skapa en mappningstabell

Antal lagringskonton

Inställningar för lagringskonto

Sammanfattning av fas 1

Fas 2: Distribuera Azure Storage- och migreringsresurser

Distribuera lagringskonton

Prenumeration

Resursgrupp

Lagringskontonamn

Plats

Prestanda

Replikering

Aktivera 100 TiB-kapacitetsfilresurser

Azure-filresurser

StorSimple-datahanterare

Azure File Sync

Sammanfattning av fas 2

Fas 3: Skapa och köra ett migreringsjobb

Källa

Mål

Katalogmappning

Välja volymsäkerhetskopior som ska migreras

Katalogmappning

Semantiska element

Exempel

Semantiska regler

Köra ett migreringsjobb

Fel per objekt

Hantera ett migreringsjobb

Köra jobb parallellt

Sammanfattning av fas 3

Fas 4: Få åtkomst till dina Azure-filresurser

Distribuera Azure File Sync

Distribuera Azure File Sync-molnresursen

Distribuera en lokal Windows Server-instans

Förbereda Windows Server-instansen för filsynkronisering

Konfigurera Azure File Sync på Windows Server-instansen

Distribuera direct-share-access

Sammanfattning av fas 4

Fas 5: Användarnedskärning

Planera din stilleståndstid

Ta reda på när namnområdet har synkroniserats fullständigt med servern

Azure Portal

Windows Server Loggboken

En sista RoboCopy

Felsöka och optimera

Överväganden för IOPS och bandbredd

Bearbetningshastighet

Undvik onödigt arbete

Windows Server 2022 och RoboCopy LFSM

Klipp ut användare

Fas 6: Avetablering

Felsökning

Fel på jobbnivå

Fel på objektnivå

Nästa steg

Ytterligare resurser