Redigera

Share via


Säkerhetskopiera filer och program på Azure Stack Hub

Microsoft Entra ID
Azure Backup
Azure ExpressRoute
Azure Stack Hub
Azure Storage

Tänk dig en situation där Azure Stack Hub är värd för virtuella datorer som kör användararbetsbelastningar. Det finns ett behov av att säkerhetskopiera och återställa filerna och programmen för arbetsbelastningarna. Den här referensarkitekturartikeln beskriver en metod som ger en optimerad lösning för säkerhetskopierings- och återställningsaktiviteter.

Arkitektur

Diagram illustrating backup of Azure Stack Hub files and applications that are hosted on Azure VMs that run such workloads as SQL Server, SharePoint Server, Exchange Server, File Server, and Active Directory Domain Services domain controllers. The backup relies on Azure Backup Server that run on a Windows Server VM, with a geo-replicated Azure Recovery Services vault providing long-term storage. Initial backups can be performed by using Azure Import/Export service. Optionally, Azure ExpressRoute can provide high-bandwidth connectivity to Azure.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Molnkomponenterna innehåller följande tjänster:

  • En Azure-prenumeration som är värd för alla molnresurser som ingår i den här lösningen.
  • En Microsoft Entra-klientorganisation som är associerad med Azure-prenumerationen. Den tillhandahåller autentisering av Microsoft Entra-säkerhetsobjekt för att auktorisera åtkomst till Azure-resurser.
  • Ett Azure Recovery Services-valv i Azure-regionen som ligger närmast det lokala datacenter som är värd för Azure Stack Hub-distributionen.

Beroende på de kriterier som presenteras i den här artikeln kan molnkomponenter även innehålla följande tjänster:

  • En Azure ExpressRoute-krets som ansluter det lokala datacentret och Azure-regionen som är värd för Azure Recovery Services-valvet. Kretsen är konfigurerad att ha Microsoft-peering för att hantera större säkerhetskopieringsstorlekar.

  • Azure Import/Export-tjänsten för aktivering av MABS offlinesäkerhetskopior till Azure.

    Kommentar

    Från och med 08/20 är MABS offlinesäkerhetskopiering till Azure som använder Azure Data Box i förhandsversion.

Beroende på användningen av Azure Import/Export-tjänsten för MABS offlinesäkerhetskopiering till Azure kan lösningen också ha ett Azure Storage-konto i samma Azure-region som Recovery Services-valvet.

De lokala komponenterna innehåller följande tjänster:

  • Ett Azure Stack Hub-integrerat system i den anslutna distributionsmodellen som kör den aktuella uppdateringen (2002 från och med augusti 2020) och som finns i kundens lokala datacenter.

  • En virtuell Windows Server 2016- eller Windows Server 2019-dator som hanteras av det Azure Stack Hub-integrerade systemet och som kör MABS v3 Update Release (UR) 1.

  • Virtuella Azure Stack Hub-datorer med MABS-skyddsagenten, som hanterar säkerhetskopieringar till och återställningar från den virtuella DATORN MABS Azure Stack Hub. MABS-skyddsagenten spårar ändringar i skyddade arbetsbelastningar och överför ändringarna till MABS-datalagret. Skyddsagenten identifierar också data på sin lokala dator som kan skyddas och spelar en roll i återställningsprocessen.

  • En Microsoft Azure Recovery Services-agent (MARS) som är installerad på servern som kör MABS. Agenten integrerar MABS- och Azure Recovery Services-valv.

    Kommentar

    En MARS-agent kallas även för en Azure Backup-agent.

Komponenter

Alternativ

Den rekommenderade lösningen som beskrivs i den här artikeln är inte det enda sättet att tillhandahålla säkerhetskopierings- och återställningsfunktioner till användararbetsbelastningar som körs på Azure Stack Hub. Kunder har andra alternativ, inklusive:

  • Lokal säkerhetskopiering och återställning med hjälp av windows serversäkerhetskopieringsfunktionen som ingår i Windows Server-operativsystemet. Användarna kan sedan kopiera lokala säkerhetskopior till långsiktig lagring. Den här metoden stöder programkonsekventa säkerhetskopieringar genom att förlita sig på Windows VSS-leverantörer, men ökar den lokala diskutrymmesanvändningen och underhållskostnaderna för säkerhetskopiering.
  • Säkerhetskopiera och återställa med hjälp av Azure Backup med den lokalt installerade MARS-agenten. Den här metoden minimerar användningen av lokalt diskutrymme och automatiserar processen med att ladda upp säkerhetskopior till molnbaserad lagring. Den stöder dock inte programkonsekventa säkerhetskopieringar.
  • Säkerhetskopiera och återställa med hjälp av en säkerhetskopieringslösning som är installerad i samma datacenter men utanför Azure Stack Hub. Den här metoden underlättar scenarier som omfattar en frånkopplad distributionsmodell i Azure Stack Hub.
  • Säkerhetskopiering och återställning på Azure Stack Hub-nivå med hjälp av diskögonblicksbilder. Den här metoden kräver att den virtuella dator som säkerhetskopieras stoppas, vilket vanligtvis inte är ett genomförbart alternativ för affärskritiska arbetsbelastningar, men kan vara acceptabelt i vissa scenarier.

Information om scenario

Säkerhetskopiering och återställning är viktiga komponenter i en omfattande strategi för affärskontinuitet och haveriberedskap. Det är svårt att utforma och implementera en konsekvent och tillförlitlig säkerhetskopieringsmetod i en hybridmiljö, men det kan förenklas avsevärt genom integrering med Microsoft Azure-tjänster. Detta gäller inte bara för arbetsbelastningar som körs på traditionell lokal infrastruktur, utan även för arbetsbelastningar som hanteras av offentliga och privata molnleverantörer från tredje part. Fördelarna med integrering med Azure-tjänster är dock tydliga när hybridmiljöerna innehåller Azure Stack-portföljerbjudanden, inklusive Azure Stack Hub.

