Back-ups verifiëren in PHP-applicaties

Een back-up biedt alleen bescherming als hiermee een dienst naar een bekende staat kan worden hersteld, binnen een aanvaardbare tijd en zonder nieuwe fouten te introduceren. Dat een back-upbestand bestaat, zonder waarschuwingen is aangemaakt of naar andere opslag is verzonden, bewijst niet dat het kan worden hersteld, alle benodigde onderdelen bevat of dat de PHP-applicatie met die gegevens werkt.

De vraag hoe back-ups in PHP-applicaties te controleren moet worden beantwoord met herhaalbare hersteltests. Het doel is niet alleen een database te herstellen: het is een coherente dienst opnieuw op te bouwen, de bedrijfsregels te verifiëren en bewijs te bewaren waarmee de procedure vóór een werkelijk incident kan worden verbeterd.

Een bestaande back-up garandeert niet dat herstel mogelijk is

Herstelfouten ontstaan vaak door weggelaten afhankelijkheden. Een database kan correct worden hersteld, waarna blijkt dat door gebruikers geüploade bestanden, sleutels om informatie te ontsleutelen, omgevingsvariabelen of configuraties van externe diensten ontbreken. Het kan ook gebeuren dat de back-up corrupt is, dat het technische account geen rechten heeft om deze te herstellen of dat de indeling ervan niet compatibel is met de doelinfrastructuur.

Het is raadzaam twee operationele doelstellingen te onderscheiden:

• Recovery Point Objective (RPO): maximale hoeveelheid gegevensverlies die wordt aanvaard, gemeten vanaf de laatste herstelbare staat.
• Recovery Time Objective (RTO): maximaal aanvaardbare tijd om de dienst weer operationeel te maken.

Beide doelstellingen bepalen de frequentie van back-ups, de retentie, het gebruik van transactielogs en de opzet van de tests. Een nachtelijke back-up kan voldoende zijn voor een weinig veranderende catalogus, maar niet voor transacties waarvoor naar een tijdstip dicht bij het incident moet worden teruggekeerd. In dat laatste geval moet het plan voorzien in herstel naar een specifiek tijdstip, als de datatechnologie en de configuratie daarvan dit toelaten.

Stel een herstelbare inventaris op, niet alleen een data-export

De inventaris moet beschrijven welke elementen de minimale staat van de applicatie vormen en waar hiervan back-ups worden gemaakt. In een PHP-applicatie staat de database doorgaans centraal, maar is die zelden het enige persistente onderdeel.

• Transactiegegevens: relationele databases, documenten, relevante migratiebestanden en, indien van toepassing, logs die nodig zijn voor herstel naar een specifiek tijdstip.
• Persistente bestanden: bijlagen, afbeeldingen, exports, gegenereerde documenten en alle inhoud die buiten de database wordt opgeslagen.
• Configuratie: runtimeparameters, domeinen, opslagpaden, mailconfiguratie, betaaldiensten en verbindingen met API's. Geversioneerde code helpt, maar vervangt de operationele configuratie niet.
• Geheime gegevens: encryptiesleutels, inloggegevens, certificaten, tokens en sessiegeheimen. Deze moeten via een gecontroleerd mechanisme worden hersteld, niet in rapporten of repositories worden gekopieerd.
• Asynchrone verwerking: wachtrijen, geplande taken, verwerkers en herhalingsbeleid. Er moet worden besloten of openstaande berichten worden hersteld, opgeschoond of veilig opnieuw worden opgebouwd.
• Afgeleide gegevens: caches, zoekindexen, gematerialiseerde weergaven, miniaturen of aggregaten. Meestal zijn dit niet de gezaghebbende bron, maar het opnieuw opbouwen ervan kan nodig zijn voordat de dienst operationeel is.

Documenteer voor elk element de eigenaar, locatie, herstelmethode, afhankelijkheden en gevoeligheid. Als geheime gegevens niet gecontroleerd kunnen worden hersteld of geroteerd, is de procedure niet volledig.

