Stel RTO en RPO vast en test ze

Definieer twee afzonderlijke doelen

Recovery Time Objective, RTO, bepaalt de langste aanvaardbare onderbreking voordat de dienst weer bruikbaar moet zijn. Recovery Point Objective, RPO, bepaalt het grootste aanvaardbare gegevensverlies uitgedrukt in tijd. Spreek deze doelen af met de bedrijfsverantwoordelijke voor een bepaalde dienst en storingsscenario.

Een beschikbaarheidsdoel beschrijft dienstprestaties over een periode. RTO en RPO beschrijven herstelverwachtingen. Ze beantwoorden verschillende vragen.

Voor een fictieve besteldienst stelt de verantwoordelijke RTO op 60 minuten en RPO op 15 minuten. Dit zijn voorbeeldwaarden, geen algemene aanbevelingen. Een andere dienst kan andere grenzen nodig hebben omdat ontbrekende bestellingen en vertraagde rapporten andere gevolgen hebben.

Meet het volledige herstel

De dienst stopt om 10:00. Het team legt deze oefening vast:

De verstreken hersteltijd is 55 minuten. De oefening voldoet aan de RTO van 60 minuten. Alleen de hersteloperatie van 25 minuten tellen zou het grootste deel van de onderbreking verbergen.

Het nieuwste bruikbare herstelpunt is 09:40. Het gat tot de onderbreking om 10:00 is 20 minuten. Dat mist de RPO van 15 minuten met 5 minuten. Dezelfde gegevens sneller herstellen verkleint dat gat niet.

Inspecteer werkelijk ontbrekende of inconsistente records. Een tijdsgat beschrijft blootstelling; het telt niet de getroffen bestellingen. Stem externe betaal- en uitvoeringsrecords af voordat normale verwerking wordt hervat. Probeer andere aannames in de hersteloefening.

Kies een herstelstrategie

Een strategie moet de vereiste dienst, gegevens en dependencies dekken. Vergelijk deze patronen met gemeten doelen:

Voor deze patronen bestaan geen universele hersteltijden. Implementatie, gegevensvolume, dependencies en testomstandigheden bepalen het resultaat. Neem beheerkosten en teamcapaciteit mee in het besluit.

Bescherm tegen meer dan uitval

Een replica kan een onbedoelde verwijdering of corrupt record kopiëren. Bewaar herstelbare versies of bied point-in-time recovery waar nodig. Verifieer bewaartermijnen, herstelrechten en toegang tot encryptiesleutels. Stem back-upisolatie af op het scenario, inclusief verlies van toegang tot het primaire account.

Controleer bij regionaal herstel de toegestane gegevenslocatie en volledige dependencyketen. Neem identiteit, DNS, certificaten, secrets, deploymentartefacten, quota en netwerktoegang mee. Een herstelomgeving die één vereiste sleutel mist, kan onbruikbaar zijn.

Definieer wie de gebeurtenis mag uitroepen, wie herstel uitvoert en wie de herstelde dienst accepteert. Plan failback of voortgezet gebruik in de herstelomgeving. Voorkom conflicterende schrijfacties vanuit verschillende componenten en stem gegevens af voordat opnieuw wordt omgeschakeld.

Zet het plan om in bewijs

Schrijf een runbook en oefen het onder gecontroleerde omstandigheden. Leg scenario, datasetgrootte, begin- en eindtijd, hersteld gegevenspunt, mislukte stappen en verantwoordelijken vast. Verifieer een echte bedrijfshandeling met veilige testrecords.

Herhaal de oefening na relevante wijzigingen en volgens het afgesproken schema. Een schemawijziging, nieuwe externe dependency of ander gegevensvolume kan eerdere resultaten ongeldig maken. Koppel het oefenbewijs aan de release en operationele verantwoordelijkheden.