Azure Site Recovery disaster recovery plan opzetten? Leer in deze stap-voor-stap guide hoe u maximale uptime behaalt. Nu beginnen!

Het harde realiteit: uw bedrijf kan zich geen uren downtime veroorloven

Vorige maand sprak ik met de IT-directeur van een middelgroot productiebedrijf in de Randstad. Hun ERP-systeem lag 6 uur plat na een storage-fout in hun datacentrum. De schade: €340.000 aan verloren productie-uren, boetes voor vertraagde leveringen, en drie klanten die serieus dreigden af te haken. "We wisten dat we een DR-plan nodig hadden," zei hij, "maar we wisten niet waar te beginnen."

De cijfers onderstrepen de urgentie. Volgens Gartner gemiddelde een datacenter outage in 2024 €266.000 per incident — een stijging van 23% ten opzichte van 2022. Voor bedrijven in de gezondheidszorg of financiële sector loopt dat cijfer nog hoger op, vooral wanneer compliance-boetes meegerekend worden.

Disaster recovery (DR) is geen luxe meer. Het is een bedrijfskritische investering. En Microsoft Azure biedt met Azure Site Recovery een oplossing die toegankelijk is voor organisaties vanaf 50虚拟machines, maar schaalt naar enterprise-implementaties met duizenden workloads.

In dit artikel deel ik hoe u een robuust DR-plan opzet: bewezen architecturen, concrete configuratiestappen, en valkuilen die ik in de praktijk heb gezien bij klanten die deze service hebben geïmplementeerd.

Waarom Azure Site Recovery de juiste keuze is voor uw DR-strategie

Bij het evalueren van disaster recovery oplossingen staan organisaties voor een fundamenteel dilemma: bouw zelf een secundair datacentrum (expensive, complex) of gebruik een managed DR-as-a-Service platform (sneller, voorspelbare kosten). Azure Site Recovery valt in de tweede categorie en onderscheidt zich op drie punten:

  1. Native integratie met Microsoft Azure: Replicatie naar Azure-regio's vereist geen derde-partij middleware. Uw Windows- en Linux-workloads worden direct gesynchroniseerd via een lichtgewicht agent of via storage-level replicatie.

  2. Ondersteuning voor hybride scenario's: U kunt niet alleen Azure-naar-Azure repliceren, maar ook on-premises VMware/Hyper-V naar Azure, fysieke servers naar Azure, en zelfs AWS-werklasten naar Azure migreren.

  3. Geïntegreerde orchestratie: De service automatiseert niet alleen replicatie, maar ook failover-testing, geplande failovers, en failback — alles vanuit één centrale portal.

De prijsstelling is eveneens gunstig. Azure Site Recovery rekent per protected instance: €5,44 per maand per beveiligde instance (Europa-west, Standard-tier) plus opslagkosten voor de gerepliceerde schijven (vanaf €0,018 per GB per maand voor lokaal redundante opslag). Voor een gemiddelde server met 500 GB schijfruimte bent u dus rond de €14,50 per maand kwijt — een fractie van de kosten voor een eigen secundair datacentrum.

Stap 1: Inventariseer uw workloads en definieer RPO/RTO-doelstellingen

Voordat u ook maar iets configureert, moet u weten wat u beschermt en hoeveel downtime acceptabel is. Dit is waar veel DR-projecten falen: organisaties repliceren alles naar Azure zonder onderscheid te maken tussen kritieke en minder belangrijke systemen.

Werklastcategorisatie

Ik adviseer een risicomatrix met drie categorieën:

  • Tier 1 (Missiekritiek): Databases, ERP-systemen, betalingsverwerking. RTO: <15 minuten, RPO: <5 minuten.
  • Tier 2 (Bedrijfskritiek): E-mail, CRM, bedrijfskritieke applicaties. RTO: <1 uur, RPO: <15 minuten.
  • Tier 3 (Ondersteunend): Interne tools, ontwikkelomgevingen,archivering. RTO: <4 uur, RPO: <1 uur.

RPO (Recovery Point Objective) is de maximale toelaatbare dataverlies in tijd. RTO (Recovery Time Objective) is hoe lang het duurt voordat systemen weer operationeel zijn na een incident.

