Metodtips för haveriberedskap med Azure File Sync

För Azure File Sync finns det tre huvudsakliga områden att överväga för haveriberedskap: hög tillgänglighet, dataskydd/säkerhetskopiering och dataredundans. Den här artikeln beskriver varje område och hjälper dig att avgöra vilken konfiguration som ska användas för din egen haveriberedskapslösning.

I en Azure File Sync distribution innehåller molnslutpunkten alltid en fullständig kopia av dina data, medan den lokala servern kan ses som en disponibel cache av dina data. I händelse av en katastrof på serversidan kan du återställa genom att etablera en ny server, installera Azure File Sync agenten på den och konfigurera den som en ny serverslutpunkt.

På grund av dess hybridkaraktär fungerar vissa traditionella strategier för säkerhetskopiering och haveriberedskap inte med Azure File Sync. För alla registrerade servrar stöder Azure File Sync inte:

Varning

Om du vidtar någon av dessa åtgärder kan det leda till problem med synkronisering eller brutna nivåindelade filer som resulterar i eventuell dataförlust. Om du har vidtagit någon av dessa åtgärder kontaktar du Azure Support för att säkerställa att distributionen är felfri.

• Överföra/klona diskenheter (volym) från en server till en annan medan serverslutpunkten fortfarande är aktiv
• Återställa från en säkerhetskopia av operativsystemet
• Klona en servers operativsystem till en annan server
• Återgå till en tidigare kontrollpunkt för virtuella datorer
• Återställa nivåindelade filer från lokal säkerhetskopiering (tredje part) till serverslutpunkten

Hög tillgänglighet

Det finns två olika strategier som du kan använda för att uppnå hög tillgänglighet för din lokala server. Du kan antingen konfigurera ett redundanskluster eller konfigurera en standby-server. Den avgörande faktorn mellan någon av konfigurationerna är hur mycket du är villig att investera i systemet, och om det är värt den extra kostnaden om du minimerar den tid som systemet är nere vid en katastrof.

För ett redundanskluster behöver du inte vidta några särskilda åtgärder för att använda Azure File Sync. För en standby-server bör du göra följande konfigurationer:

Ha en sekundär server med olika serverslutpunkter som synkroniseras till samma synkroniseringsgrupp som din primära server, men som inte aktiverar slutanvändaråtkomst till servern. På så sätt kan alla filer synkroniseras från den primära servern till väntelägesservern. Du kan överväga att aktivera nivåindelning endast för namnområden så att endast namnområdet laddas ned från början. Om den primära servern misslyckas kan du använda DFS-N för att snabbt konfigurera om slutanvändaråtkomsten till väntelägesservern.

Dataskydd/säkerhetskopiering

Att skydda dina faktiska data är en viktig komponent i en haveriberedskapslösning. Det finns två huvudsakliga sätt att göra detta med dina Azure-filresurser: du kan antingen säkerhetskopiera dina data i molnet eller lokalt. Vi rekommenderar starkt att du säkerhetskopierar dina data i molnet eftersom molnslutpunkten innehåller en fullständig kopia av dina data, medan serverslutpunkter kanske bara innehåller en delmängd av dina data.

Säkerhetskopiera dina data i molnet

Du bör använda Azure Backup som molnlösning för säkerhetskopiering. Azure Backup hanterar bland annat schemaläggning, kvarhållning och återställning av säkerhetskopior. Om du vill kan du manuellt ta resursögonblicksbilder och konfigurera din egen lösning för schemaläggning och kvarhållning, men det här är inte idealiskt. Du kan också använda lösningar från tredje part för att direkt säkerhetskopiera dina Azure-filresurser.

Om en katastrof inträffar kan du återställa från en resursögonblicksbild, vilket är en skrivskyddad kopia av filresursen. Eftersom dessa ögonblicksbilder är skrivskyddade påverkas de inte av utpressningstrojaner. För stora datauppsättningar där återställningsåtgärder för fullständiga resurser tar lång tid kan du aktivera direkt användaråtkomst till ögonblicksbilden så att användarna kan kopiera de data de behöver till sin lokala enhet medan återställningen slutförs.

Ögonblicksbilder lagras direkt i din Azure-filresurs, oavsett om du tar dem manuellt eller om Azure Backup tar dem åt dig. Därför bör du aktivera mjuk borttagning för att skydda dina ögonblicksbilder mot oavsiktlig borttagning av filresursen.

Mer information finns i Om säkerhetskopiering av Azure-filresurser eller kontakta din säkerhetskopieringsleverantör för att se om de stöder säkerhetskopiering av Azure-filresurser.

Säkerhetskopiera dina data lokalt

Om du aktiverar molnnivåindelning ska du inte implementera en lokal säkerhetskopieringslösning. När molnnivåindelning är aktiverat lagras endast en delmängd av dina data lokalt på servern. Resten av dina data lagras i molnslutpunkten. Beroende på vilken säkerhetskopieringslösning du använder för en lokal säkerhetskopiering är nivåindelade filer antingen:

• hoppas över och inte säkerhetskopieras (på grund av deras FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS attribut) eller
• de säkerhetskopieras endast som en nivåindelad fil och kanske inte är tillgängliga vid återställning på grund av ändringar i liveresursen, eller
• de kommer att återkallas till disken, vilket resulterar i höga avgifter för utgående trafik.

