Herstelplanning begint met de vraag welke bedrijfsdienst wanneer weer beschikbaar moet zijn. Een lijst van virtuele machines is onvoldoende, omdat applicaties afhankelijk zijn van identiteit, DNS, databases, certificaten, netwerkregels en externe koppelingen. Maak die keten zichtbaar voordat u een test uitvoert.
Voor een algemene introductie kunt u de pagina over Veeam Backup and Replication raadplegen. Deze handleiding gaat over herstelontwerp en periodieke toetsing, niet over installatie.
Vertaal RPO naar gegevensverlies
Recovery Point Objective geeft aan hoeveel gegevensverlies in tijd aanvaardbaar is. Een RPO van vier uur betekent niet automatisch dat één taak per vier uur voldoende is. Taken kunnen uitlopen of mislukken; verwerking en kopiëren naar een tweede locatie kosten tijd. Meet daarom de werkelijke ouderdom van bruikbare herstelpunten.
Verschillende gegevens verdienen verschillende doelen. Een transactiedatabase kan een kortere RPO vragen dan een statische documentatieomgeving. Leg eigenaar, bron, frequentie en laatste succesvolle verificatie per klasse vast. Zo blijft beleid uitvoerbaar en worden uitzonderingen zichtbaar.
Maak RTO meetbaar
Recovery Time Objective is de maximaal aanvaardbare tijd tot herstel van dienstverlening. Neem besluitvorming, toegang tot media, inventarisatie, datatransport, opstart, validatie en vrijgave mee. Alleen de duur van een restore-job meten geeft een te optimistisch beeld.
Splits de totale tijd in stappen en wijs iedere stap een eigenaar toe. Wanneer het ophalen uit objectopslag de grens bepaalt, vraagt dat een andere oplossing dan een lange applicatiecontrole. Gebruik metingen uit tests in plaats van theoretische doorvoersnelheden.
Bepaal de herstelvolgorde
Start met gemeenschappelijke voorzieningen die andere systemen nodig hebben, maar voorkom een universele volgorde zonder scenario. Bij verlies van één applicatie is identity misschien al beschikbaar; bij verlies van een locatie niet. Maak runbooks voor minimaal een bestand, een applicatie, een volledige workload en een locatiebrede storing.
Noteer per stap bronherstelpunt, doelomgeving, netwerkzone, benodigde credentials en acceptatiecriterium. Houd een korte noodversie beschikbaar buiten de productieomgeving. Een document op de getroffen fileserver helpt niet tijdens een groot incident.
Kies de juiste herstelmethode
Granulair herstel is passend voor een verwijderd bestand of object. Een volledige machine restore helpt bij brede corruptie. Instant Recovery kan een dienst snel starten vanaf back-upopslag, waarna migratie naar productieopslag volgt. Iedere methode heeft andere capaciteit en nazorg nodig.
Test niet alleen het snelste demonstratiescenario. Grote volumes, trage verbindingen en afhankelijkheden bepalen de werkelijke uitkomst. Controleer bij instant herstel hoe de repository reageert op productiewerkbelasting en hoeveel tijd de definitieve migratie vraagt.
Bouw een geïsoleerde testomgeving
Hersteltests mogen productie niet verstoren en mogelijke malware niet opnieuw activeren. Gebruik een geïsoleerd netwerk met gecontroleerde toegang. Voorkom dubbele IP-adressen, ongewenste e-mail, geplande taken en verbindingen naar externe productiepartners.
Maak testdata en logs zorgvuldig schoon wanneer persoonsgegevens betrokken zijn. Beperk toegang tot deelnemers en verwijder de omgeving na acceptatie volgens beleid. Een hersteltest is geen vrijstelling van privacy- en beveiligingsregels.
Definieer functionele acceptatie
Een draaiende VM is slechts een technische mijlpaal. Laat een applicatie-eigenaar controleren of gebruikers kunnen aanmelden, gegevens de juiste datum hebben, kerntransacties werken en rapportages consistent zijn. Gebruik vooraf geschreven tests zodat succes niet tijdens de oefening wordt hergedefinieerd.
Controleer daarnaast integriteit, patches en indicatoren van compromittering. Bij een cyberincident beslist incidentrespons of een herstelpunt schoon genoeg is. Herstelbaarheid en veiligheid moeten samen worden beoordeeld.
Meet en rapporteer
Registreer starttijd, beslismoment, gekozen herstelpunt, duur per stap, technische fouten en moment van functionele acceptatie. Vergelijk gemeten RPO en RTO met afspraken. Een geslaagde test met overschreden tijd is een waardevolle bevinding, geen volledig succes.
Maak verbeteracties concreet met eigenaar en deadline. Veel terugkerende vertraging ontstaat door ontbrekende toegang, verouderde contactlijsten, onduidelijke prioriteit of onvoldoende repositoryprestaties. Deze organisatorische problemen zijn even relevant als technische fouten.
Plan verschillende testniveaus
Automatische verificatie kan frequent draaien en basisfouten vroeg vinden. Gerichte technische restores toetsen bestanden en machines. Een volledige ketentest beoordeelt applicaties en samenwerking. Tafeloefeningen verkennen besluitvorming voor scenario’s die niet vaak technisch kunnen worden nagebootst.
Combineer de niveaus in een jaarplanning op basis van risico. Kritieke diensten verdienen vaker een diepgaande test dan systemen die gemakkelijk opnieuw kunnen worden opgebouwd. Test opnieuw na grote migraties, platformupdates of wijzigingen in identiteit en netwerk.
Onderhoud het runbook
Een runbook is een levend document. Werk screenshots, paden, rollen en contactpersonen bij na iedere oefening. Verwijder stappen die geen waarde leveren en automatiseer herhaalbare controles waar dat veilig kan. Bewaar versiehistorie zodat wijzigingen te herleiden zijn.
Laat een andere beheerder de procedure uitvoeren. Als herstel alleen lukt met ongeschreven kennis van één specialist, is de organisatie kwetsbaar. De beste test levert niet alleen een werkende applicatie op, maar ook een procedure die een bevoegd team onder druk kan volgen.
Meet het volledige proces
De klok stopt pas wanneer de verantwoordelijke eigenaar de dienstverlening functioneel heeft geaccepteerd, niet wanneer de restore-job op 100 procent staat.