Voor een typische Windows Server-omgeving met SQL Server kunt u met Azure Site Recovery synchrone replicatie (RPO = 0) bereiken door CRR (Continuous Replication) in te schakelen, maar dit vereist lage latentie tussen uw bron en Azure-regio — idealiter onder 5 ms. Voor de meeste Europese organisaties die repliceren naar Azure-regio's in West-Europa of Noord-Europa is dit haalbaar.

Praktische tip: valideer uw latentie

Voordat u Azure Site Recovery configureert, meet ik altijd eerst de netwerklatentie tussen uw bronlocatie en de doel-Azure-regio. Gebruik Azure Speed Test (azurespeed.com) of Powershell:

Test-NetConnection -ComputerName portal.azure.com -Port 443

Als de latency boven 50 ms ligt, overweeg dan een intermediaire Azure-regio of een traffic manager met endpoint health checks. Boven 100 ms wordt asynchrone replicatie met frequentie om de 30 seconden de realistische optie.

Stap 2: Creëer uw Recovery Services Vault

De Recovery Services Vault is de centrale container waarin alle DR-configuraties, replicatiebeleid en recovery points worden opgeslagen. Dit is uw operationele cockpit.

Configuratiestappen

  1. Open de Azure Portal en zoek naar "Recovery Services vaults"
  2. Klik op Create en selecteer uw abonnement, resourcegroep, en een regio — dit moet een andere regio zijn dan uw bronnen (voor geo-redundantie)
  3. Kies bij Storage redundancy voor Geo-redundant (standaard) of Zone-redundant als u binnen één regio DR wilt voor AZ-uitval. Voor DR tegen regionale outages: altijd geo-redundant.
  4. Na creatie opent u de vault en navigeert naar Properties > Update onder "Storage settings" om de replicatie-instellingen te beheren.

Belangrijk: De vault moet in een andere regio staan dan uw bronnen. Als uw productie in West-Europa draait, plaatst u de vault in North Europe of een volledig ander geografisch gebied zoals UK South of Germany West Central.

Stap 3: Implementeer de Mobility Service op uw bronservers

De Mobility Service is de agent die daadwerkelijk IO-wijzigingen vastlegt en naar Azure verzendt. Deze moet op elke machine geïnstalleerd worden die u wilt beschermen.

Push-installatie vs. handmatige installatie

Azure Site Recovery ondersteunt push-installatie: wanneer u replicatie inschakelt voor een machine, installeert de service automatisch de Mobility Service via poort 443 (HTTPS) of poort 9443 (data). Voor servers achter strikte firewalls kunt u de agent ook handmatig downloaden via de vault.

Minimale vereisten voor Windows:

  • Windows Server 2012 R2 of hoger
  • .NET Framework 4.6.2 of hoger
  • PowerShell 5.1 of hoger
  • Minimaal 2 GB vrije schijfruimte voor de agent

Voor Linux:

  • Red Hat Enterprise Linux 7.3 tot 9.x, CentOS 7.3 tot 9.x, Ubuntu 18.04/20.04/22.04 LTS, SUSE Linux Enterprise Server 12 SP5 of 15.x
  • De Linux-agent vereist kernel-headers en compilatietools als u uit broncode installeert (standaard .deb/.rpm packages zijn ook beschikbaar).

Na installatie ziet u de server verschijnen onder Site Recovery infrastructure > Protected items > Replicated items. De eerste replicatie — afhankelijk van uw datavolume en bandbreedte — kan 4 tot 48 uur duren.

Stap 4: Configureer replicatiebeleid en storage

Replicatie-instellingen

Binnen de vault onder Manage > Site Recovery infrastructure > Replication policies definieert u hoe agressief uw replicatie is:

  • Recovery point retention: Hoe lang worden recovery points bewaard? Standaard 24 uur, uitbreidbaar naar 72 uur (Standard) of zelfs 180 dagen (Enhanced). Langer bewaren kost meer opslag maar biedt meer flexibiliteit bij corrupte data.
  • App-consistent snapshot frequentie: Voor applicaties zoals SQL Server of SharePoint kunt u app-consistente snapshots instellen (elke 1, 4, 6, of 12 uur). Dit zorgt ervoor dat transactielogs correct worden afgesloten en databases in een consistente staat zijn na recovery.

Multi-VM consistentie groepen