Om du bestämmer dig för att använda en lokal säkerhetskopieringslösning bör du utföra säkerhetskopieringar på en server i synkroniseringsgruppen med molnnivåindelning inaktiverad. När du utför en återställning använder du återställningsalternativen på volymnivå eller filnivå. Filer som återställs med återställningsalternativet på filnivå synkroniseras till alla slutpunkter i synkroniseringsgruppen och befintliga filer ersätts med den version som återställs från säkerhetskopian. Återställningar på volymnivå ersätter inte nyare filversioner i molnslutpunkten eller andra serverslutpunkter.

Vss-ögonblicksbilder (Volume Shadow Copy Service) (inklusive fliken Tidigare versioner ) stöds på volymer med molnnivåindelning aktiverat. På så sätt kan du utföra självbetjäningsåterställningar i stället för att förlita dig på att en administratör utför återställningar åt dig. Du måste dock aktivera tidigare versionskompatibilitet via PowerShell, vilket ökar kostnaderna för ögonblicksbildlagring. VSS-ögonblicksbilder skyddar inte mot katastrofer på själva serverslutpunkten, så de bör endast användas tillsammans med säkerhetskopieringar på molnsidan. Mer information finns i Självbetjäningsåterställning via tidigare versioner och VSS.

Dataredundans

För att säkerställa en robust haveriberedskapslösning lägger du till någon form av dataredundans i infrastrukturen. Det finns fyra redundanserbjudanden för Azure Files: Lokalt redundant lagring (LRS),zonredundant lagring (ZRS),geo-redundant lagring (GRS) och geozonredundant lagring (GZRS).

• Lokalt redundant lagring (LRS): Med LRS lagras varje fil tre gånger i ett Azure Storage-kluster. Detta skyddar mot dataförlust på grund av maskinvarufel, till exempel en felaktig diskenhet. Men om en katastrof som brand eller översvämning inträffar i datacentret kan alla repliker av ett lagringskonto som använder LRS gå förlorade eller oåterkalleliga.
• Zonredundant lagring (ZRS): Med ZRS lagras tre kopior av varje fil, men dessa kopior är fysiskt isolerade i tre distinkta lagringskluster i olika Azure-tillgänglighetszoner. Tillgänglighetszoner är unika fysiska platser i en Azure-region. Varje zon består av ett eller flera datacenter som är utrustade med oberoende ström, kylning och nätverk. En skrivning till lagring accepteras inte förrän den har skrivits till lagringskluster i alla tre tillgänglighetszonerna.
• Geo-redundant lagring (GRS): Med GRS har du två regioner, en primär och sekundär region. Filer lagras tre gånger i ett Azure Storage-kluster i den primära regionen. Skrivningar replikeras asynkront till en Microsoft-definierad sekundär region. GRS tillhandahåller sex kopior av dina data som sprids mellan två Azure-regioner.
• Geozonredundant lagring (GZRS): Du kan betrakta GZRS som om det vore ZRS men med geo-redundans. Med GZRS lagras filer tre gånger över tre distinkta lagringskluster i den primära regionen. Alla skrivningar replikeras sedan asynkront till en Microsoft-definierad sekundär region.

För en robust haveriberedskapslösning bör de flesta kunder överväga ZRS. ZRS lägger till den minsta extra kostnaden för dess extra fördelar med dataredundans och är också den mest sömlösa i händelse av ett avbrott. Om organisationens policy- eller regelkrav kräver geo-redundans för dina data bör du överväga antingen GRS eller GZRS.

Geo-redundans

Om ditt lagringskonto har konfigurerats med antingen GRS- eller GZRS-replikering initierar Microsoft redundansväxlingen av tjänsten för synkronisering av lagring om den primära regionen bedöms vara permanent oåterkallelig eller otillgänglig under lång tid. Ingen åtgärd krävs från dig i händelse av en katastrof.

Även om du manuellt kan begära en redundansväxling av tjänsten för synkronisering av lagring till din länkade GRS- eller GZRS-region rekommenderar vi inte att du gör detta utanför storskaliga regionala avbrott eftersom processen inte är sömlös och kan medföra extra kostnader. Starta processen genom att öppna ett supportärende och begära att både dina Azure-lagringskonton som innehåller din Azure-filresurs och Tjänsten för synkronisering av lagring ska redväxas.

Varning

Du måste kontakta supporten för att begära att lagringssynkroniseringstjänsten redväxeras om du initierar den här processen manuellt. Om du försöker skapa en ny tjänst för synkronisering av lagring med samma serverslutpunkter i den sekundära regionen kan det leda till att extra data finns kvar i lagringskontot eftersom den tidigare installationen av Azure File Sync inte rensas.

När en redundansväxling inträffar växlar serverslutpunkterna över för att automatiskt synkronisera med molnslutpunkten i den sekundära regionen. Serverslutpunkterna måste dock stämmas av med molnslutpunkterna. Detta kan leda till filkonflikter eftersom data i den sekundära regionen kanske inte fångas upp till den primära regionen.

Nästa steg

Läs mer om säkerhetskopiering av Azure-filresurser