En av de främsta fördelarna med Azure Stack Hub är att den stöder PaaS-modellen (platform-as-a-service), men den hjälper även kunderna att modernisera sina befintliga IaaS-arbetsbelastningar (infrastruktur som en tjänst). Sådana arbetsbelastningar kan omfatta filresurser, Microsoft SQL Server-databaser, Microsoft SharePoint-servergrupper och Microsoft Exchange Server-kluster. Om du migrerar dem till virtuella datorer som körs på hyperkonvergerade, mycket motståndskraftiga kluster som har administrativa modeller och programmeringsmodeller som är konsekventa med Microsoft Azure resulterar det i minimerade kostnader för hantering och underhåll.

För att implementera säkerhetskopiering av filer och program som körs på virtuella Azure Stack Hub-datorer rekommenderar Microsoft en hybridmetod som förlitar sig på en kombination av molnkomponenter och lokala komponenter för att leverera en skalbar, högpresterande, elastisk, säker, enkel hantering och kostnadseffektiv säkerhetskopieringslösning. Den centrala komponenten i den här lösningen är Microsoft Azure Backup Server (MABS) v3, som ingår i Azure Backup-erbjudandet. MABS förlitar sig på Azure Stack Hub-infrastruktur för beräknings-, nätverks- och kortsiktiga lagringsresurser och använder Azure-baserad lagring för att fungera som långsiktig säkerhetskopieringslagring. Den här metoden minimerar eller eliminerar behovet av att underhålla fysiska säkerhetskopieringsmedier, till exempel band.

Kommentar

MABS baseras på Microsoft System Center Data Protection Manager (DPM) och ger liknande funktioner med bara några få skillnader. DPM stöds dock inte för användning med Azure Stack Hub.

Kärnfunktioner

Den föreslagna lösningen stöder följande funktioner på virtuella Azure Stack Hub-datorer som kör Windows Server 2019, 2016, 2012 R2, 2012, 2008 R2 SP1 (64-bitars med Windows Management Framework 4.0), 2008 SP2 (64-bitars med Windows Management Framework 4.0) och Windows 10 (64-bitars):

  • Säkerhetskopiering och återställning av volymer, resurser, mappar, filer och systemtillstånd för New Technology File System (NTFS) och Resilient File System (ReFS).

  • Säkerhetskopiering och återställning av SQL Server 2019, 2017, 2016 (med nödvändiga service pack(SPs)) och 2014 (med nödvändiga SPs) instanser och deras databaser.

  • Säkerhetskopiering och återställning av Exchange Server 2019- och Exchange Server 2016-servrar och -databaser, inklusive fristående servrar och databaser i en databastillgänglighetsgrupp (DAG).

  • Återställning av enskilda postlådor och postlådedatabaser i en DAG.

  • Säkerhetskopiering och återställning av SharePoint 2019 och SharePoint 2016 (med de senaste IP-adresserna) och klientwebbserverinnehåll.

  • Återställning av SharePoint 2019- och SharePoint 2016-databaser, webbprogram, filer, listobjekt och sökkomponenter.

    Kommentar

    Om du vill distribuera Windows 10-klientoperativsystem på Azure Stack Hub måste du ha Windows-licensiering per användare eller ha köpt det via en QMTH (Qualified Multitenant Hoster).

MABS implementerar säkerhetskopieringsschemat disk-to-disk-to-cloud (D2D2C), med den primära säkerhetskopieringen som lagras lokalt på den server som är värd för MABS-installationen. Lokala säkerhetskopior kopieras sedan till ett Azure Site Recovery-valv. Den lokala disken fungerar som kortsiktig lagring, medan valvet tillhandahåller långsiktig lagring.

Kommentar

Till skillnad från DPM stöder MABS inte bandsäkerhetskopior.

Säkerhetskopieringsprocessen består av följande fyra steg:

  1. Du installerar MABS-skyddsagenten på en dator som du vill skydda och lägger till den i en skyddsgrupp.
  2. Du konfigurerar skydd för datorn eller dess app, inklusive säkerhetskopiering till lokala MABS-diskar för kortsiktig lagring och till Azure för långsiktig lagring. Som en del av installationen anger du säkerhetskopieringsschemat för båda typerna av säkerhetskopior.
  3. Den skyddade arbetsbelastningen säkerhetskopieras till de lokala MABS-diskarna enligt det schema som du angav.
  4. Den lokala säkerhetskopian som lagras på MABS-diskar säkerhetskopieras till Azure Recovery Services-valvet av MARS-agenten som körs på MABS-servern.

Förutsättningar

Implementeringen av den rekommenderade lösningen beror på att du uppfyller följande krav:

  • Åtkomst till en Azure-prenumeration med behörigheter som räcker för att etablera ett Azure Recovery Services-valv i Azure-regionen som är närmast ett lokalt datacenter som är värd för Azure Stack Hub-distributionen.

  • En Active Directory-domän Services-domän (AD DS) som är tillgänglig från en virtuell Azure Stack Hub-dator som ska vara värd för en MABS-instans.

  • En Azure Stack Hub-värdbaserad virtuell dator som ska köra en MABS-instans som uppfyller de krav som anges i Installera Azure Backup Server på Azure Stack och med utgående anslutning till URL:er som anges i DPM/MABS-nätverksstöd.

    Kommentar

    Ytterligare diskutrymme och prestandaöverväganden för MABS beskrivs mer detaljerat senare i den här artikeln.

    Kommentar

    Om du vill kontrollera om den virtuella datorn som är värd för MABS har anslutning till Azure Backup-tjänsten kan du använda cmdleten Get-DPMCloud Anslut ion (ingår i Azure Backup Server PowerShell-modulen).

    Kommentar

    MABS kräver också en lokal instans av SQL Server. Mer information om SQL Server-krav finns i Installera och uppgradera Azure Backup Server.

Datatyper

Ur MABS-perspektivet finns det två datatyper att tänka på:

  • Fildata är data som vanligtvis finns på filservrar (till exempel Microsoft Office-filer, textfiler eller mediefiler) och som måste skyddas som flata filer.
  • Programdata är data som finns på programservrar (till exempel Exchange Storage-grupper, SQL Server-databaser eller SharePoint-servergrupper) och som kräver att MABS är medvetet om motsvarande programkrav.

