Een geslaagde back-up bewijst op zichzelf niet dat een applicatie weer beschikbaar kan worden gemaakt. Een sleutel, externe afhankelijkheid, bestanden die bij de database horen of een procedure die aangeeft in welke volgorde ze moeten worden hersteld, kunnen ontbreken. Met disaster-recoverytests voor PHP-applicaties kun je het volledige proces controleren voordat gegevensverlies of -corruptie ertoe dwingt het onder druk uit te voeren.
Het doel is niet te garanderen dat er nooit storingen zullen zijn, maar bewijs te verzamelen over wat kan worden hersteld, hoelang dat duurt en welke obstakels nog moeten worden aangepakt. Om de oefening nuttig te maken, moet je de reikwijdte bepalen, de omgeving isoleren, zowel de infrastructuur als het gedrag van de applicatie valideren en verantwoordelijken aanwijzen voor de nodige verbeteringen.
Een back-up controleren is niet hetzelfde als de service herstellen
Een back-upcontrole kan bevestigen dat een bestand bestaat, dat de grootte ervan redelijk lijkt of dat een tool het kan lezen. Dat is een waardevolle controle, maar iets anders dan de benodigde onderdelen herstellen en aantonen dat de applicatie ermee werkt.
Volledig herstel kan een database, door gebruikers geüploade bestanden, code en configuratie omvatten, evenals services zoals job queues, object storage, caching of geplande taken. Ook kan het afhangen van DNS, certificaten, permissies, PHP-extensies en externe services. Als een van deze onderdelen ontbreekt of niet overeenkomt met de rest, kan de back-up geldig zijn terwijl de service toch niet is hersteld.
Leg voor elke applicatie vast wat ‘hersteld’ betekent. Dat kan inhouden dat het PHP-proces start, dat bevoegde gebruikers kunnen inloggen en een kritieke workflow kunnen voltooien, of dat achtergrondtaken weer worden verwerkt. Een zichtbare startpagina is niet voldoende als enig criterium.
Stel vóór de start de reikwijdte en succescriteria vast
Documenteer het scenario dat wordt getest, bijvoorbeeld het verlies van een database, beschadigde bestanden of de onbeschikbaarheid van een volledige omgeving. Je hoeft niet alle incidenten in één sessie te simuleren. Door het scenario af te bakenen, kun je bepalen welke onderdelen moeten worden hersteld en wat uitdrukkelijk buiten de oefening valt.
Spreek met de business-, technologie- en operationele teams verifieerbare criteria af. Praktische vragen zijn onder meer:
- Welke functies moeten weer beschikbaar zijn en welke kunnen wachten?
- Tot welk moment zouden de gegevens moeten worden hersteld en hoeveel verlies van wijzigingen is aanvaardbaar?
- Hoelang kan de service onderbroken zijn voordat de impact onaanvaardbaar wordt?
- Welke afhankelijkheden maken deel uit van het herstel en welke worden door veilige vervangers nagebootst?
- Wie geeft toestemming voor de uitvoering, valideert het resultaat en meldt problemen?
De recovery point objective (RPO) en recovery time objective (RTO) kunnen helpen om toleranties voor gegevensverlies en onderbreking uit te drukken. Deze moeten worden afgestemd op de behoeften en mogelijkheden van elke service; er bestaat geen universele waarde. Met de test kun je de waargenomen tijden en de staat van de gegevens vergelijken met die doelstellingen, zonder een eenmalig resultaat als garantie voor de toekomst te beschouwen.
Bereid een geïsoleerde en veilige omgeving voor
Voer het herstel uit in een omgeving die gescheiden is van productie, met maatregelen om te voorkomen dat de oefening echte gegevens wijzigt of berichten naar klanten verstuurt. Isoleer netwerken waar mogelijk en blokkeer of vervang integraties die betalingen kunnen uitvoeren, e-mails kunnen versturen, events kunnen publiceren of externe systemen kunnen wijzigen. Informeer de deelnemers dat het om een test gaat.
De herstelde gegevens kunnen gevoelige informatie bevatten. Pas de toepasselijke beleidsregels voor toegang, bewaring en gegevensbescherming toe; beperk wie toegang heeft tot de omgeving en hoelang. Hergebruik geen productiecredentials. Beheer testgeheimen gecontroleerd en controleer dat herstelde bestanden deze niet blootleggen in logs, repositories of publiek toegankelijke mappen.
Leg de uitgangssituatie vast: datum en herstelpunt van de back-up, benodigde code- en configuratieversies, beschikbare resources en verschillen tussen de test- en productieomgeving. Een andere PHP-versie, ontbrekende extensies of afwijkende permissies kunnen het resultaat beïnvloeden. Noteer deze verschillen; verwar ze niet met een geslaagde of mislukte back-up.
Herstel alle benodigde onderdelen
Volg de gedocumenteerde procedure, ook als je een snellere manier kent. Juist daarmee wordt gecontroleerd of de instructies voldoende zijn om iemand anders de service te laten herstellen. Noteer de volgorde en duur van elke stap, handmatige commando’s, genomen beslissingen en alle niet-geplande interventies.
Een mogelijke volgorde, die aan elke architectuur moet worden aangepast, is: herstel de infrastructuur en configuratie, herstel de database en bestanden, implementeer de compatibele codeversie en verbind de benodigde afhankelijkheden. Controleer in PHP, waar relevant, de configuratie van de webserver en PHP-FPM, vereiste extensies, omgevingsvariabelen, schrijfrechten en geplande taken. Controleer ook queues, object storage en workerprocessen als de applicatie daarvan afhankelijk is.
Voer migraties of processen voor het opnieuw opbouwen van gegevens niet automatisch uit zonder te weten wat het effect is op een herstelde back-up. Controleer of de credentials uitsluitend naar testservices verwijzen en of cron-taken geen externe effecten veroorzaken. Als voor het herstel handmatige interventie nodig is, registreer die dan als onderdeel van de werkelijke hersteltijd en als mogelijk verbeterpunt.
Valideer integriteit en gedrag, niet alleen het opstarten
De controles moeten zowel gegevens als functionele workflows omvatten. Begin met technische controles: verbinding met de database, processtatus, beschikbare schijfruimte, foutlogs en reacties van interne services. Valideer vervolgens dat opgeslagen bestanden en verwijzingen met elkaar overeenkomen en dat belangrijke relaties of beperkingen in de database consistent blijven.
Kies representatieve queries en workflows die aansluiten op het daadwerkelijke gebruik van de applicatie. Controleer bijvoorbeeld of een bekende entiteit kan worden gevonden, of je met een testaccount kunt inloggen en of je een bewerking zonder externe effecten kunt voltooien. Als er bestanden zijn geüpload, valideer dan of ze kunnen worden opgehaald en aan hun records kunnen worden gekoppeld. Controleer bij queues of openstaande jobs zich gedragen zoals verwacht en niet per ongeluk twee keer worden verwerkt.
Bewaar voldoende bewijs om de evaluatie te kunnen herhalen: queryresultaten, uitgevoerde stappen, waargenomen fouten en begin- en eindtijd. Alleen ‘het werkt’ registreren is niet genoeg. Leg vooraf vast welke controles nodig zijn om de oefening te laten slagen en welke blokkerend zijn. Een applicatie die reageert maar onvolledige gegevens toont of kritieke bewerkingen niet verwerkt, mag volgens strengere criteria niet als hersteld worden beschouwd.
Meet, verbeter en herhaal met een passende frequentie
Meet de tijd vanaf het afgesproken beginmoment tot het moment waarop aan de herstelcriteria is voldaan, niet alleen de tijd die nodig is om een database te herstellen. Splits, als dat helpt bij de analyse, wachttijd, geautomatiseerd werk, handmatige stappen en validatie uit. Vergelijk het resultaat met de afgesproken doelstellingen en identificeer aannames die niet klopten, zoals niet-beschikbare permissies of verouderde documentatie.
Het rapport moet de reikwijdte, het herstelpunt, het resultaat van elke controle, waargenomen tijden, incidenten, beslissingen en verantwoordelijken voor corrigerende acties bevatten. Geef prioriteit aan maatregelen die blokkades verminderen: automatiseer herhaalbare stappen, werk instructies bij, corrigeer permissies, controleer afhankelijkheden of verbeter de back-upstrategie. Plan opvolgmomenten en herhaal het getroffen onderdeel om te controleren of de correctie het probleem heeft opgelost.
De frequentie hangt af van het risico, architectuurwijzigingen en operationele capaciteit. Je kunt een frequente gedeeltelijke hersteltest — bijvoorbeeld van een database of bestanden — combineren met oefeningen voor volledig herstel en verschillende scenario’s. Het is ook raadzaam de test te herhalen na belangrijke wijzigingen in het back-upsysteem, de infrastructuur of de afhankelijkheden. Een geslaagde test levert bewijs op voor een specifiek scenario en specifieke omstandigheden; het resultaat van alle toekomstige incidenten is er niet mee gegarandeerd.