Definieer scenario's en kies het herstelpunt

Niet alle incidenten vereisen dezelfde reactie. Een per ongeluk verwijderd record, massale corruptie, een kwetsbaarheid die gegevens heeft gewijzigd en een volledige uitval van de omgeving vereisen verschillende procedures. Door scenario's te definiëren voorkomt u dat een volledig herstel wordt uitgevoerd terwijl een beperkte correctie zou volstaan, of dat besmette gegevens worden hersteld door een punt na het probleem te kiezen.

Scenario's die moeten worden getest

• Herstel van een record of beperkte gegevensset via export, audit of herstel in een tijdelijke instantie.
• Herstel van een volledige database vanuit een consistente back-up.
• Herstel naar een moment vóór het incident via transactielogs, wanneer die mogelijkheid bestaat.
• Herstel van een volledige dienst: gegevens, bestanden, configuratie, geheime gegevens, applicatie en ondersteunende processen.
• Opnieuw opbouwen van indexen, caches en andere afgeleide gegevens zonder de gezaghebbende bron te wijzigen.

Leg vóór het herstel het beoogde herstelpunt vast en registreer het aanvaarde gegevensverlies. Als bijvoorbeeld een back-up van 02:00 wordt hersteld, kan voor elke latere bewerking afstemming met andere legitieme bronnen nodig zijn, zoals betalingslogs of systemen van derden. Die staat mag niet worden gepresenteerd alsof deze transacties bevat die er niet in staan.

Hanteer een herstelvolgorde die neveneffecten beperkt

Een gecontroleerd herstel vereist isolatie en een duidelijke volgorde. De testomgeving mag geen echte e-mails versturen, betalingen uitvoeren, productie-integraties aanroepen of wachtrijen delen met de actieve dienst. Gebruik voor die test veilige inloggegevens en bestemmingen.

1. Bereid de doelinfrastructuur voor: netwerk, opslag, versie van de data-engine, rechten en voldoende capaciteit.
2. Herstel of richt de configuratie en geheime gegevens in via het geautoriseerde kanaal. Verifieer dat de vereiste encryptiesleutels overeenkomen met de staat van de herstelde gegevens.
3. Herstel de database en de persistente bestanden. Noteer tijdstempels, back-upidentificaties en gebruikte commando's of taken.
4. Breng de compatibele applicatieversie uit. De uitrol installeert het softwareartefact; dit betekent op zichzelf niet dat het voor gebruikers beschikbaar wordt gemaakt.
5. Voer migraties alleen uit als ze door het scenario worden gerechtvaardigd. Een onomkeerbare migratie kan vergelijking met de oorspronkelijke staat bemoeilijken of de herstelde gegevens onterecht wijzigen.
6. Houd verwerkers, geplande taken en integraties met extern effect uitgeschakeld totdat de validaties zijn voltooid.
7. Bouw afgeleide gegevens opnieuw op en activeer processen geleidelijk, waarbij duplicaten, fouten en herhalingen worden bewaakt.

Wachtrijen vereisen bijzondere aandacht. Een verwerker opnieuw activeren vóór de staat is gevalideerd, kan dubbele meldingen versturen, bewerkingen herhalen of berichten verwerken die niet langer bij de herstelde gegevens passen. Het beleid moet bepalen welke berichten worden bewaard, welke worden verwijderd en hoe dubbele uitvoering wordt voorkomen.

Valideer de technische consistentie en de bedrijfsconsistentie

Dat een applicatie HTTP 200 retourneert, bewijst niet dat deze herstelbaar is. De controles moeten technische integriteit, functioneel gedrag en domeinrestricties combineren. Automatiseer de stabiele validaties zodat ze na elke test kunnen worden herhaald.