Kommentar

Som ett alternativ till säkerhetskopiering av fildata med MABS är det möjligt att installera MABS-agenten direkt på en virtuell Azure Stack Hub-dator och säkerhetskopiera det lokala filsystemet direkt till ett Azure Recovery Services-valv. Men till skillnad från MABS tillhandahåller den här metoden inte centraliserad hantering och förlitar sig alltid på molnbaserad lagring för säkerhetskopior och återställningar.

Säkerhetskopieringstyper

Oavsett om du skyddar fildata eller programdata börjar skyddet med att skapa en replik av datakällan i den lokala lagringen av en MABS-instans. Repliken synkroniseras eller uppdateras med jämna mellanrum enligt de inställningar som du konfigurerar. Vilken metod MABS använder för att synkronisera repliken beror på vilken typ av data som skyddas. Om en replik identifieras som inkonsekvent utför MABS en konsekvenskontroll, vilket är en block-för-block-verifiering av repliken mot datakällan.

För en filvolym eller resurs på en server använder MABS-skyddsagenten ett volymfilter och en ändringsjournal för att avgöra vilka filer som har ändrats efter den första fullständiga säkerhetskopieringen. Den utför sedan en kontrollsummaprocedur för dessa filer för att endast synkronisera de ändrade blocken. Under synkroniseringen överförs dessa ändringar till MABS och tillämpas sedan på repliken, vilket synkroniserar repliken med datakällan.

Om en replik blir inkonsekvent med datakällan genererar MABS en avisering som anger vilken dator och vilka datakällor som påverkas. Du kan lösa problemet genom att reparera repliken genom att initiera en synkronisering med konsekvenskontroll på repliken. Under en konsekvenskontroll utför MABS en block-för-block-verifiering och reparerar repliken för att returnera den till konsekvens med datakällan. Du kan schemalägga en daglig konsekvenskontroll för skyddsgrupper eller initiera en konsekvenskontroll manuellt.

Med jämna mellanrum som du kan konfigurera skapar MABS en återställningspunkt för den skyddade datakällan. En återställningspunkt är en version av de data som kan återställas.

För programdata spåras ändringar av volymblock som tillhör programfiler efter att repliken har skapats av MABS av volymfiltret. Hur ändringar överförs till MABS-servern beror på programmet och typen av synkronisering. Åtgärden som är märkt synkronisering i MABS-administratörskonsolen motsvarar en inkrementell säkerhetskopia, och den skapar en transaktionsmässigt konsekvent och korrekt återspegling av programdata när den kombineras med repliken.

Under den typ av synkronisering som är märkt med fullständig säkerhetskopiering i MABS-administratörskonsolen skapas en fullständig ögonblicksbild av Volume Shadow Copy Service (VSS), men endast de ändrade blocken överförs till MABS-servern.

Varje fullständig snabbsäkerhetskopia skapar en återställningspunkt för programdata. Om programmet stöder inkrementella säkerhetskopior skapar varje synkronisering även en återställningspunkt. Synkroniseringsprocessen är programberoende:

  • För Exchange-data överför synkronisering en inkrementell VSS-ögonblicksbild med hjälp av Exchange VSS-skrivaren. Återställningspunkter skapas för varje synkronisering och för varje fullständig snabbsäkerhetskopia.
  • SQL Server-databaser som är logglevererade, som är i skrivskyddat läge eller som använder den enkla återställningsmodellen, stöder inte inkrementell säkerhetskopiering. Återställningspunkter skapas endast för varje fullständig snabbsäkerhetskopia. För alla andra SQL Server-databaser överför synkroniseringen en säkerhetskopia av transaktionsloggen, med återställningspunkter som skapas för varje inkrementell synkronisering och snabb fullständig säkerhetskopiering. Transaktionsloggen är en seriepost för alla transaktioner som har utförts mot databasen sedan transaktionsloggen senast säkerhetskopierades.
  • SharePoint-servrar stöder inte inkrementell säkerhetskopiering. Återställningspunkter skapas endast för varje fullständig snabbsäkerhetskopia.

Inkrementella synkroniseringar kräver mindre tid än det tar att göra en fullständig snabbsäkerhetskopia. Den tid som krävs för att återställa data ökar dock när antalet synkroniseringar ökar. Det beror på att MABS måste återställa den senaste fullständiga säkerhetskopian och sedan återställa och tillämpa alla inkrementella synkroniseringar fram till den tidpunkt som har angetts för återställning.

För att möjliggöra snabbare återställningstid utför MABS regelbundet en fullständig snabb säkerhetskopia, som uppdaterar repliken så att den inkluderar de ändrade blocken. Under den fullständiga snabbsäkerhetskopian tar MABS en ögonblicksbild av repliken innan repliken uppdateras med hjälp av de ändrade blocken. För att aktivera mer frekventa RRPOs och minska dataförlustfönstret utför MABS även inkrementella synkroniseringar under tiden mellan två fullständiga snabbsäkerhetskopior.

Precis som med fildataskydd, om en replik blir inkonsekvent med dess datakälla, genererar MABS en avisering som anger vilken server och vilka datakällor som påverkas. För att lösa inkonsekvensen kan du reparera repliken genom att initiera en synkronisering med konsekvenskontroll på repliken. Under en konsekvenskontroll utför MABS en block-för-block-verifiering av repliken och reparerar den för att få den tillbaka i konsekvens med datakällorna. Du kan schemalägga en daglig konsekvenskontroll för skyddsgrupper eller initiera en konsekvenskontroll manuellt.

Skyddsprinciper

En dator eller dess arbetsbelastning skyddas när du installerar MABS-skyddsagentens programvara på datorn och lägger till data för datorn eller dess arbetsbelastning i en skyddsgrupp. Skyddsgrupper används för att konfigurera och hantera skyddet av datakällor på datorer. En skyddsgrupp är en samling datakällor som delar samma skyddskonfiguration. Skyddskonfigurationen är en samling inställningar som är gemensamma för en skyddsgrupp, till exempel skyddsgruppens namn, skyddsprincip, lagringsallokeringar och metoden för att skapa repliker.

