Dela via

Tillförlitlighet i Azure Backup

Azure Backup är en inbyggd Azure tjänst som skyddar molnbaserade och lokala arbetsbelastningar på ett säkert sätt. Säkerhetskopiering kan skala sitt skydd över flera arbetsbelastningar och ger inbyggd integrering med Azure-arbetsbelastningar, inklusive virtuella datorer, SAP Hana i Azure virtuella datorer, SQL i Azure virtuella datorer, Azure Files, Azure Blob Storage, Azure Data Lake Storage, Azure Managed Disks, Azure Elastic SAN volumes och Azure Kubernetes Service (AKS). Du behöver inte hantera automatisering eller infrastruktur, skriva skript eller etablera lagring.

När du använder Azure är reliability ett delat ansvar. Microsoft tillhandahåller en rad funktioner som stöder återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur säkerhetskopiering kan vara motståndskraftig mot en mängd olika potentiella avbrott och problem, inklusive tillfälliga fel, avbrott i tillgänglighetszonen och regionstopp. Den visar också viktig information om serviceavtalet för säkerhetskopiering (SLA).

Anmärkning

Den här artikeln beskriver hur själva säkerhetskopieringstjänsten är motståndskraftig mot olika problem och hur du kan göra den mer motståndskraftig. Den förklarar inte hur du använder Säkerhetskopiering för att skydda dina virtuella datorer, data eller andra tillgångar. Mer information om hur du använder säkerhetskopiering finns i Översikt över säkerhetskopiering.

Rekommendationer för produktionsdistribution för tillförlitlighet

För att säkerhetskopiera dina produktionsarbetsbelastningar rekommenderar vi att du konfigurerar valvet på följande sätt:

  • Använd zonredundant lagring (ZRS) som lägsta redundansnivå för dina säkerhetskopior. ZRS replikerar dina säkerhetskopior över flera tillgänglighetszoner så att du kan återställa dina säkerhetskopior under ett avbrott i tillgänglighetszonen.

  • Om du använder geo-redundant lagring (GRS) för att replikera dina säkerhetskopior till en länkad Azure region aktiverar du återställning mellan regioner (CRR) för datakällor som stöds. MED CRR kan du återställa säkerhetskopiorna till den kopplade regionen när som helst.

Följande avsnitt i den här artikeln innehåller mer information om dessa konfigurationer.

Anmärkning

Dessa rekommendationer för lagringsredundans gäller för platser där säkerhetskopior replikeras, inte för säkerhetskopieringstjänsten eller de resurser som du säkerhetskopierar. Säkerhetskopieringsskydd och lagringsredundans kompletterar varandra. Säkerhetskopior skyddar mot dataförlust och redundans skyddar mot infrastrukturfel.

En lista över andra rekommendationer för säkerhetskopiering, inklusive tillförlitlighetsfokuserade rekommendationer, finns i Säkerhetskopieringsmoln och lokala arbetsbelastningar till molnet.

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Säkerhetskopiering kan säkerhetskopiera och återställa en mängd olika datakällor. Du konfigurerar säkerhetskopieringar på olika sätt beroende på vilken datakälla du arbetar med. Följande datakällor är vanliga:

  • Azure virtuella datorer
  • Olika databaser
  • Blob Storage konton
  • AKS-kluster
  • Lokala servrar via mars-agenten (Microsoft Azure Recovery Services)

Säkerhetskopiering lagrar dina data i valv. Valv är onlinelagringsentiteter i Azure som innehåller data, till exempel säkerhetskopior, återställningspunkter och säkerhetskopieringsprinciper. Recovery Services-valv och Backup-valv är två typer av valv. Du kan använda en eller båda typerna beroende på vad du behöver skydda. En lista över de datakällor som varje valvtyp stöder finns i Vanliga frågor och svar om valv som stöds för säkerhetskopiering och återställning.

Jobb representerar processen att säkerhetskopiera eller återställa dina data. Säkerhetskopieringsjobb omfattar schemalagda åtgärder eller åtgärder på begäran som kopierar dina data från källan till valvet. Återställningsjobb omfattar åtgärder som återställer dina data från lagring av säkerhetskopior till en målplats. Varje jobb har en unik identifierare och statusspårning så att du kan övervaka förloppet och felsöka problem som uppstår under säkerhetskopierings- och återställningsåtgärder. Du skapar även säkerhetskopieringsprinciper som är associerade med jobb. Principer anger konfiguration som säkerhetskopieringsschemat och hur länge du vill behålla data.