• Vergelijk aantallen relevante entiteiten met de verwachte waarden voor het herstelpunt: gebruikers, bestellingen, facturen, bestanden of gebeurtenissen.
• Zoek naar gebroken verwijzingen tussen database en objectopslag: records die naar ontbrekende bestanden verwijzen, of bestanden zonder bekende eigenaar.
• Controleer restricties, relaties, codering, tijdzones en identifiersequenties wanneer deze nieuwe schrijfbewerkingen beïnvloeden.
• Voer functionele flows uit met een testaccount: authenticatie, gegevens lezen, gecontroleerd een record aanmaken en toegang tot een beveiligd bestand.
• Verifieer rollen en rechten. Onjuist herstelde geheime gegevens kunnen toegang verhinderen of, erger nog, privileges uitbreiden.
• Controleer openstaande, mislukte of geblokkeerde taken en zorg dat hervatting ervan geen onterechte externe acties veroorzaakt.

Applicatietests moeten passend beschermde gegevens gebruiken. Als persoonsgegevens naar een geïsoleerde omgeving worden gekopieerd, pas dan de toepasselijke toegangs-, retentie- en minimalisatiecontroles toe. Gebruik waar mogelijk gemaskeerde gegevens voor validaties waarvoor geen identificeerbare informatie nodig is.

Behandel caches, indexen en afgeleide gegevens als opnieuw op te bouwen onderdelen

Een cache mag niet de enige locatie zijn van informatie die nodig is om de dienst te herstellen. Invalideer na herstel van de gezaghebbende bron caches die waarden van vóór het herstelde punt kunnen bevatten. Laat ze vervolgens gecontroleerd opwarmen of voer een expliciete generatie uit als die bestaat.

Zoekindexen en andere afgeleide gegevensopslagplaatsen moeten als zodanig worden geïdentificeerd voordat ze worden verwijderd of opnieuw gegenereerd. De heropbouw moet uitgaan van de herstelde gegevens en verifieerbare meetwaarden opleveren: aantal geïndexeerde documenten, fouten, openstaande elementen en controlequery's. Als een index gevoelige velden opslaat, maken ook de rechten en het retentiebeleid daarvan deel uit van de validatie.

Maak van elke test operationeel bewijs

Een herstel in een geïsoleerde omgeving testen moet een geplande activiteit zijn, geen improvisatie tijdens een crisis. Wijs verantwoordelijken aan om uit te voeren, te observeren, de bedrijfswerking te valideren en wijzigingen aan de procedure te autoriseren. Meet werkelijke tijden per fase in plaats van schattingen.

Bewaar na elke oefening beknopt en bruikbaar bewijs:

• getest scenario, datum, verantwoordelijke en gekozen herstelpunt;
• identificatie en ouderdom van elke gebruikte back-up;
• relevante versies en configuratie van het doel, zonder geheime gegevens bloot te leggen;
• waargenomen tijd voor herstellen, valideren en opnieuw opbouwen van afgeleide gegevens;
• resultaat van consistentiecontroles en functionele tests;
• incidenten, genomen beslissingen, aanvaard gegevensverlies en corrigerende acties.

Herzie de procedure wanneer het dataschema, de bestandsopslag, de geheime gegevens, de integraties, de architectuur van wachtrijen of het uitrolproces veranderen. Historisch bewijs maakt het mogelijk vast te stellen dat de RTO niet langer wordt gehaald, dat een back-up geen onderdeel meer bevat of dat een afhankelijkheid handmatig is geworden.

Fouten die een back-upstrategie ongeldig maken

Alleen de database herstellen is de meest zichtbare fout, maar niet de enige. Veelvoorkomende risico's zijn ook niet verifiëren dat de back-up correct wordt voltooid, afhankelijk zijn van één locatie, herstel naar een specifiek tijdstip niet controleren, omgevingen mengen, rechten van het herstellende account weglaten en de procedure slechts in de kennis van één persoon laten bestaan.

De oplossing is niet om zonder criterium meer back-ups te verzamelen, maar om herstelbare staten te definiëren, een herstel te isoleren, gegevens en processen te valideren, het resultaat te meten en het plan bij te werken. Zo zijn back-ups niet langer een operationele belofte, maar een aantoonbaar vermogen om de dienst te herstellen.