Een overzicht van back-ups van Azure-VM's

In dit artikel wordt beschreven hoe de Azure Backup-service back-ups maakt van virtuele Azure-machines (VM's).

Azure Backup biedt onafhankelijke en geïsoleerde back-ups om bescherming te bieden tegen onbedoelde vernietiging van de gegevens op uw VM's. Back-ups worden in een Recovery Services-kluis opgeslagen waarin het beheer van herstelpunten is ingebouwd. Het is eenvoudig om te configureren en de schaal aan te passen, back-ups worden geoptimaliseerd en u kunt, indien nodig, eenvoudig herstelbewerkingen uitvoeren.

Als onderdeel van het back-upproces wordt een momentopname gemaakt en worden de gegevens overgedragen naar de Recovery Services-kluis zonder dat dit van invloed is op productieworkloads. De momentopname biedt verschillende consistentieniveaus, zoals hier wordt beschreven.

Azure Backup heeft ook gespecialiseerde aanbiedingen voor databaseworkloads, zoals SQL Server en SAP HANA, die workloadbewust zijn, een RPO van 15 minuten (beoogde herstelpunten) bieden en back-up en herstel van afzonderlijke databases toestaan.

Back-upproces

Hier volgt een beschrijving van de manier waarop in Azure Backup een back-up voor virtuele Azure-machines wordt uitgevoerd:

  1. Voor Azure-VM's die zijn geselecteerd voor back-up, start Azure Backup een back-uptaak volgens het back-upschema dat u opgeeft.
  2. Tijdens de eerste back-up wordt er een back-upextensie op de VM geïnstalleerd als de VM wordt uitgevoerd.
  3. Voor Windows-VM's die worden uitgevoerd, coördineert Back-up met Windows Volume Shadow Copy Service (VSS) om een app-consistente momentopname van de VM te maken.
    • Back-up maakt standaard volledige VSS-back-ups.
    • Als Back-up geen app-consistente momentopname kan maken, wordt er een bestandsconsistente momentopname van de onderliggende opslag gemaakt (omdat er geen schrijfbewerkingen van de toepassing plaatsvinden terwijl de VM wordt gestopt).
  4. Voor Linux-VM's maakt Back-up een bestandsconsistente back-up. Voor app-consistente momentopnamen moet u scripts vóór/na handmatig aanpassen.
  5. Nadat Back-up de momentopname heeft gemaakt, worden de gegevens naar de kluis overgedragen.
    • De back-up wordt geoptimaliseerd door parallel een back-up te maken van elke VM-schijf.
    • Azure Backup leest de blokken op elke schijf waarvan een back-up wordt gemaakt, en identificeert en verplaatst alleen de gegevensblokken die sinds de vorige back-up zijn gewijzigd (de delta).
    • Momentopnamegegevens worden mogelijk niet direct naar de kluis gekopieerd. Het kan tijdens piekuren enkele uren duren. De totale back-uptijd voor een virtuele machine is minder dan 24 uur bij beleid voor dagelijkse back-ups.
  6. Wijzigingen die worden aangebracht in een Windows-VM nadat Azure Backup is ingeschakeld, zijn:
    • Microsoft Visual C++ 2013 Redistributable(x64) - 12.0.40660 is geïnstalleerd op de VM
    • Opstarttype volume shadow copy-service (VSS) is gewijzigd in automatisch van handmatig
    • IaaSVmProvider Windows-service is toegevoegd

Back-uparchitectuur van virtuele Azure-machines

Versleuteling van Azure VM-back-ups

Wanneer u een back-up maakt van azure-VM's met Azure Backup, worden VM's in rust versleuteld met Storage Service Encryption (SSE). Azure Backup kunt ook back-ups maken van Azure-VM's die zijn versleuteld met behulp van Azure Disk Encryption.

Versleuteling Details Ondersteuning
Sse Met SSE biedt Azure Storage versleuteling-at-rest door gegevens automatisch te versleutelen voordat ze worden opgeslagen. Azure Storage ontsleutelt ook gegevens voordat deze worden opgehaald. Azure Backup ondersteunt back-ups van VM's met twee typen Storage Service Encryption:
  • SSE met door het platform beheerde sleutels: deze versleuteling is standaard voor alle schijven in uw VM's. Meer informatie vindt u hier.
  • SSE met door de klant beheerde sleutels. Met CMK beheert u de sleutels die worden gebruikt om de schijven te versleutelen. Meer informatie vindt u hier.
  • Azure Backup maakt gebruik van SSE voor at-rest-versleuteling van Azure-VM's.
    Azure Disk Encryption Azure Disk Encryption versleutelt zowel besturingssysteem- als gegevensschijven voor Azure-VM's.

    Azure Disk Encryption kan worden geïntegreerd met BitLocker-versleutelingssleutels (BEK's), die als geheimen worden beveiligd in een sleutelkluis. Azure Disk Encryption kan ook worden geïntegreerd met Azure Key Vault sleutelversleutelingssleutels (KKS).
    Azure Backup ondersteunt back-ups van beheerde en onbeheerde Azure-VM's die zijn versleuteld met alleen BEK's of met BEK's samen met KKS.

    Van zowel BEK's als KKS wordt een back-up gemaakt en versleuteld.

    Omdat er een back-up van KKS en BEK's wordt gemaakt, kunnen gebruikers met de benodigde machtigingen sleutels en geheimen zo nodig terugzetten naar de sleutelkluis. Deze gebruikers kunnen ook de versleutelde VM herstellen.

    Versleutelde sleutels en geheimen kunnen niet worden gelezen door onbevoegde gebruikers of door Azure.

    Voor beheerde en onbeheerde Azure-VM's ondersteunt Backup zowel VM's die zijn versleuteld met alleen BEK's als VM's die zijn versleuteld met BEK's samen met KKS.

    De back-up van BEK's (geheimen) en KKS (sleutels) worden versleuteld. Ze kunnen alleen worden gelezen en gebruikt wanneer ze door geautoriseerde gebruikers worden hersteld naar de sleutelkluis. Onbevoegde gebruikers of Azure kunnen geen back-up van sleutels of geheimen lezen of gebruiken.

    Er wordt ook een back-up gemaakt van BEK's. Dus als de BEK's verloren gaan, kunnen geautoriseerde gebruikers de BEK's herstellen naar de sleutelkluis en de versleutelde VM's herstellen. Alleen gebruikers met het benodigde machtigingsniveau kunnen back-ups maken en versleutelde VM's of sleutels en geheimen herstellen.

    Maken van momentopnamen

    Azure Backup maakt momentopnamen volgens het back-upschema.

    • Windows-VM's: Voor Windows-VM's coördineert de Backup-service met VSS om een app-consistente momentopname van de VM-schijven te maken. Standaard maakt Azure Backup een volledige VSS-back-up (het kapt de logboeken van de toepassing af, zoals SQL Server op het moment van de back-up om een consistente back-up op toepassingsniveau te krijgen). Als u een SQL Server-database op Azure VM-back-up gebruikt, kunt u de instelling wijzigen om een VSS-kopieback-up te maken (om logboeken te behouden). Raadpleeg dit artikel voor meer informatie.

    • Virtuele Linux-machines: Als u app-consistente momentopnamen van Linux-VM's wilt maken, gebruikt u het Pre-Script en Post-Script Framework van Linux om uw eigen aangepaste scripts te schrijven om consistentie te garanderen.

      • Azure Backup roept alleen de pre-/postscripts aan die door u zijn geschreven.
      • Als de prescripts en postscripts correct worden uitgevoerd, markeert Azure Backup het herstelpunt als toepassingsconsistent. Wanneer u echter aangepaste scripts gebruikt, bent u uiteindelijk verantwoordelijk voor de consistentie van de toepassing.
      • Meer informatie over het configureren van scripts.

    Consistentie van momentopnamen

    In de volgende tabel worden de verschillende typen consistentie van momentopnamen uitgelegd:

    Momentopname Details Herstel Overweging
    Toepassingsconsistent App-consistente back-ups leggen geheugeninhoud en in behandeling zijnde I/O-bewerkingen vast. App-consistente momentopnamen maken gebruik van een VSS-schrijver (of pre/post-scripts voor Linux) om ervoor te zorgen dat de app-gegevens consistent zijn voordat er een back-up wordt gemaakt. Wanneer u een VM herstelt met een app-consistente momentopname, wordt de VM opgestart. Er is geen beschadiging of verlies van gegevens. De apps worden gestart in een consistente status. Windows: Alle VSS-schrijvers zijn geslaagd

    Linux: Pre/post scripts zijn geconfigureerd en geslaagd
    Bestandssysteemconsistent Bestandssysteemconsistente back-ups bieden consistentie door tegelijkertijd een momentopname van alle bestanden te maken.

    Wanneer u een virtuele machine herstelt met een bestandssysteemconsistente momentopname, wordt de VM opgestart. Er is geen beschadiging of verlies van gegevens. Apps moeten hun eigen 'fix-up'-mechanisme implementeren om ervoor te zorgen dat herstelde gegevens consistent zijn. Windows: sommige VSS-schrijvers zijn mislukt

    Linux: standaard (als pre-/postscripts niet zijn geconfigureerd of mislukt)
    Crashconsistent Crashconsistente momentopnamen treden doorgaans op als een Azure-VM wordt afgesloten op het moment van de back-up. Alleen de gegevens die al op de schijf bestaan op het moment van de back-up, worden vastgelegd en er wordt een back-up van gemaakt. Begint met het opstartproces van de VM, gevolgd door een schijfcontrole om beschadigde fouten op te lossen. Alle in-memory gegevens of schrijfbewerkingen die vóór het vastlopen niet naar de schijf zijn overgebracht, gaan verloren. Apps implementeren hun eigen gegevensverificatie. Een database-app kan bijvoorbeeld het transactielogboek gebruiken voor verificatie. Als het transactielogboek vermeldingen bevat die zich niet in de database bevinden, worden transacties teruggedraaid totdat de gegevens consistent zijn. DE VM bevindt zich in de status Afsluiten (gestopt/toewijzing ongedaan gemaakt).

    Notitie

    Als de inrichtingsstatus is geslaagd, maakt Azure Backup bestandssysteemconsistente back-ups. Als de inrichtingsstatus niet beschikbaar is of mislukt, worden crashconsistente back-ups gemaakt. Als de inrichtingsstatus wordt gemaakt of verwijderd, betekent dit dat Azure Backup de bewerkingen opnieuw probeert uit te voeren.

    Overwegingen voor back-up en herstel

    Overweging Details
    Schijf Back-up van VM-schijven is parallel. Als een VM bijvoorbeeld vier schijven heeft, probeert de Backup-service parallel een back-up te maken van alle vier de schijven. Back-up is incrementeel (alleen gewijzigde gegevens).
    Planning Als u het back-upverkeer wilt verminderen, maakt u op verschillende tijdstippen van de dag een back-up van verschillende VM's en zorgt u ervoor dat de tijden elkaar niet overlappen. Als op hetzelfde moment back-ups worden gemaakt van VM's, treden er netwerkproblemen op.
    Back-ups voorbereiden Houd rekening met de tijd die nodig is om de back-up voor te bereiden. De voorbereidingstijd omvat het installeren of bijwerken van de back-upextensie en het activeren van een schaduwkopie volgens het back-upschema.
    Gegevensoverdracht Houd rekening met de tijd die Azure Backup nodig heeft om de incrementele wijzigingen van de vorige back-up te identificeren.

    In een incrementele back-up worden de wijzigingen door Azure Backup bepaald door de controlesom van het blok te berekenen. Als een blok wordt gewijzigd, wordt het gemarkeerd voor overdracht naar de kluis. De service analyseert de geïdentificeerde blokken om de hoeveelheid gegevens die moet worden overgedragen, verder te minimaliseren. Nadat alle gewijzigde blokken zijn geëvalueerd, worden de wijzigingen in de kluis door Azure Backup overgedragen.

    Er kan een vertraging optreden tussen het maken van de schaduwkopie en het kopiëren ervan naar de kluis. Tijdens piekmomenten kan het acht uur duren voordat de momentopnamen zijn overgebracht naar de kluis. De back-uptijd voor een virtuele machine is minder dan 24 uur voor de dagelijkse back-up.
    Eerste back-up Hoewel de totale back-uptijd voor incrementele back-ups minder dan 24 uur is, is dit mogelijk niet het geval voor de eerste back-up. De tijd die nodig is om de initiële back-up te maken, is afhankelijk van de grootte van de gegevens en wanneer de back-up wordt verwerkt.
    Wachtrij herstellen Azure Backup hersteltaken van meerdere opslagaccounts tegelijk verwerkt en herstelaanvragen in een wachtrij plaatsen.
    Kopie herstellen Tijdens het herstelproces worden gegevens gekopieerd van de kluis naar het opslagaccount.

    De totale hersteltijd is afhankelijk van de I/O-bewerkingen per seconde (IOPS) en de doorvoer van het opslagaccount.

    Als u de kopieertijd wilt verkorten, selecteert u een opslagaccount dat niet is geladen met andere schrijf- en leesbewerkingen van toepassingen.

    Back-upprestaties

    Deze veelvoorkomende scenario's kunnen van invloed zijn op de totale back-uptijd:

    • Een nieuwe schijf toevoegen aan een beveiligde Azure-VM: Als een virtuele machine een incrementele back-up ondergaat en er een nieuwe schijf wordt toegevoegd, neemt de back-uptijd toe. De totale back-uptijd kan langer dan 24 uur duren vanwege de initiële replicatie van de nieuwe schijf en de deltareplicatie van bestaande schijven.
    • Gefragmenteerde schijven: Back-upbewerkingen zijn sneller wanneer schijfwijzigingen aaneengesloten zijn. Als wijzigingen worden verspreid en gefragmenteerd over een schijf, wordt de back-up langzamer.
    • Schijfverloop: Als beveiligde schijven die een incrementele back-up ondergaan een dagelijks verloop van meer dan 200 GB hebben, kan het lang duren (meer dan acht uur) voordat de back-up is voltooid.
    • Back-upversies: De nieuwste versie van Back-up (ook wel de versie van Direct herstellen genoemd) maakt gebruik van een meer geoptimaliseerd proces dan controlesomvergelijking voor het identificeren van wijzigingen. Maar als u Direct herstellen gebruikt en een back-upmomentopname hebt verwijderd, schakelt de back-up over naar controlesomvergelijking. In dit geval duurt de back-upbewerking langer dan 24 uur (of mislukt).

    Herstelprestaties

    Deze veelvoorkomende scenario's kunnen van invloed zijn op de totale hersteltijd:

    • De totale hersteltijd is afhankelijk van de invoer-/uitvoerbewerkingen per seconde (IOPS) en de doorvoer van het opslagaccount.
    • De totale hersteltijd kan worden beïnvloed als het doelopslagaccount wordt geladen met andere lees- en schrijfbewerkingen van de toepassing. Als u de herstelbewerking wilt verbeteren, selecteert u een opslagaccount dat niet is geladen met andere toepassingsgegevens.

    Aanbevolen procedures

    Wanneer u back-ups van VM's configureert, wordt u aangeraden deze procedures te volgen:

    • Wijzig de standaardplanningstijden die in een beleid zijn ingesteld. Als de standaardtijd in het beleid bijvoorbeeld 12:00 uur is, verhoogt u de timing met enkele minuten zodat de resources optimaal worden benut.
    • Als u VM's vanuit één kluis herstelt, raden we u ten zeerste aan verschillende v2-opslagaccounts voor algemeen gebruik te gebruiken om ervoor te zorgen dat het doelopslagaccount niet wordt beperkt. Elke VIRTUELE machine moet bijvoorbeeld een ander opslagaccount hebben. Als er bijvoorbeeld 10 VM's zijn hersteld, gebruikt u 10 verschillende opslagaccounts.
    • Voor back-ups van VM's die gebruikmaken van Premium-opslag met Direct herstellen, raden we u aan 50% vrije ruimte toe te wijzen van de totale toegewezen opslagruimte, die alleen nodig is voor de eerste back-up. De 50% vrije ruimte is geen vereiste voor back-ups nadat de eerste back-up is voltooid
    • De limiet voor het aantal schijven per opslagaccount is relatief ten opzichte van de mate van toegang tot de schijven door toepassingen die worden uitgevoerd op een IaaS-VM (infrastructure as a service). Als er op één opslagaccount vijf tot tien schijven of meer aanwezig zijn, geldt als vuistregel dat de belasting kan worden verdeeld door sommige schijven naar afzonderlijke opslagaccounts te verplaatsen.
    • Als u VM's met beheerde schijven wilt herstellen met behulp van PowerShell, geeft u de aanvullende parameter TargetResourceGroupName op om de resourcegroep op te geven waarnaar beheerde schijven worden hersteld. Meer informatie vindt u hier.

    Back-upkosten

    Azure-VM's waarvan een back-up wordt gemaakt met Azure Backup, zijn onderhevig aan Azure Backup prijzen.

    De facturering begint pas als de eerste geslaagde back-up is voltooid. Op dit moment begint de facturering voor zowel opslag- als beveiligde VM's. Facturering wordt voortgezet zolang back-upgegevens voor de VM zijn opgeslagen in een kluis. Als u de beveiliging voor een VIRTUELE machine stopt, maar back-upgegevens voor de VM aanwezig zijn in een kluis, wordt de facturering voortgezet.

    Facturering voor een opgegeven VM stopt alleen als de beveiliging is gestopt en alle back-upgegevens worden verwijderd. Wanneer de beveiliging stopt en er geen actieve back-uptaken zijn, wordt de grootte van de laatste geslaagde VM-back-up de grootte van de beveiligde instantie die wordt gebruikt voor de maandelijkse factuur.

    De berekening van de grootte van het beveiligde exemplaar is gebaseerd op de werkelijke grootte van de VM. De grootte van de VM is de som van alle gegevens in de VM, met uitzondering van de tijdelijke opslag. Prijzen zijn gebaseerd op de werkelijke gegevens die zijn opgeslagen op de gegevensschijven, niet op de maximaal ondersteunde grootte voor elke gegevensschijf die is gekoppeld aan de virtuele machine.

    Op dezelfde manier is de factuur voor back-upopslag gebaseerd op de hoeveelheid gegevens die is opgeslagen in Azure Backup. Dit is de som van de werkelijke gegevens in elk herstelpunt.

    Neem bijvoorbeeld een A2-standaard VM met twee extra gegevensschijven met een maximale grootte van 32 TB. In de volgende tabel ziet u de werkelijke gegevens die op elk van deze schijven zijn opgeslagen:

    Schijf Maximale grootte Werkelijke gegevens aanwezig
    Besturingssysteemschijf 32 TB 17 GB
    Lokale/tijdelijke schijf 135 GB 5 GB (niet inbegrepen voor back-up)
    Gegevensschijf 1 32 TB 30 GB
    Gegevensschijf 2 32 TB 0 GB

    De werkelijke grootte van de VIRTUELE machine is in dit geval 17 GB + 30 GB + 0 GB = 47 GB. Deze grootte van het beveiligde exemplaar (47 GB) wordt de basis voor de maandelijkse factuur. Naarmate de hoeveelheid gegevens in de VM toeneemt, verandert de grootte van het beveiligde exemplaar die wordt gebruikt voor facturering.

    Volgende stappen