Herstellen vanuit Azure Backup

Elke geslaagde back-uprun maakt een herstelpunt: een snapshot van de beveiligde resource op een specifiek moment. Azure Backup bewaart herstelpunten volgens de bewaartermijnregels van het back-upbeleid. Wanneer je moet herstellen, selecteer je een herstelpunt en kies je een hersteltype. De beschikbare typen zijn afhankelijk van de resource: voor VM's kun je een volledige VM herstellen, een schijf herstellen of afzonderlijke bestanden herstellen. Als je deze opties begrijpt, kun je de snelste weg naar herstel kiezen.

Bij een volledig herstel van een VM wordt de volledige virtuele machine opnieuw gemaakt — de besturingssysteemschijf, gegevensschijven en netwerkinterface — vanuit een herstelpunt. Je kunt herstellen naar de oorspronkelijke locatie (waarbij de bestaande VM wordt vervangen) of naar een alternatieve locatie (waarbij een nieuwe VM wordt gemaakt met een andere naam of in een andere resourcegroep of regio). Volledig herstel is de langzaamste optie, maar herstelt een volledig defecte of verwijderde VM. Herstel tussen regio's wordt ook ondersteund als de kluis GRS-opslag gebruikt.

Bij schijfherstel worden de beheerde schijven vanuit een herstelpunt geëxporteerd naar een opgegeven opslagaccount, zonder een nieuwe VM te maken. Dit is handig wanneer je alleen specifieke gegevens van een schijf wilt herstellen of wanneer je de herstelde schijf aan een bestaande VM wilt koppelen voor onderzoek. Nadat de schijven zijn geëxporteerd, kun je ze koppelen, door het bestandssysteem bladeren en alleen de bestanden kopiëren die je nodig hebt — sneller dan een volledige VM-herstelbewerking starten.

Met herstel van onderdelen (ILR) kun je afzonderlijke bestanden en mappen uit een VM-back-up bekijken en herstellen zonder de volledige schijf te herstellen. Azure Backup koppelt het herstelpunt als een lokaal iSCSI-doel op een Windows- of Linux-computer. Je maakt verbinding met een meegeleverd script, bekijkt de gekoppelde schijf alsof het een lokaal station is en kopieert alleen de specifieke bestanden die je nodig hebt. De koppelingssessie verloopt na 12 uur om de blootstelling te beperken.

Bij het beoordelen van back-upstrategieën zijn twee meetwaarden belangrijk: RPO (Recovery Point Objective) is het maximale aanvaardbare gegevensverlies, uitgedrukt in tijd — als je back-up dagelijks wordt uitgevoerd, is je RPO maximaal 24 uur. RTO (Recovery Time Objective) is de tijd die het herstelproces zelf in beslag neemt. Volledige VM-herstelbewerkingen kunnen, afhankelijk van de schijfgrootte, 30 minuten tot meerdere uren duren. Herstel van afzonderlijke bestanden gaat veel sneller. Door je RPO en RTO af te stemmen op de bedrijfsvereisten, bepaal je je back-upschema en de keuze van je herstelstrategie.

Voor Azure Files waarvan een back-up is gemaakt via Azure Backup, heb je twee herstelopties. Bij herstel naar de oorspronkelijke locatie wordt de huidige inhoud van de share overschreven met de snapshot. Bij herstel naar een alternatieve locatie wordt de inhoud hersteld naar een andere fileshare of een ander opslagaccount, waarbij de huidige share ongewijzigd blijft. Je kunt ook een herstel van onderdelen uitvoeren om specifieke bestanden of mappen uit de snapshot te herstellen. Dit is het meest voorkomende hersteltype met de minste impact voor fileshares.

Met herstel tussen regio's (CRR) kun je VM's herstellen naar een secundaire (gekoppelde) regio wanneer de primaire regio niet beschikbaar is. CRR is alleen beschikbaar voor kluizen die zijn geconfigureerd met geografisch redundante opslag. Je moet CRR expliciet inschakelen in de eigenschappen van de kluis — standaard is dit niet ingeschakeld. Aan CRR zijn extra kosten verbonden, maar het is essentieel voor scenario's waarin je workloads in de secundaire regio moet herstellen voordat Azure Site Recovery de failover heeft voltooid.

Elke herstelbewerking maakt een back-uptaak van het type Herstellen die je kunt bewaken in het deelvenster Back-uptaken van de kluis. Het herstellen van grote schijven kan uren duren. Als een herstelbewerking halverwege mislukt (bijvoorbeeld door een machtigingsprobleem in het doelopslagaccount), geeft Azure Backup een gedetailleerde foutmelding en een koppeling naar documentatie. Je kunt het herstel opnieuw proberen zodra het onderliggende probleem is opgelost — een gedeeltelijk voltooid herstel beschadigt het herstelpunt niet.

Wanneer SQL Server op een Azure-VM wordt uitgevoerd en is beveiligd met de oplossing Azure Backup for SQL Server, krijg je extra mogelijkheden voor de nauwkeurigheid van het herstel. Je kunt herstellen naar een specifiek tijdstip (op basis van transactielogboekback-ups die elke 15–60 minuten worden uitgevoerd) in plaats van alleen naar een herstelpunt van een volledige back-up. Hierdoor wordt de RPO voor SQL-workloads aanzienlijk verlaagd ten opzichte van alleen back-ups op bestandssysteemniveau van de VM.

Veel organisaties testen hun back-ups nooit totdat zich een ramp voordoet — en ontdekken dan dat de back-ups beschadigd of onvolledig zijn, of veel langer duren om te herstellen dan verwacht. Volgens de aanbevolen werkwijze zijn regelmatige hersteloefeningen vereist: herstel naar een testresourcegroep, controleer de werking van de toepassing en documenteer de werkelijk behaalde RTO. De werkmap Backup Reports van Azure Backup Center biedt een nalevingsoverzicht met de datum van de laatste geslaagde back-up voor elk beveiligd onderdeel.

Azure Backup voor VM's houdt gedurende 1–5 dagen (configureerbaar in het beleid) een lokale snapshot voor direct herstel bij in de resourcegroep naast de VM. Herstellen vanuit deze lokale snapshot gaat veel sneller dan herstellen vanuit de kluis, omdat de gegevens niet vanuit de opslag van de kluis hoeven te worden overgedragen. Nadat de laag voor direct herstel is verlopen, wordt het herstelpunt alleen nog in de kluis opgeslagen. Door direct herstel te gebruiken voor recente incidenten verlaag je je RTO aanzienlijk.

In deze les heb je geleerd dat Azure Backup meerdere hersteltypen biedt — volledig herstel van een VM, schijfherstel en herstel van afzonderlijke bestanden — elk met andere afwegingen tussen snelheid en granulariteit, dat voor herstel tussen regio's GRS-kluizen vereist zijn en dit expliciet moet worden ingeschakeld, en dat regelmatige hersteloefeningen essentieel zijn om te controleren of je werkelijke RTO overeenkomt met de bedrijfsvereisten. Hierna bekijken we Azure Site Recovery voor het repliceren van volledige workloads naar een secundaire regio.