Als u applicaties hebt die uit meerdere VMs bestaan (bijvoorbeeld een SharePoint-farm met webfrontend, app-server, en database), plaatst u deze in een Consistency Group. Dit garandeert dat alle VMs na een failover een gezamenlijk herstelpunt delen — cruciaal voor applicaties met transactieafhankelijkheden.

Opslagkeuze voor gerepliceerde data

Binnen Azure heeft u drie opties:

  • Lokaal redundante opslag (LRS): 3 kopieën binnen één datacenter. Goedkoop, maar kwetsbaar voor regionaal falen.
  • Geografisch redundante opslag (GRS): 3 kopieën in primaire regio, 3 in secundaire regio. Aanbevolen voor DR tegen regionale outages. €0,018 per GB vs. €0,014 voor LRS.
  • Geografisch redundante opslag met leestoegang (RA-GRS): Voegt lees-toegang toe tot de secundaire kopie. Nuttig voor disaster recovery testing zonder productie-verstoring.

Ik adviseer GRS voor alle Tier 1 workloads. De kostenstijging van 28% rechtvaardigt de risicoreductie.

Stap 5: Implementeer Azure Backup als aanvulling op DR

Een belangrijk onderscheid: Azure Site Recovery beschermt tegen infrastructurele outages (hardware, netwerk, complete datacentre failure), maar beschermt niet tegen logische corruptie of ransomware. Daarvoor hebt u Azure Backup nodig.

In de praktijk adviseer ik een gelaagde strategie:

Laag Technologie Doel
DR-replicatie Azure Site Recovery Snelle failover bij infrastructuuruitval
Backups Azure Backup Bescherming tegen dataverlies, ransomware
Archivering Azure Blob Storage met immutability Langetermijnretentie, compliance

Azure Backup voor Windows Servers begint bij €6,50 per maand per protected instance (Europa-west) plus opslagkosten. Voor SQL Server-workloads kunt u daily backups met 7-jaar retentie configureren voor ongeveer €12-18 per maand afhankelijk van de databasegrootte.

Praktijkvoorbeeld: Bij een van mijn klanten in de zorgsector werd hun productie-VM gecompromitteerd door ransomware. Gelukkig had ik Azure Site Recovery geconfigureerd voor DR, maar de malware verspreidde zich via de replicatie en bereikte de Azure-replica's. Gelukkig waren er ook Azure Backup-punten van 24 uur eerder die schoon waren. De les: isoalteer uw backup-infrastructuur van uw replicatie-infrastructuur met aparte netwerksegmenten en IAM-rollen.

Stap 6: Automatiseer failover met Recovery Plans

Recovery Plans orchestreren de volgorde waarin VMs worden gestart na een failover. Dit is essentieel voor applicaties met afhankelijkheden.

Structuur van een Recovery Plan

Een goed Recovery Plan volgt de driefasenbenadering:

  1. Pre-actions (optioneel): Scripts of Azure Automation-runbooks die vóór de failover draaien, bijvoorbeeld om databases te detachachen of VPN-tunnels te sluiten.
  2. Boot groepen: Groepeer VMs op basis van opstartprioriteit. Group 0 bevat domain controllers en infrastructuurservices. Group 1 bevat applicatieservers. Group 2 bevat frontends en gebruikersinterfaces.
  3. Post-actions: Automatische stappen na failover, zoals health checks, DNS-updates, of notificaties naar monitoringtools.

Azure Automation Runbook voorfailover scripting

U kunt PowerShell-runbooks integreren voor geavanceerde automatisering. Een voorbeeld voor het automatisch aanpassen van connection strings na failover:

param(
    [Parameter(Mandatory=$true)]
    [string]$ResourceGroupName,
    
    [Parameter(Mandatory=$true)]
    [string]$WebAppName,
    
    [Parameter(Mandatory=$true)]
    [string]$NewConnectionString
)

$webApp = Get-AzWebApp -ResourceGroupName $ResourceGroupName -Name $WebAppName
$appSettings = @{"ConnectionString" = $NewConnectionString}
Set-AzWebApp - WebApp $webApp -AppSettings $appSettings

Dit script kunt u koppelen aan uw Recovery Plan zodat applicatieconfiguraties automatisch worden bijgewerkt wanneer de DR-omgeving activeert.

Stap 7: Test, test, en test nogmaals — maar dan in een geïsoleerde omgeving