Valv lagrar dina säkerhetskopieringsprinciper och konfiguration tillsammans med metadata om jobb, vilket gör att du kan spåra jobb och felsöka.

Fysisk arkitektur

Microsoft hanterar kärninfrastrukturen för säkerhetskopieringstjänsten. Den här infrastrukturen ansvarar för hantering och drift av tjänsten, inklusive utlösande och övervakningsjobb.

Backup lagrar säkerhetskopior i valvet. Säkerhetsvalv byggs på Azure Storage. Valv replikerar automatiskt dina säkerhetskopierade data, och säkerhetskopieringens hållbarhet och återhämtning beror på valvets lagringsredundans.

  • Lokalt redundant lagring (LRS) replikerar data i valvet till en eller flera Azure tillgänglighetszoner som finns i den primära regionen. Du kan inte välja önskad tillgänglighetszon, men Azure kan flytta eller expandera LRS-konton mellan zoner för att förbättra belastningsutjämningen. Dina data är inte garanterade att spridas över zoner. Mer information finns i Översikt över tillgänglighetszoner.

  • ZRS och GRS ger extra skydd. I den här artikeln beskrivs de här alternativen i detalj.

Anmärkning

Vissa datakällor stöder säkerhetskopiering på driftnivå , som lagrar data på en annan plats i stället för i valvet. Till exempel Azure säkerhetskopiering av hanterade diskar och AKS-säkerhetskopieringar stöd för säkerhetskopiering på driftnivå, som lagras i diskögonblicksbilder. Den här artikeln beskriver inte lagring av säkerhetskopiering på driftnivå, men du kan använda återhämtningsvägledningen i den här artikeln för säkerhetskopieringsåtgärder och arbetsflöden för dessa säkerhetskopieringstyper.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för Azure övergående felhantering när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av tillfälliga fel.

När du använder Säkerhetskopiering är både arbetsflöden för säkerhetskopiering och återställning motståndskraftiga mot tillfälliga fel. Tjänsten försöker automatiskt igen när den stöter på tillfälliga nätverksfel eller tillfälliga tjänstavbrott. Du konfigurerar ingen logik för återförsök. Om det uppstår upprepade fel kan du läsa Felsöka hanteringsåtgärder för säkerhetskopieringsvalv.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Säkerhetskopiering hanterar separat konfigurationen av tillgänglighetszonen för tjänsten och för din data.

  • Tjänst: Säkerhetskopieringstjänsten är automatiskt zontålig i regioner som stöds. Den här inbyggda zonåterhämtningen gäller dock inte för dina säkerhetskopierade data.

  • Redundans för säkerhetskopieringslagring: Välj den redundansnivå som du vill ha för dina säkerhetskopierade data genom att konfigurera recovery services-valvet eller säkerhetskopieringsvalvet. Om du väljer ZRS lagras kopior av dina säkerhetskopierade data automatiskt i flera tillgänglighetszoner i den Azure region som du använder.

    Om du inte använder ZRS betraktas dina säkerhetskopierade data som icke-zonbaserade och kan lagras i valfri zon. Om någon zon i regionen har problem kan icke-zonbaserade säkerhetskopieringsdata vara otillgängliga.

Diagram som visar kärntjänsten Backup, som automatiskt är zontålig och zonredundant säkerhetskopieringslagring.

Kravspecifikation

Kostnad

När du aktiverar ZRS för dina säkerhetskopior debiteras du med en annan hastighet än LRS på grund av den extra replikeringen och lagringskostnaderna. Mer information finns i Prissättning för säkerhetskopiering.

Konfigurera stöd för tillgänglighetszoner

  • Skapa ett nytt valv som använder ZRS: Konfigurera lagringsredundans när du skapar ett valv. Du följer olika steg beroende på valvtyp. Mer information finns i följande artiklar:

  • Konfigurera ZRS för befintliga valv: För Säkerhetskopieringsvalv konfigurerar du lagringsredundans när du skapar valvet. När du har skapat ett säkerhetskopieringsvalv är inställningen låst och du kan inte ändra den.

    För Recovery Services-valv måste du konfigurera lagringsredundans innan du skyddar arbetsbelastningar. När du har skyddat en arbetsbelastning är inställningen låst och du kan inte ändra den.

    Du kan skapa ett nytt valv som konfigurerats för att använda ZRS och omtilldela dina arbetsbelastningar till det nya valvet. Den här metoden kräver dock stilleståndstid. Mer information finns i Ändra standardinställningar. Du ansvarar också för att manuellt ta bort befintliga återställningspunkter och andra data eftersom det gamla valvets kvarhållningsprinciper inte längre gäller. Mer information finns i Ta bort ett säkerhetskopieringsvalv eller Ta bort ett Recovery Services-valv.