MABS lagrar en separat replik av varje skyddsgruppmedlem i lagringspoolen. En medlem i skyddsgruppen kan innehålla sådana datakällor som:

  • En volym, resurs eller mapp på en filserver eller ett serverkluster.
  • En lagringsgrupp för en Exchange-server eller ett serverkluster.
  • En databas för en instans av SQL Server eller serverkluster.

För varje skyddsgrupp konfigurerar du en skyddsprincip som baseras på dina återställningsmål för den skyddsgruppen. Återställningsmål representerar dataskyddskrav som motsvarar organisationens RTO:er och RRPO:er. I MABS definieras de baserat på en kombination av följande parametrar:

  • Kortsiktigt kvarhållningsintervall. Detta avgör hur länge du vill behålla säkerhetskopierade data på den lokala MABS-lagringen.

  • Frekvenser för synkroniserings- och återställningspunkter. Detta motsvarar direkt dataförlusttolerans, vilket i sin tur återspeglar organisationens RPOs. Den avgör också hur ofta MABS ska synkronisera sina lokala repliker med skyddade datakällor genom att samla in sina dataändringar. Du kan ange synkroniseringsfrekvensen till valfritt intervall mellan 15 minuter och 24 timmar. Du kan också välja att synkronisera precis innan en återställningspunkt skapas i stället för enligt ett angivet tidsschema.

  • Kortsiktigt återställningspunktschema. Detta anger hur många återställningspunkter som ska skapas i den lokala lagringen för skyddsgruppen. För filskydd väljer du de dagar och tider som du vill att återställningspunkter ska skapas för. För dataskydd för program som stöder inkrementella säkerhetskopieringar avgör synkroniseringsfrekvensen schemat för återställningspunkter.

  • Express fullständigt säkerhetskopieringsschema. Det här är återställningspunktsschemat för dataskydd för program som inte stöder inkrementella säkerhetskopieringar och som stöder fullständiga expresssäkerhetskopior.

  • Onlinesäkerhetskopieringsschema. Detta avgör hur ofta du skapar en kopia av lokala säkerhetskopior i Azure Recovery Services-valvet som är associerat med den lokala MABS-instansen. Du kan schemalägga varje dag, varje vecka, varje månad eller varje år, med maximal tillåten frekvens på två säkerhetskopior per dag. MABS skapar automatiskt en återställningspunkt för onlinesäkerhetskopieringar med hjälp av den senaste lokala repliken, utan att överföra nya data från den skyddade datakällan.

    Kommentar

    Ett Recovery Services-valv stöder så många som 9 999 återställningspunkter.

  • Kvarhållningsprincip online. Detta anger den tidsperiod under vilken dagliga, veckovisa, månatliga och årliga säkerhetskopieringar behålls i Azure Site Recovery-valvet som är associerat med den lokala MABS-instansen.

    Kommentar

    Om du vill skydda det senaste innehållet i datakällan online skapar du en ny återställningspunkt på den lokala disken innan du skapar en onlineåterställningspunkt.

    Kommentar

    Som standard är Azure Recovery Services-valvet geo-redundant, vilket innebär att alla säkerhetskopior som kopieras till dess lagring automatiskt replikeras till en Azure-region som ingår i ett fördefinierat regionpar. Du kan ändra replikeringsinställningarna till lokalt redundanta om det räcker för dina återhämtningsbehov och om du behöver minimera lagringskostnaderna. Du bör dock överväga att behålla standardinställningen. Det här alternativet kan inte ändras om valvet innehåller några skyddade objekt.

Testa återställningar

Förutom en optimalt utformad och implementerad säkerhetskopieringsstrategi är det lika viktigt att definiera, dokumentera och testa återställningsprocessen för varje typ av skyddad arbetsbelastning. Även om MABS tillhandahåller inbyggda konsekvenskontroller som automatiskt verifierar integriteten för datasäkerhetskopior, bör testningen av återställningar vara en del av rutinmässiga driftprocedurer. Testningen validerar en återställning genom att undersöka tillståndet för återställde arbetsbelastningar. Testresultaten ska vara tillgängliga för arbetsbelastningsägare.

I allmänhet tenderar testning av återställningar att vara utmanande eftersom det kräver en miljö som liknar den som är värd för de skyddade arbetsbelastningarna. Azure Stack Hub, med sin inbyggda DevOps och infrastruktur som kodfunktioner, förenklar avsevärt hanteringen av den här utmaningen.

Roller och ansvar

Planering för och implementering av säkerhetskopiering och återställning av Azure Stack Hub-baserade arbetsbelastningar innebär vanligtvis interaktion mellan många intressenter:

  • Azure Stack Hub-operatorer. Azure Stack Hub-operatörer hanterar Azure Stack Hub-infrastrukturen, säkerställer att det finns tillräckligt med beräknings-, lagrings- och nätverksresurser för att implementera en omfattande säkerhetskopierings- och återställningslösning och göra dessa resurser tillgängliga för klientorganisationer. De samarbetar också med program- och dataägare för att fastställa den optimala metoden för att distribuera sina arbetsbelastningar till Azure Stack Hub.
  • Azure-administratörer. Azure-administratörer hanterar de Azure-resurser som behövs för att implementera hybridsäkerhetslösningar.
  • Microsoft Entra-administratörer. Microsoft Entra-administratörer hanterar Microsoft Entra-resurser, inklusive användar- och gruppobjekt som används för att etablera, konfigurera och hantera Azure-resurser.
  • IT-personal för Azure Stack Hub-klientorganisationen. Dessa intressenter utformar, implementerar och hanterar MABS, inklusive MABS-säkerhetskopieringar och återställningar.
  • Azure Stack Hub-användare. Dessa användare tillhandahåller RPO- och RTO-krav och skickar begäranden för att säkerhetskopiera och återställa data och program.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