Dit is het stadium waarop veel organisaties falen. Ze configureren DR perfect, maar testen nooit of de failover daadwerkelijk werkt. Een niet-geteste DR-strategie is geen DR-strategie.

Test Failover vs. Planned Failover vs. Unplanned Failover

Azure Site Recovery biedt drie failover-types:

  • Test Failover: Maakt een volledig geïsoleerde kopie van uw DR-omgeving. Geen impact op productie. Ideale voor maandelijkse validatie.
  • Planned Failover: Geplande, gecontroleerde migratie (bijvoorbeeld voor datacentrumverhuizing). Geen dataverlies.
  • Unplanned Failover: Geactiveerd tijdens daadwerkelijke uitval. Mogelijk dataverlies afhankelijk van uw RPO.

Testfrequentie

Ik adviseer:

  • Maandelijks: Test Failover naar geïsoleerde netwerkomgeving
  • Kwartaal: Volledige Recovery Plan-validatie met applicatie-eigenaren
  • Halfjaarlijks: Failback-test (recovery naar originele locatie)
  • Na grote wijzigingen: Direct na significant infrastructuurwijzigingen (nieuwe VMs, netwerkupdates, applicatieversie-upgrades)

Aandachtspunt: Bij het uitvoeren van Test Failover wordt een temporary VNet aangemaakt. Zorg dat dit VNet geen overlap heeft met uw productienetwerk en dat de test-VMs geïsoleerd zijn van productie-systemen om per ongeluk verkeersomleiding te voorkomen.

Stap 8: Monitoring en alerting configureren

Een DR-oplossing die niemand in de gaten houdt, is waardeloos. Azure Site Recovery heeft ingebouwde monitoring, maar ik adviseer aanvullende configuratie:

Azure Monitor Alerts

Stel waarschuwingen in voor kritieke gebeurtenissen:

  • Replicatie health: Alert wanneer replicatie langer dan 15 minuten stagneert
  • Recovery point leeftijd: Alert wanneer de oudste recovery point ouder is dan uw RPO (bijvoorbeeld: geen schone recovery point in 30 minuten bij RPO = 15 min)
  • Agent health: Alert wanneer Mobility Service agent offline gaat

Log Analytics-integratie

Door Azure Site Recovery te koppelen aan Log Analytics kunt u aangepaste dashboards bouwen en correleren met andere Azure-services:

AzureDiagnostics
| where Category == "AzureSiteRecoveryJobs"
| where OperationName == "Failover"
| project TimeGenerated, SourceServer, TargetServer, DurationSeconds

Dit geeft inzicht in failover-tijden over tijd en helpt bij het identificeren van trends.

Stap 9: Documentatie en runbook-ontwikkeling

Technische implementatie is slechts de helft van het DR-plan. De andere helft is procesdocumentatie die ook werkt onder druk, midden in de nacht, met slaapgebrekte engineers.

Minimum vereiste documentatie

  1. Contactlijst: Escalatiepaden, vendor contacten, interne sleutelfiguren
  2. Stap-voor-stap runbooks: Geautomatiseerd waar mogelijk, met handmatige stappen als backup
  3. Netwerkdiagram: Alle connectiviteitsroutes, IP-ranges, DNS-entries
  4. Recovery procedures per applicatie: Specifieke stappen voor elke Tier 1-applicatie
  5. Testresultaten: Gedateerde verslagen van alle uitgevoerde failover-tests

Ik adviseer dit document te behandelen als code: version-control (Git), peer review, en regelmatige updates. Een DR-plan dat alleen in iemands hoofd leeft, is een risico.

Kostenoptimalisatie: hoe u niet betaalt voor onnodige redundantie

Een veelgemaakte fout is over-engineering: alles repliceren op de hoogste frequentie naar de duurste opslag. Hier zijn mijn aanbevelingen voor kostenbeheersing:

  1. Gebruik availability zones voor Tier 2-workloads: In plaats van volledige regio-redundantie kunt u voor minder kritieke systemen kiezen voor Availability Zones binnen één regio. Dit kost €0,013 per GB per maand in plaats van €0,018.

  2. Expiry policies instellen: Automatischrecovery points verwijderen na hun nuttige levensduur. Standaard 24 uur is vaak voldoende voor niet-kritieke workloads.

  3. Cold tier voorarchief: Oude recovery points kunt u verplaatsen naar Azure Archive Blob Storage (€0,0008 per GB per maand) voor compliance-retentie zonder de operationele kosten.

  4. Azure Reserved Instances: Als u langdurig DR-rekencapaciteit in Azure aanhoudt, kunt u Reserved VM Instances kopen voor 1 of 3 jaar — tot 72% kostenbesparing versus pay-as-you-go.