Beteende när alla zoner är felfria

I det här avsnittet beskrivs vad du kan förvänta dig när du konfigurerar valv för ZRS och alla zoner är i drift.

  • Drift mellan zoner: Säkerhetskopieringsjobb körs på infrastruktur som replikerats över zoner. Azure hanterar jobb från infrastruktur i valfri zon.

  • Datareplikering mellan zoner: ZRS replikerar säkerhetskopierade data mellan zoner. Replikeringen sker synkront, vilket innebär att flera zoner bekräftar varje skrivåtgärd innan den slutförs.

Beteende vid ett zonfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar valv för ZRS och det uppstår ett avbrott i någon av zonerna.

  • Upptäckt och svar: För själva säkerhetskopieringstjänsten ansvarar Microsoft för att identifiera fel i tillgänglighetszoner och svara. Du behöver inte göra något för att påbörja en zone-failover.

    Viktigt!

    För data eller resurser som inte är tillgängliga på grund av zonstoppet ansvarar du för att identifiera avbrott och vidta återställningsåtgärder, inklusive återställning av säkerhetskopior till en felfri zon.

  • Notification: Microsoft meddelar dig inte automatiskt när en zon är nere. Du kan dock använda Azure Resource Health för att övervaka hälsotillståndet för en enskild resurs, och du kan konfigurera Resource Health aviseringar för att meddela dig om problem. Du kan också använda Azure Service Health för att förstå tjänstens övergripande hälsotillstånd, inklusive eventuella zonfel, och du kan konfigurera Service Health-aviseringar för att meddela dig om problem.

  • Aktiva begäranden: Beteendet för aktiva jobb beror på vilken zon som misslyckas.

    • För alla datakällor i den misslyckade tillgänglighetszonen gör zonfelet datakällorna otillgängliga. Aktiva jobb kan pausas eller misslyckas.

    • För alla datakällor i felfria tillgänglighetszoner som kör aktiva jobb kan en liten mängd stilleståndstid, vanligtvis några sekunder, inträffa medan plattformen växlar till felfria tillgänglighetszoner för säkerhetskopieringstjänsten.

  • Förväntad dataförlust: Den förväntade mängden dataförlust kallas även mål för återställningspunkt (RPO). RPO för dina säkerhetskopieringsdata beror på flera faktorer, inklusive säkerhetskopieringsschemat. För ett zonstopp förväntas i allmänhet ingen förlust av säkerhetskopierade data eftersom alla data replikeras synkront mellan zoner.

  • Förväntad stilleståndstid: Den förväntade stilleståndstiden kallas även för mål för återställningstid (RTO). RTO är olika för vart och ett av följande scenarier:

    • För alla datakällor i den misslyckade tillgänglighetszonen kanske datakällorna inte är tillgängliga förrän zonen återställs. Backupjobb kanske inte körs förrän datakällan är tillgänglig igen. RTO är odefinierat.

    • För alla datakällor i felfria tillgänglighetszoner kan en liten mängd stilleståndstid, vanligtvis några sekunder, inträffa medan plattformen växlar till felfria tillgänglighetszoner för säkerhetskopieringstjänsten.

  • Omfördelning: Efterföljande jobbkörningar använder automatiskt infrastruktur i friska zoner så länge datakällorna är tillgängliga.

    Du ansvarar för att återställa säkerhetskopieringen till infrastrukturen i en felfri zon och för att konfigurera om lastbalanserare, klienter och andra system för att omdirigera trafik till en felfri infrastruktur i den nya zonen.

Zonåterställning

När tillgänglighetszonen återställs återställer Backup automatiskt åtgärder i tillgänglighetszonen och omdirigerar trafik mellan zonerna som vanligt. Jobb fortsätter att köras och data är fortfarande tillgängliga.