Azure Stack Hub hjälper till att öka tillgängligheten för arbetsbelastningen på grund av den återhämtning som är inbyggd i infrastrukturen. Du kan öka tillgängligheten ytterligare genom att utforma och implementera lösningar som utökar arbetsbelastningsskyddets omfattning. Det här är det mervärde som MABS tillhandahåller. När det gäller MABS som körs på Azure Stack Hub finns det två aspekter av tillgänglighet som behöver utforskas mer detaljerat:

  • Tillgängligheten för MABS och dess datalager
  • Tillgängligheten för återställning till tidpunkt för MABS-skyddade arbetsbelastningar

Du måste tänka på båda dessa när du utvecklar en säkerhetskopieringsstrategi som drivs av mål för återställningspunkter (RPO: er) och mål för återställningstid (RTO). RTO och RPO representerar kontinuitetskrav som anges av affärsfunktioner inom en organisation. RPO anger en tidsperiod som representerar den maximala acceptabla dataförlusten på grund av en incident som gör data otillgängliga under en tid. RTO anger den maximala godkända varaktighet som det kan ta att återställa åtkomsten till affärsfunktioner efter en incident som gör funktionerna otillgängliga.

Kommentar

För att uppfylla RTO-kraven för Azure Stack Hub-arbetsbelastningar bör du ta hänsyn till återställningen av Azure Stack-infrastrukturen, virtuella användardatorer, program och användardata. I den här artikeln överväger vi endast de två sista av dessa program och användardata, även om vi även presenterar överväganden när det gäller tillgängligheten för MBS-funktionerna (Modern Backup Storage).

Tillgängligheten för MABS och dess datalager beror på tillgängligheten för den virtuella dator som är värd för MABS-installationen och dess lokala och molnbaserade lagring. Virtuella Azure Stack Hub-datorer är mycket tillgängliga avsiktligt. Om det uppstår ett MABS-fel kan du återställa Azure Backup-skyddade objekt från andra virtuella Azure Stack Hub-datorer som är värdar för MABS. Observera dock att för en server som är värd för MABS för att återställa säkerhetskopior som har gjorts med hjälp av MABS som körs på en annan server måste båda servrarna registreras med samma Azure Site Recovery-valv.

Kommentar

I allmänhet kan du distribuera en annan instans av MABS och konfigurera den för att säkerhetskopiera den primära MABS-distributionen. Detta liknar de konfigurationer för primär-till-sekundärt skydd, länkning och cykliskt skydd som är tillgängliga när du använder DPM. Den här metoden stöds dock inte för MABS och ger inte meningsfulla tillgänglighetsfördelar i scenariot som beskrivs i den här artikeln.

Funktionen för återställning till tidpunkt för MABS-skyddade arbetsbelastningar beror till stor del på typen av data, dess säkerhetskopior och dess skyddsprinciper. För att förstå dessa beroenden är det nödvändigt att utforska dessa begrepp mer detaljerat.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Att hantera användardata och program i hybridscenarier kräver ytterligare säkerhetsöverväganden. Dessa överväganden kan grupperas i följande kategorier:

  • Kryptering av säkerhetskopiering
  • Azure Recovery Services-valvskydd

MABS och Azure Backup framtvingar kryptering av säkerhetskopior i vila och under överföring:

  • Kryptering i vila. Under installationen av MABS tillhandahåller användaren en lösenfras. Den här lösenfrasen används sedan för att kryptera alla säkerhetskopior innan de laddas upp till ett Azure Recovery Services-valv. Dekryptering sker först efter att säkerhetskopior har laddats ned från valvet. Lösenfrasen är endast tillgänglig för användaren som skapade den och för den lokalt installerade MARS-agenten. Det är viktigt att se till att lösenfrasen lagras på en säker plats, eftersom den fungerar som auktoriseringsmekanism när molnbaserade återställningar utförs på en annan MABS-server än den där säkerhetskopiorna ägde rum.
  • Kryptering under överföring. MABS v3 förlitar sig på TLS-protokollet (Transport Layer Security) version 1.2 för att skydda sina anslutningar till Azure.

Azure Recovery Services-valvet erbjuder mekanismer som ytterligare skyddar onlinesäkerhetskopieringar, inklusive:

  • Rollbaserad Azure-åtkomstkontroll (Azure RBAC). Med Azure RBAC kan du delegera och separera ansvar enligt principen om lägsta behörighet. Det finns tre Inbyggda roller i Azure Backup som begränsar åtkomsten till säkerhetskopieringshanteringsåtgärder:
    • Säkerhetskopieringsdeltagare. Ger åtkomst till att skapa och hantera säkerhetskopior, förutom att ta bort Recovery Services-valv och delegera åtkomst till andra.
    • Operatör för säkerhetskopiering. Ger åtkomst som motsvarar säkerhetskopieringsdeltagarens, förutom att ta bort säkerhetskopior och hantera säkerhetskopieringsprinciper.
    • Säkerhetskopieringsläsare. Ger åtkomst till övervakning av säkerhetskopieringsåtgärder.
  • Azure-resurslås. Du kan skapa och tilldela skrivskyddade och borttagningslås till ett Azure Site Recovery-valv för att minska risken för att valvet oavsiktligt ändras eller tas bort.
  • Mjuk borttagning. Mjuk borttagning skyddar valv och säkerhetskopierade data från oavsiktliga eller skadliga borttagningar. Om en användare tar bort ett säkerhetskopieringsobjekt med mjuk borttagning behålls motsvarande data i 14 dagar, vilket möjliggör återställning utan dataförlust under den perioden. 14-dagars kvarhållning av säkerhetskopierade data i läget för mjuk borttagning medför ingen kostnad. Mjuk borttagning är aktiverat som standard.
  • Skydd av säkerhetskänsliga åtgärder. Azure Recovery Services-valvet implementerar automatiskt ett annat autentiseringslager när en säkerhetskänslig åtgärd, till exempel att ändra en lösenfras, görs. Den här extra verifieringen hjälper till att säkerställa att endast behöriga användare utför dessa åtgärder.
  • Övervakning och aviseringar för misstänkt aktivitet. Azure Backup tillhandahåller inbyggd övervakning och avisering av säkerhetskänsliga händelser som är relaterade till Azure Backup-åtgärder. Säkerhetskopieringsrapporter underlättar användningsspårning, granskning av säkerhetskopior och återställningar samt identifiering av viktiga trender för säkerhetskopiering.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

