DR-test uden påvirkning

En disaster recovery-plan, der aldrig er blevet testet, er kun en hypotese. Erfaring fra virkeligheden viser, at DR-planer ofte afslører mangler — konfigurationsafvigelser, manglende automatisering, forældede runbooks eller længere opstartstider end forventet — som kun viser sig under testforhold. Regelmæssig DR-test er den eneste måde at være sikker på, at planen virker, når du har mest brug for den.

Test Failover er en indbygget funktion i Azure Site Recovery, der lader dig simulere en failover til den sekundære region uden at afbryde produktionen. Under en testfailover opretter ASR kopier af de replikerede VM'er i et isoleret virtuelt netværk i den sekundære region. Produktions-VM'erne fortsætter med at køre normalt i den primære region, så der er ingen risiko for aktive brugere.

Det isolerede test-VNet må ikke have forbindelse til produktionssystemer. Det forhindrer test-VM'er i ved et uheld at skrive til produktionsdatabasen, sende e-mails til rigtige kunder eller udløse betalingstransaktioner. Opret et dedikeret testfailover-VNet uden peering til produktions-VNet'er og uden internetadgang, og brug det udelukkende til DR-øvelser.

En DR-test bør validere et bestemt sæt kriterier:

• Opstartstid — starter alle VM'er inden for det forventede tidsvindue?
• Opstart af applikationen — initialiseres applikationen korrekt, når den har forbindelse til den gendannede database?
• Dataintegritet — er dataene på gendannelsespunktet konsistente og komplette?
• Faktisk RTO — mål den samlede forløbne tid fra udløsning af failover til applikationen begynder at behandle forespørgsler
• Udførelse af runbook — blev alle automatiseringsscripts gennemført korrekt?

Start en timer, så snart du udløser testfailoveren. Stop timeren, når det er bekræftet, at applikationen er sund (belastningsfordelerens sundhedskontrol returnerer 200 OK). Dette er din faktiske RTO. Sammenlign den med din mål-RTO. Hvis den faktiske RTO overstiger målet, skal du identificere flaskehalsene — langsom VM-opstart, lang databaseinitialisering eller forsinkelse i DNS-udbredelsen — og afhjælpe dem.

Når testfailoveren er gennemført, skal du oprette forbindelse til den gendannede database og kontrollere dataene. Kontrollér, at transaktioner, der blev bekræftet før replikeringsafskæringen, er til stede, og at delvist bekræftede transaktioner håndteres korrekt (rulles tilbage eller fuldføres). For databaser med point-in-time restore (PITR) skal du teste gendannelse til et bestemt tidsstempel og kontrollere den forventede datatilstand.

Når testen er gennemført, skal du rydde testfailover-ressourcerne op — test-VM'erne, deres diske og netværksgrænseflader i den sekundære region. Azure Site Recovery indeholder handlingen 'Cleanup test failover' i portalen, som automatisk fjerner alle testressourcer. Hvis du glemmer oprydningen, spilder du penge og fylder den sekundære region med forældede ressourcer.

Efter hver DR-test skal du skrive en testrapport, der indeholder: testens dato og omfang, den opnåede faktiske RTO og RPO, en tjekliste over valideringspunkter med status for bestået/ikke bestået, eventuelle observerede mangler eller fejl samt de planlagte korrigerende handlinger. Denne rapport er værdifuld ved compliance-audits (ISO 27001, SOC 2, HIPAA) og til at følge forbedringen af DR-modenheden over tid.

Branchens bedste praksis og compliance-rammeværk kræver typisk DR-test mindst årligt, men mange organisationer tester kvartalsvist eller endda månedligt for arbejdsbelastninger i niveau 1. Hyppigere test opdager konfigurationsafvigelser tidligere og opbygger teamets tillid og rutine. Automatisér så meget som muligt af testopsætningen og -verificeringen for at reducere indsatsen ved hyppige test.

Azure Chaos Studio er en administreret tjeneste til kaosteknik, som lader dig indsætte kontrollerede fejl i Azure-ressourcer for at teste applikationens resiliens. Du kan lukke VM'er ned, få zoner til at svigte, begrænse CPU'en eller indsætte netværksforsinkelse for at observere, hvordan applikationen opfører sig. I modsætning til en standard-DR-øvelse tester kaosteknik, om applikationen håndterer delvise fejl på en kontrolleret måde.

DR-test er mest værdifuld som en del af en kontinuerlig forbedringscyklus: Planlæg → Udfør → Mål → Afhjælp → Gentag. Efter hver test skal du afhjælpe de fundne mangler, opdatere runbooks og dokumentation og derefter teste igen. Med tiden bør afstanden mellem dine angivne RTO/RPO-mål og de faktisk opnåede værdier blive mindre, indtil du konsekvent består hver test inden for tolerancen.

I denne lektion lærte du, at testfailover lader dig simulere en DR-hændelse uden at afbryde produktionen ved at oprette kopier af VM'er i et isoleret VNet; at du skal måle den faktiske RTO og kontrollere dataintegriteten under testen; og at du bør rydde testressourcerne op og dokumentere resultaterne efter hver øvelse. Næste gang undersøger vi disaster recovery specifikt for PaaS-tjenester som Azure SQL Database.