Test för zonfel

Säkerhetskopieringsplattformen hanterar trafikroutning, datareplikering, redundans och återställning efter fel. Den här funktionen är helt hanterad, så du behöver inte initiera eller verifiera felprocesser i tillgänglighetszonen.

Motståndskraft mot regionomfattande fel

Säkerhetskopiering stöder geo-redundans och failover-redundans via GRS och CRR.

Viktigt!

GRS för säkerhetskopiering fungerar endast i parade Azure-regioner.

Geo-redundant lagring samt återställning mellan regioner

Använd Säkerhetskopiering för att replikera dina säkerhetskopior till en Azure parkopplad region med hjälp av GRS för att uppnå regional redundans för dina säkerhetskopieringsdata. GRS skyddar dina säkerhetskopior från regionala avbrott.

Den region som du distribuerar valvet till kallas för den primära regionen. Dina datakällor måste finnas i den primära regionen. Du kan inte konfigurera säkerhetskopior till ett valv i en annan region.

Den kopplade regionen kallas även för den sekundära regionen.

Diagram som visar hur data replikeras med hjälp av GRS.

Om du inte konfigurerar GRS och ett avbrott inträffar i valvets region kanske du kan komma åt valvet och visa säkerhetskopieringsobjekt. Men utan regional redundans förblir underliggande säkerhetskopieringsdata inte tillgängliga för återställningsåtgärder.

Återställning mellan regioner

När du konfigurerar GRS i ett valv gör Microsoft säkerhetskopior i den kopplade regionen tillgängliga efter ett avbrott i den primära regionen. Om datakällan har stöd för CRR kan du återställa från sekundära återställningspunkter även när inget avbrott inträffar i den primära regionen. MED CRR kan du också köra övningar för att utvärdera återhämtning mot regionala avbrott. När du aktiverar CRR uppgraderar Microsoft din lagring av säkerhetskopior från GRS till geo-redundant lagring med läsåtkomst (RA-GRS).

Kravspecifikation

  • Regionstöd: GRS för Backup fungerar endast inom parade Azure-regioner.

  • Endast nya valv: Du måste konfigurera GRS i valvet innan den första säkerhetskopieringen sker.

Överväganden

  • CRR: När du har aktiverat CRR kan det ta upp till 48 timmar innan säkerhetskopieringsobjekt är tillgängliga i den sekundära regionen.

Kostnad

GRS-valv medför extra kostnader för replikering och lagring mellan regioner i den sekundära regionen. Dataöverföring mellan Azure regioner debiteras baserat på standardbandbredden mellan regioner. CRR debiteras till ett annat pris eftersom Microsoft uppgraderar valvlagringen från GRS till RA-GRS. Mer information finns i Prissättning för säkerhetskopiering.

Konfigurera stöd för flera regioner

  • Skapa ett nytt valv som använder GRS och CRR: När du skapar ett valv bör du även konfigurera lagringsredundans. När du har valt GRS kan du valfritt aktivera CRR på valvet. Vilka steg du följer beror på valvtypen. Mer information finns i följande artiklar:

  • Konfigurera GRS och CRR för befintliga valv: För Säkerhetskopieringsvalv måste du konfigurera lagringsredundans när du skapar valvet.

    För Recovery Services-valv måste du konfigurera lagringsredundans innan du skyddar arbetsbelastningar. När en arbetsbelastning har skyddats är inställningen låst och du kan inte ändra den.

    Du kan aktivera CRR för befintliga GRS-valv. När du har aktiverat CRR kan du inte inaktivera det.

Beteende när alla regioner är felfria

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar valv för att använda GRS och alla regioner fungerar.

  • Åtgärd mellan regioner: Säkerhetskopior slutförs alltid i den primära regionen, vilket är den region där valvet och datakällan distribueras.

  • Datareplikering mellan regioner: När du konfigurerar valvet för att använda GRS lagras säkerhetskopiorna först i den primära regionen via LRS. När det har slutförts i den primära regionen replikeras data asynkront till den sekundära regionen. Den sekundära regionen använder LRS för att lagra data. Säkerhetskopieringsdata kan ta upp till 12 timmar att replikera från den primära regionen till den sekundära regionen.

Beteende under ett regionfel