När du överväger kostnaden för säkerhetskopieringslösningen som beskrivs i den här artikeln bör du komma ihåg att ta hänsyn till både lokala och molnbaserade komponenter. Prissättningen för lokala komponenter bestäms av prismodellen för Azure Stack Hub. Precis som med Azure erbjuder Azure Stack Hub ett betala per användning-arrangemang som är tillgängligt via enterprise-avtal och Molnlösningsleverantör-programmet. Det här arrangemanget inkluderar ett månadspris per virtuell Windows Server-dator. Om du kan använda befintliga Windows Server-licenser kan du avsevärt minska den kostnaden till den virtuella datorns baspriser. MABS förlitar sig på SQL Server som datalager, men det finns ingen licenskostnad associerad med att köra SQL Server-instansen om den bara används för MABS.

Det finns Azure-relaterade avgifter för användning av följande resurser:

  • Azure Backup. Prissättningen för Azure Backup bestäms till stor del av antalet skyddade arbetsbelastningar och storleken på datasäkerhetskopior (före komprimering och kryptering) för var och en. Kostnaden påverkas också av valet mellan lokalt redundant lagring (LRS) och geo-redundant lagring (GRS) för replikering av Azure Recovery Services-valvinnehållet. Mer information finns i Prissättning för Azure Backup.
  • Azure ExpressRoute. Prissättningen för Azure ExpressRoute baseras på en av två modeller:
    • Obegränsad data. Det här är en månatlig avgift där alla inkommande och utgående dataöverföringar ingår.
    • Avgiftsbelagda data. Det här är en månatlig avgift där alla inkommande dataöverföringar är kostnadsfria och utgående dataöverföringar debiteras per gigabyte.
  • Azure Import/Export. Kostnaden för Azure Import/Export inkluderar en fast avgift per enhet för enhetshantering.
  • Azure Storage. När du använder Azure Import/Export gäller standardavgifter för Azure Storage och transaktionsavgifter.

Utan ExpressRoute kan du behöva ta hänsyn till ökad bandbreddsanvändning för dina Internetanslutningar för säkerhetskopieringar och återställningar. Kostnaden varierar beroende på många faktorer, inklusive geografiskt område, aktuell bandbreddsanvändning och Internetleverantören.

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

Hanterbarhet

En av de viktigaste faktorerna som påverkar din strategi för säkerhetskopiering och återställning är konfigurationen av skyddsgrupper och de kriterier som du använder för att bestämma vilka skyddade arbetsbelastningar som ska tillhöra samma skyddade grupper. Som beskrivs tidigare i den här artikeln är en skyddsgrupp en samling datakällor som volymer, resurser eller programdatalager som har vanliga inställningar för säkerhetskopiering och återställning. När du definierar en skyddsgrupp måste du ange:

  • Datakällor, till exempel servrar och arbetsbelastningar som du vill skydda.
  • Säkerhetskopieringslagring, inklusive inställningar för kortsiktigt och långsiktigt skydd.
  • Återställningspunkter, som är tidpunkter från vilka säkerhetskopierade data kan återställas.
  • Allokerat diskutrymme, vilket är mängden diskutrymme från lagringspoolen som allokeras för säkerhetskopior.
  • Inledande replikering, som är den metod som används för den första säkerhetskopieringen av datakällor. Metoden kan vara en onlineöverföring (via ett nätverk) eller en offlineöverföring (till exempel via Azure Import/Export-tjänsten).
  • Konsekvenskontrollmetoden, som är metoden för att verifiera integriteten för datasäkerhetskopior.

Följande metoder används ofta för att avgöra vilka skyddade arbetsbelastningar som ska tillhöra samma skyddade grupper:

  • Efter dator. Den här metoden kombinerar alla datakällor för en dator till samma skyddsgrupp.
  • Efter arbetsbelastning. Den här metoden separerar filer och varje programdatatyp i olika skyddsgrupper. Återställning av en server som är värd för flera arbetsbelastningar kan dock kräva flera återställningar från olika skyddsgrupper.
  • Efter RPO och RTO. Den här metoden grupperar datakällor med liknande RRPOs. Du styr grupprincipobjektet genom att ange synkroniseringsfrekvensen för skyddsgruppen, som avgör mängden potentiell dataförlust (mätt i tid) under oväntade avbrott. I scenariot som beskrivs i den här artikeln kontrollerar du RTO genom att ange kvarhållningsperioden inom den kortsiktiga lagringen. Detta avgör den period under vilken säkerhetskopieringar kan återställas från den lokala kortsiktiga lagringen, i stället för från den molnbaserade långsiktiga lagringen. Säkerhetskopiering från den lokala kortsiktiga lagringen resulterar i en snabbare återställning.
  • Efter dataegenskaper. Den här metoden står för frekvensen för dataändringar, datatillväxthastighet eller dess lagringskrav som kriterier för gruppering.

När du namnger skyddsgrupper använder du unika, meningsfulla namn. Ett namn kan vara valfri kombination av alfanumeriska tecken och blanksteg på upp till 64 tecken.

När du skapar en skyddsgrupp väljer du en metod för att skapa den första repliken. Den inledande replikeringen kopierar alla data som har valts för skydd till servern som är värd för MABS och kopierar dem sedan till Azure Site Recovery-valvet. Båda kopiorna kontrolleras för konsekvens. MABS kan skapa repliker automatiskt via nätverket, men du kan skapa repliker manuellt genom att säkerhetskopiera, överföra och återställa data offline.

Information om hur du väljer metoden för att skapa repliker finns i Inledande replikering över nätverket. Artikeln innehåller en tabell som innehåller uppskattningar av hur lång tid DET tar för MABS att skapa en replik automatiskt via nätverket för olika skyddade datastorlekar och nätverkshastigheter.

Offline-seeding-processen stöder användning av Azure Import/Export-tjänsten, som kan överföra data till ett Azure Storage-konto med hjälp av SATA-diskar. Den här funktionen kan användas när onlinesäkerhetskopian är för långsam på grund av mängden säkerhetskopierade data eller hastigheten på nätverksanslutningen till Azure.