Compliance-overwegingen: GDPR, HIPAA en SOC 2

Als uw organisatie valt onder strenge compliance-vereisten, zijn er aanvullende overwegingen:

Data residency

Azure Site Recovery respecteert data residency door replicatie standaard naar een door u gekozen regio. Voor GDPR-compliance moet u ervoor zorgen dat de doelregio adequaat is. De EU Data Boundary-initiative van Microsoft garandeert dat klantdata binnen de EU blijft voor Europese workloads.

Versleuteling

Alle gerepliceerde data wordt in rust versleuteld met AES-256. Voor extra beveiliging kunt u customer-managed keys (CMK) gebruiken via Azure Key Vault — handig voor HIPAA-complaince waar u aantoonbaar controle moet hebben over versleutelingssleutels.

Audit logging

Azure Site Recovery logt alle operations naar Azure Activity Logs en Azure Diagnostic Logs. Deze logs kunt u streamen naar Azure Sentinel of een SIEM-oplossing voor real-time threat detection.

Veelgemaakte fouten en hoe ze te vermijden

Fout 1: Replicatie naar dezelfde regio

Het klinkt очевидно, maar ik zie het regelmatig: klanten die Azure Site Recovery configureren en per ongeluk hun recovery vault in dezelfde Azure-regio plaatsen als hun productie. Bij een regionaal outage verliest u dan zowel productie als DR.

Fout 2: Te hoge RPO/RTO-verwachtingen

Een RTO van 0 minuten is technisch onmogelijk bij asynchrone replicatie. Wees realistisch: <15 minuten RTO vereist geautomatiseerde failover, snelle VM-herstart, en vooraf geteste applicatiescripts. Zonder deze investering is 1-4 uur realistischer.

Fout 3: Failover vergeten te testen

Zoals eerder genoemd: niet-geteste DR is geen DR. Ik heb meegemaakt dat een klant bij een echte outage ontdekte dat hun recovery plan scripts bevatte voor Windows Server 2012 terwijl ze inmiddels waren gemigreerd naar 2022 — scripts faalden, recovery duurde 18 uur in plaats van de geplande 2 uur.

Fout 4: Bandbreedte onderschatten

Initieële replicatie en continued replicatie verbruiken bandbreedte. Azure Site Recovery compressie gebruikt (tot 72% reductie), maar voor grote datavolumes (50+ TB) hebt u een Azure ExpressRoute-verbinding of voldoende internetbandbreedte nodig. Een vuistregel: reken op 500 kbps per VM voor continue replicatie van typische kantoorwerklasten.

Conclusie: Disaster recovery is een continu proces, geen project

Het opzetten van Azure Site Recovery is geen eenmalig project. Het vereist doorlopende aandacht: maandelijkse tests, kwartaalreviews, en continue aanpassing na infrastructuurwijzigingen. Maar de investering betaalt zich terug bij de eerste significante outage die u afwendt.

Voor organisaties die al in het Microsoft-ecosysteem zitten, is Azure Site Recovery de meest kosteneffectieve manier om enterprise-grade disaster recovery te bereiken. De integratie met Azure Monitor, Azure Automation, en Azure Backup creëert een complete data protection strategie die schaalt van MKB tot enterprise.

Heeft u hulp nodig bij het ontwerpen of implementeren van uw DR-strategie? Ciro Cloud is gespecialiseerd in cloudinfrastructuur en disaster recovery-oplossingen. Neem contact op voor een gratis consultatie waarin we uw huidige risicoprofiel analyseren en concrete aanbevelingen doen voor uw specifieke situatie.

De kracht van een goed DR-plan ligt niet in de technologie — het ligt in de discipline om het regelmatig te testen, te evalueren, en te verbeteren. Azure Site Recovery geeft u de tools; de rest is organisatie en toewijding.

Wekelijkse cloud insights — gratis

Praktische gidsen over cloud kosten, beveiliging en strategie. Geen spam.

Comments

Leave a comment