Det här avsnittet beskriver vad du kan förvänta dig när du konfigurerar valv för användning av GRS och ett avbrott inträffar i den primära regionen.

  • Identifiering och svar: För datakällor som har stöd för CRR och där CRR är aktiverat i valvet kan du när som helst initiera din egen CRR till den kopplade regionen, inklusive under ett regionstopp eller en katastrof. Du ansvarar för att identifiera avbrott och vidta återställningsåtgärder, inklusive återställning av säkerhetskopior till en felfri region.

    För alla andra scenarier är data som replikeras till den sekundära regionen tillgängliga för återställning i den sekundära regionen endast om Azure deklarerar en katastrof i den primära regionen. Microsoft ansvarar för att förklara en katastrof. Hur lång tid det tar att deklarera en katastrof beror på incidentens allvarlighetsgrad och hur lång tid det tar att bedöma situationen. Microsoft deklarerar vanligtvis en katastrof först efter en längre tidsperiod.

  • Notification: Microsoft meddelar dig inte automatiskt när en region är nere. Observera följande:

  • Förväntad dataförlust: RPO för dina säkerhetskopieringsdata beror på flera faktorer, inklusive säkerhetskopieringsschemat. I allmänhet för ett regionstopp kan du förvänta dig upp till 36 timmars dataförlust eftersom RPO i den primära regionen är 24 timmar och det kan ta upp till 12 timmar att replikera säkerhetskopierade data från den primära till den sekundära regionen.

  • Förväntad stilleståndstid: RTO är olika för vart och ett av följande scenarier:

    • Datakällor och andra resurser i den misslyckade regionen kanske inte är tillgängliga förrän regionen återställs, så RTO är odefinierat.

    • Säkerhetskopiering kanske inte kan utföra säkerhetskopierings- eller återställningsåtgärder i den drabbade regionen förrän regionen återställs, så RTO är ej definierad.

    • Om du använder CRR är RTO (återställningstidens mål) för att initiera återställningen av säkerhetskopior som redan replikerats till den kopplade regionen noll. Om du inte använder CRR beror RTO på hur lång tid det tar för Microsoft att deklarera en katastrof i den misslyckade regionen.

  • Omfördelning: Inga säkerhetskopieringsjobb kan köras medan den primära regionen är offline. Du kan återställa data i valvet, men du kan inte lägga till nya data.

    Du ansvarar för att återställa säkerhetskopieringen till infrastrukturen i den kopplade regionen och för att konfigurera om lastbalanserare, klienter och andra system för att omdirigera trafik till en felfri infrastruktur i den kopplade regionen.

Regionåterställning

När den primära regionen återställs återställer Backup automatiskt åtgärder i regionen. Jobb återupptas och data är fortfarande tillgängliga.

Test för regionfel

Du kan använda CRR för att utföra en återställningsåtgärd till den kopplade regionen. Du kan använda den här metoden för att verifiera återställning och andra återställningsprocesser.

Motståndskraft mot förlust av säkerhetskopierade data

Säkerhetskopiering innehåller två viktiga återställningsfunktioner för att förhindra oavsiktlig eller skadlig borttagning av dina säkerhetskopierade data:

  • Med mjuk borttagning kan du återställa borttagna objekt och valv under en konfigurerbar kvarhållningsperiod. Som standard är den här perioden 14 dagar, men du kan redigera den. Tänk på mjuk borttagning som en papperskorg för dina säkerhetskopior och valv. Mer information finns i Skydda som standard med mjuk borttagning för säkerhetskopiering.

  • Oföränderliga valv kan hjälpa dig att skydda dina säkerhetskopierade data genom att blockera åtgärder som kan leda till förlust av återställningspunkter. Du kan låsa inställningen för det oföränderliga valvet så att det blir oåterkalleligt. Du kan också använda skriv en gång, läs många (WORM)-lagring för säkerhetskopior för att hindra skadliga aktörer från att inaktivera oföränderlighet och radera säkerhetskopior. Mer information finns i Oföränderligt valv för säkerhetskopiering.

Serviceavtal

Serviceavtalet (SLA) för Azure tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i SLAs for online služby.

Serviceavtalet för säkerhetskopiering omfattar tjänstens tillgänglighet för både säkerhetskopierings- och återställningsåtgärder. För att omfattas av serviceavtalet måste du försöka med misslyckade säkerhetskopierings- eller återställningsjobb minst en gång var 30:e minut.

Relaterat innehåll

  • Last updated on