Arbetsflödet för offline-seeding har följande steg:

  1. Du kopierar de första säkerhetskopieringsdata till en eller flera SATA-diskar med hjälp av verktyget AzureOfflineBackupDiskPrep.
  2. Verktyget genererar automatiskt ett Azure Import-jobb och en Microsoft Entra-app i den prenumeration som är värd för målets Azure Storage-konto och Azure Recovery Services-valv. Appen ger Azure Backup säker och begränsad åtkomst till Azure Import Service, enligt vad som krävs av offline-seedingprocessen.
  3. Du skickar diskarna till Azure-datacentret som är värd för Azure Storage-målkontot.
  4. Azures datacenterpersonal kopierar data från diskarna till Azure Storage-kontot.
  5. Arbetsflödet utlöser en kopia från Azure Storage-kontot till Azure Recovery Services-valvet.

DevOps

Även om säkerhetskopiering och återställning anses vara en del av IT-åtgärder finns det vissa DevOps-specifika överväganden som är värda att införliva i en omfattande säkerhetskopieringsstrategi. Azure Stack Hub underlättar automatisk distribution av olika arbetsbelastningar, inklusive VM-baserade program och tjänster. Du kan använda den här funktionen för att effektivisera MABS-distributionen till virtuella Azure Stack Hub-datorer, vilket förenklar den inledande installationen i scenarier med flera klientorganisationer. Genom att kombinera Azure Resource Manager-mallar, VM-tillägg och DPM PowerShell-modulen går det att automatisera konfigurationen av MABS, inklusive konfigurationen av dess skyddsgrupper, kvarhållningsinställningar och scheman för säkerhetskopiering. I den anda av bästa praxis för DevOps bör du lagra mallar och skript i en källkontrollanläggning och konfigurera distributionen med hjälp av pipelines. Dessa metoder hjälper till att minimera återställningstiden i fall där infrastrukturen som behövs för att återställa fil- och programdata måste återskapas.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

När du planerar att distribuera MABS på Azure Stack Hub måste du överväga mängden bearbetnings-, lagrings- och nätverksresurser som allokeras till de virtuella datorer som är värdar för distributionen. Microsoft rekommenderar att du allokerar en 2,33 gigahertz -processor (GHz) med fyra kärnor för att uppfylla MABS-bearbetningsbehoven och cirka 10 GB diskutrymme för att hantera installationsbinärfilerna. Andra lagringskrav kan kategoriseras på följande sätt:

  • Diskutrymme för säkerhetskopior. Den allmänna rekommendationen för säkerhetskopieringsdiskutrymme är att allokera en lagringspool med diskutrymme som motsvarar ungefär 1,5 gånger storleken på alla data som ska säkerhetskopieras. När diskarna är anslutna till den virtuella datorn hanterar MABS volym- och diskutrymmeshantering. Antalet diskar som du kan ansluta till en virtuell dator beror på dess storlek.

    Kommentar

    Du bör inte lagra säkerhetskopior lokalt i mer än fem dagar. Säkerhetskopior som är äldre än fem dagar bör avlastas till Azure Site Recovery-valvet.

  • Diskutrymme för MARS-agentens cacheplats. Överväg att använda enhet C på den virtuella dator som är värd för MABS-installationen.

  • Diskutrymme för lokalt mellanlagringsområde under återställningar. Överväg att använda den tillfälliga enheten D på den virtuella datorn som är värd för MABS-installationen.

Om du vill etablera lagring för den virtuella dator som är värd för MABS-installationen använder du hanterade diskar på Premium-prestandanivån. De förväntade prestandaegenskaperna är 2 300 I/O-åtgärder per sekund (IOPS) och 145 MB/s per disk. Till skillnad från Azure finns det inga prestandagarantier för Azure Stack Hub.

Om du vill få en mer exakt uppskattning av lagringen som krävs för säkerhetskopiering av Azure Stack Hub-baserade arbetsbelastningar bör du överväga att använda Vm-storlekskalkylatorn för Azure Stack för MABS, som är tillgänglig från Microsoft Downloads. Kalkylatorn implementeras som en Microsoft Excel-arbetsbok med makron som härleder optimal storleksinformation för Azure Stack Hub som baseras på ett antal parametrar som du anger. Dessa parametrar omfattar:

  • Källinformation som innehåller en lista över de virtuella datorer som ska skyddas, inklusive för varje:
    • Storleken på skyddade data
    • Arbetsbelastningstypen (Windows Server, SharePoint eller SQL Server)
  • Datakvarhållningsintervall i dagar

Varje arbetsbelastningstyp är som standard associerad med en fördefinierad daglig ändringsfrekvens (eller omsättning). Du kan justera dessa värden om de inte återspeglar användningsmönstren i din miljö.

Vm-storlekskalkylatorn för Azure Stack för MABS använder den information som du anger för att ange:

  • En uppskattad storlek på den virtuella Azure Stack Hub-dator som är värd för installationen av MABS.
  • En uppskattad mängd MABS-diskutrymme som behövs för att vara värd för säkerhetskopierade data.
  • Totalt antal diskar på 1 terabyte (TB) vardera.
  • IOPS-priset som är tillgängligt för MABS-användning.
  • En uppskattad tid för att slutföra den första säkerhetskopieringen. Uppskattningen baseras på den totala storleken på skyddade data och på den IOPS som är tillgänglig för MABS-användning.
  • En uppskattad tid för att slutföra dagliga säkerhetskopieringar. Uppskattningen baseras på den totala storleken på den dagliga omsättningen och på den IOPS som är tillgänglig för MABS-användning.

Kommentar

Azure Stack VM Size Calculator for MABS släpptes i april 2018, vilket innebär att den inte tar hänsyn till optimeringar som ingår i MABS v3 (inklusive de som ingår i UR1). Den innehåller dock förbättringar som är specifika för MBS, som introducerades i MABS v2 som släpptes i juni 2017.

