Een overzicht van back-ups van Azure-VM's
In dit artikel wordt beschreven hoe de Azure Backup-service een back-up 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 er een momentopname gemaakt en worden de gegevens zonder gevolgen voor productieworkloads overgebracht naar de Recovery Services-kluis. De momentopname biedt verschillende consistentieniveaus, zoals hier wordt beschreven. U kunt kiezen voor een toepassingsconsistente/bestandsconsistente back-up op basis van een agent of een crash-consistente back-up zonder agent in het back-upbeleid.
Azure Backup biedt ook gespecialiseerde aanbiedingen voor databaseworkloads zoals SQL Server en SAP HANA die workloadbewust zijn, een RPO van 15 minuten (herstelpuntdoelstelling) 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:
Voor Azure-VM's die zijn geselecteerd voor back-up, start Azure Backup een back-uptaak volgens het back-upschema dat u opgeeft.
Als u voor toepassings- of bestandssysteemconsistente back-ups hebt gekozen, moet op de VM een back-upextensie zijn geïnstalleerd om het momentopnameproces te coördineren.
Als u hebt gekozen voor crashconsistente back-ups, zijn er geen agents vereist in de VM's.
Tijdens de eerste back-up wordt een back-upextensie op de VM geïnstalleerd als de VIRTUELE machine wordt uitgevoerd.
- Voor Windows-VM's is de VMSnapshot-extensie geïnstalleerd.
- Voor Linux-VM's wordt de EXTENSIE VMSnapshotLinux geïnstalleerd.
Voor Windows-VM's die worden uitgevoerd, coördineert Azure Backup met Windows Volume Shadow Copy Service (VSS) om een app-consistente momentopname van de VIRTUELE machine 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 VIRTUELE machine is gestopt).
Voor Virtuele Linux-machines maakt Back-up een bestandsconsistente back-up. Voor app-consistente momentopnamen moet u vooraf/postscripts handmatig aanpassen.
Voor Virtuele Windows-machines wordt Microsoft Visual C++ 2013 Redistributable (x64) versie 12.0.40660 geïnstalleerd, wordt het opstarten van Volume Shadow Copy Service (VSS) gewijzigd in automatisch en wordt er een IaaSVmProvider voor Windows Service toegevoegd.
Nadat Backup de momentopname heeft gemaakt, worden de gegevens overgedragen naar de kluis.
- 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 enkele uren duren tijdens piektijden. De totale back-uptijd voor een virtuele machine is minder dan 24 uur bij beleid voor dagelijkse back-ups.
Versleuteling van Back-ups van Azure-VM's
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 kan ook een back-up maken van Azure-VM's die zijn versleuteld met behulp van Azure Disk Encryption.
| Versleuteling | DETAILS | Ondersteuning |
|---|---|---|
| SSE | Met SSE biedt Azure Storage versleuteling in rust door gegevens automatisch te versleutelen voordat deze worden opgeslagen. Azure Storage ontsleutelt ook gegevens voordat ze worden opgehaald. Azure Backup ondersteunt back-ups van VM's met twee typen Storage Service Encryption: |
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 Virtuele Azure-machines. Azure Disk Encryption kan worden geïntegreerd met BitLocker-versleutelingssleutels (BEK's), die als geheimen in een sleutelkluis worden beveiligd. Azure Disk Encryption kan ook worden geïntegreerd met Azure Key Vault-sleutelversleutelingssleutels (KEK's). |
Azure Backup biedt ondersteuning voor back-ups van beheerde en onbeheerde Azure-VM's die alleen zijn versleuteld met BEK's of met BEK's in combinatie met KKS. Er wordt een back-up gemaakt van zowel BEK's als KEK's. Omdat er een back-up van KEK's en BEK's wordt gemaakt, kunnen gebruikers met de benodigde machtigingen zo nodig sleutels en geheimen 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 beide VM's die alleen zijn versleuteld met BEK's of VM's die zijn versleuteld met BEK's, samen met KKS.
De back-up-BEK's (geheimen) en KKS (sleutels) worden versleuteld. Ze kunnen alleen worden gelezen en gebruikt wanneer ze weer worden hersteld naar de sleutelkluis door geautoriseerde gebruikers. Niet-geautoriseerde gebruikers of Azure kunnen geen back-upsleutels 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 een back-up maken van versleutelde VM's of sleutels en geheimen en deze herstellen.
Maken van momentopnamen
Azure Backup maakt momentopnamen volgens het back-upschema.
Als u voor toepassings- of bestandssysteemconsistente back-ups hebt gekozen, moet op de VM een back-upextensie zijn geïnstalleerd om het momentopnameproces te coördineren. Voor crashconsistente back-ups zonder agents is de VM-agent niet vereist voor momentopnamen.
Windows-VM's: Voor Windows-VM's coördineert de Backup-service met VSS een app-consistente momentopname van de VM-schijven. Azure Backup maakt standaard een volledige VSS-back-up (hiermee worden de logboeken van de toepassing afgekapt, zoals SQL Server op het moment van de back-up, om consistente back-up op toepassingsniveau te krijgen). Als u een SQL Server-database in azure VM-back-up gebruikt, kunt u de instelling wijzigen om een BACK-up van VSS-kopie te maken (om logboeken te behouden). Zie dit artikel voor meer informatie.
Linux-VM's: als u app-consistente momentopnamen van Linux-VM's wilt maken, gebruikt u het prescript- en postscriptframework van Linux om uw eigen aangepaste scripts te schrijven om consistentie te garanderen.
- Azure Backup roept alleen de vooraf/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 | Dit is de standaardinstelling in het back-upbeleid voor vm's. App-consistente back-ups leggen geheugeninhoud vast en wachtende I/O-bewerkingen. App-consistente momentopnamen maken gebruik van een VSS Writer (of pre-/postscripts voor Linux) om de consistentie van de app-gegevens te garanderen voordat er een back-up wordt gemaakt. | Wanneer u een VIRTUELE machine herstelt met een app-consistente momentopname, wordt de VM opgestart. Er is geen beschadiging of verlies van gegevens. De apps beginnen in een consistente status. | Windows: Alle VSS-schrijvers zijn geslaagd Linux: Scripts vooraf/na zijn geconfigureerd en voltooid |
| Bestandssysteemconsistent | Dit is de standaardinstelling in het back-upbeleid voor vm's. Consistente back-ups van bestandssysteem 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 scripts vooraf/post niet zijn geconfigureerd of mislukt) |
| Crashconsistent | Crashconsistente momentopname is een opt-in-instelling in het back-upbeleid van de VM. Azure Backup maakt ook crashconsistente back-ups als de VIRTUELE machine niet wordt uitgevoerd tijdens de back-up en wanneer toepassings-/bestandsconsistente back-ups mislukken. Alleen de gegevens die al op de schijf aanwezig zijn op het moment van de back-upbewerking, worden vastgelegd en een back-up gemaakt; gegevens in de hostcache lezen/schrijven worden niet vastgelegd. |
Begint met het VM-opstartproces, gevolgd door een schijfcontrole om beschadigingsfouten op te lossen. Alle in-memory gegevens of schrijfbewerkingen die niet zijn overgedragen naar de schijf voordat het vastlopen verloren gaat. 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 door de databasesoftware teruggedraaid totdat de gegevens consistent zijn. | Wanneer u ervoor hebt gekozen om een back-up van het toepassings-/bestandssysteem en de VM uit te sluiten (gestopt/de toewijzing ervan ongedaan gemaakt) en wanneer de momentopname opnieuw wordt geprobeerd. U hebt gekozen voor crashconsistente back-ups zonder agent |
Notitie
Als de inrichtingsstatus is geslaagd, maakt Azure Backup consistente back-ups van het bestandssysteem. 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 VIRTUELE machine bijvoorbeeld vier schijven heeft, probeert de Backup-service een back-up te maken van alle vier de schijven parallel. 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 niet overlappen. Als op hetzelfde moment back-ups worden gemaakt van VM's, treden er netwerkproblemen op. |
| Back-ups voorbereiden | Houd de tijd in gedachten die nodig is om de back-up voor te bereiden. De voorbereidingstijd kan bestaan uit het installeren of bijwerken van de back-upextensie en het activeren van een momentopname volgens het back-upschema. |
| Gegevensoverdracht | Denk aan 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 de evaluatie van alle gewijzigde blokken is voltooid, worden de wijzigingen door Azure Backup overgedragen naar de kluis. Er kan een vertraging optreden tussen het maken van de momentopname 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 | De totale back-uptijd voor incrementele back-ups is minder dan 24 uur, wat mogelijk niet het geval is 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 verwerkt hersteltaken van meerdere opslagaccounts tegelijk en plaatst herstelaanvragen in een wachtrij. |
| Kopie terugzetten | Tijdens het herstelproces worden gegevens uit de kluis gekopieerd 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 beperken, selecteert u een opslagaccount dat niet wordt geladen met andere schrijf- en leesbewerkingen van toepassingen. |
Notitie
Met Azure Backup kunt u nu meerdere keren per dag een back-up maken van uw Azure-VM's met behulp van het uitgebreide beleid. Met deze mogelijkheid kunt u ook de duur definiëren waarin uw back-uptaken uw back-upschema activeren en afstemmen met de werkuren wanneer er frequente updates voor Azure Virtual Machines zijn. Meer informatie.
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 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, is 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 voordat de back-up (meer dan acht uur) is voltooid.
- Back-upversies: De nieuwste versie van Backup (ook wel de versie direct herstellen genoemd) maakt gebruik van een meer geoptimaliseerd proces dan de controlesomvergelijking voor het identificeren van wijzigingen. Maar als u Direct herstellen gebruikt en een momentopname van een back-up hebt verwijderd, schakelt de back-up over naar de controlesomvergelijking. In dit geval duurt de back-upbewerking langer dan 24 uur (of mislukt deze).
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 herstelt vanuit één kluis, raden we u ten zeerste aan om 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 worden hersteld, gebruikt u 10 verschillende opslagaccounts.
- Voor back-ups van VM's die gebruikmaken van Premium Storage met Instant Restore, wordt u aangeraden 50% vrije ruimte toe te wijzen aan de totale toegewezen opslagruimte, die alleen vereist 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 waaraan beheerde schijven worden hersteld. Meer informatie vindt u hier.
Back-upkosten
Azure-VM's waarvan een back-up is gemaakt met Azure Backup, zijn onderhevig aan azure Backup-prijzen.
Facturering wordt pas gestart 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 VIRTUELE machine worden opgeslagen in een kluis. Als u de beveiliging voor een virtuele machine stopt, maar back-upgegevens voor de VIRTUELE machine in een kluis aanwezig zijn, wordt de facturering voortgezet.
Facturering voor een opgegeven VIRTUELE machine stopt alleen als de beveiliging wordt 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 beveiligde instantiegrootte die wordt gebruikt voor de maandelijkse factuur.
Als u ervoor hebt gekozen om op agents gebaseerde toepassingsconsistente of bestandssysteemconsistente back-ups te maken, is de berekening van de grootte van de beveiligde instantie gebaseerd op de werkelijke grootte van de virtuele machine. De grootte van de VIRTUELE machine is de som van alle gegevens in de VIRTUELE machine, 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.
Notitie
Voor crashconsistente back-ups zonder agent worden er momenteel 0,5 beveiligde exemplaren (PI) per VM in rekening gebracht tijdens de preview.
Op dezelfde manier is de back-upopslagfactuur 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 in dit geval is 17 GB + 30 GB + 0 GB = 47 GB. Deze grootte van beveiligde exemplaren (47 GB) wordt de basis voor de maandelijkse factuur. Naarmate de hoeveelheid gegevens in de VIRTUELE machine toeneemt, wordt de grootte van de beveiligde instantie die wordt gebruikt voor factureringswijzigingen aangepast.