Om du skapar en skyddsgrupp med hjälp av det grafiska MABS-gränssnittet beräknar MABS den lokala diskutrymmesallokering som baseras på de kortsiktiga återställningsmål som du anger när du lägger till en datakälla i en skyddsgrupp. Sedan kan du bestämma hur mycket utrymme som ska allokeras i lagringspoolen för repliker och återställningspunkter för varje datakälla i gruppen. Du måste se till att det finns tillräckligt med utrymme på de lokala diskarna på de skyddade servrarna för ändringsjournalen. MABS tillhandahåller standardutrymmesallokeringar för medlemmarna i skyddsgruppen. Mer information om standardutrymmesallokeringar för olika MABS-komponenter finns i Dokumentation om distribuera skyddsgrupper.

Överväg att använda standardutrymmesallokeringar om du inte vet att de inte uppfyller dina behov. Om du överskrider standardallokeringarna kan det leda till allokering av för lite eller för mycket utrymme. Allokering av för lite utrymme för återställningspunkterna kan hindra MABS från att lagra tillräckligt med återställningspunkter för att uppfylla dina mål för kvarhållningsintervall. Allokering av för mycket utrymme slösar diskkapacitet. När du har skapat en skyddsgrupp kan du öka allokeringen för replik- och återställningspunktvolymerna för varje datakälla om du har allokerat för lite utrymme för en datakälla. Om du har allokerat för mycket utrymme för skyddsgruppen kan du ta bort datakällan från skyddsgruppen och ta bort repliken. Lägg sedan till datakällan i skyddsgruppen med mindre allokeringar.

Om du efter distributionen behöver justera den uppskattade storleken på de virtuella Azure Stack Hub-datorer som är värdar för MABS för att hantera ändringar i bearbetnings- eller lagringskrav har du tre alternativ:

  • Implementera vertikal skalning. Detta kräver att du ändrar mängden och typen av processor-, minnes- och diskresurser för de virtuella Azure Stack Hub-datorer som är värdar för MABS.
  • Implementera horisontell skalning. Detta kräver etablering eller avetablering av de virtuella Azure Stack Hub-datorer som har MABS installerat för att matcha bearbetningskraven för de skyddade arbetsbelastningarna.
  • Ändra skyddsprinciper. Detta kräver att du ändrar parametrarna för skyddsprinciperna, inklusive kvarhållningsintervall, återställningspunktsschema och uttryckligt fullständigt säkerhetskopieringsschema.

Kommentar

MABS omfattas av gränser för antalet återställningspunkter, fullständiga snabbsäkerhetskopior och inkrementella säkerhetskopior. Mer information om dessa gränser finns i Återställningsprocess.

Om du väljer att automatiskt öka volymerna står MABS för den ökade säkerhetskopieringsvolymen när produktionsdata växer. Annars begränsar MABS lagringen av säkerhetskopior till storleken på datakällorna i skyddsgruppen.

Det finns två huvudsakliga alternativ för att justera tillgänglig bandbredd:

  • Öka storleken på den virtuella datorn. För virtuella Azure Stack Hub-datorer avgör storleken maximal nätverksbandbredd. Det finns dock inga bandbreddsgarantier. I stället kan virtuella datorer använda mängden tillgänglig bandbredd upp till den gräns som bestäms av deras storlek.
  • Öka dataflödet för överordnad länkväxlar. Azure Stack Hub-system har stöd för en rad maskinvaruväxlar som erbjuder flera alternativ för överordnad länkhastighet. Varje Azure Stack Hub-klusternod har två överordnad länk till rackväxlarna för feltolerans. Systemet allokerar hälften av överordnad kapacitet för kritisk infrastruktur och resten är delad kapacitet för Azure Stack-tjänster och all användartrafik. System som distribueras med snabbare hastigheter har mer bandbredd tillgänglig för säkerhetskopieringstrafik.

Även om det är möjligt att separera nätverkstrafik genom att ansluta ett andra nätverkskort till en server, delar all azure Stack Hub VM-trafik till Internet samma överordnad länk. Ett andra virtuellt nätverkskort separerar inte trafik på fysisk transportnivå.

För att hantera större säkerhetskopieringsstorlekar kan du överväga att använda Azure ExpressRoute med Microsoft-peering för att ansluta mellan virtuella Azure Stack Hub-nätverk och Azure Recovery Services-valv. Azure ExpressRoute utökar lokala nätverk till Microsoft-molnet via en privat anslutning som tillhandahålls av en anslutningsleverantör. Du kan köpa ExpressRoute-kretsar för en mängd olika bandbredder, från 50 Mbit/s till 10 Gbit/s.

Kommentar

Mer information om hur du implementerar Azure ExpressRoute i Azure Stack Hub-scenarier finns i Anslut Azure Stack Hub till Azure med Hjälp av Azure ExpressRoute.

Kommentar

MABS v3 använder förbättringar som är inbyggda i MBS och optimerar nätverks- och lagringsanvändningen genom att endast överföra ändrade data under konsekvenskontroller.

Sammanfattning

Azure Stack Hub är ett unikt erbjudande som skiljer sig i många aspekter från andra virtualiseringsplattformar. Därför bör särskild hänsyn tas till strategier för affärskontinuitet för arbetsbelastningar som körs på de virtuella datorerna. Att använda Azure-tjänster förenklar design- och implementeringsstrategin. I den här artikeln utforskade vi att använda MABS för att säkerhetskopiera fil- och programdata på virtuella Azure Stack Hub-datorer i den anslutna distributionsmodellen. Med den här metoden kan kunderna dra nytta av återhämtning och hanterbarhet i Azure Stack Hub, och från hyperskalan och den globala närvaron av Azure-molnet.

Säkerhetskopieringslösningen som beskrivs här fokuserar uteslutande på fil- och programdata på virtuella Azure Stack Hub-datorer. Detta är bara en del av en övergripande strategi för affärskontinuitet som bör ta hänsyn till olika andra scenarier som påverkar arbetsbelastningens tillgänglighet. Några exempel är: lokaliserade maskinvaru- och programvarufel, systemfel, katastrofala händelser och storskaliga katastrofer.

Nästa steg

Relaterad hybridvägledning:

Relaterade arkitekturer: