Met een back-up kunnen gegevens worden hersteld, maar als u deze rechtstreeks over de actieve database terugzet, kunnen legitieme wijzigingen worden gewist die na de back-updatum zijn aangebracht. Als het probleem één record of een beperkte set records betreft, is het doel doorgaans om de verloren informatie te herstellen en de rest van de huidige status te behouden. Dat vereist dat herstel wordt behandeld als een vergelijkings- en reconciliatiebewerking, niet als een eenvoudige vervanging.
De juiste strategie hangt af van de database-engine, het schema, de beschikbaarheid van auditlogs en de omvang van de schade. In een PHP-applicatie is het verstandig de herstellogica los te koppelen van de productieapplicatie, beslissingen te documenteren en validaties te testen voordat u gegevens schrijft. Als niet kan worden vastgesteld welke wijzigingen veilig zijn, is stoppen en een handmatige reconciliatie voorbereiden doorgaans minder riskant dan een overschrijving automatiseren.
Bepalen wat gegevens herstellen betekent
Bij een volledige restore wordt een database, schema of grote dataset vervangen door de inhoud van een herstelpunt. Bij selectief herstel probeert u daarentegen specifieke rijen of bepaalde waarden terug te zetten zonder de overige actieve gegevens te wijzigen. Beschrijf voordat u kiest nauwkeurig het gewenste resultaat: welke entiteit ontbreekt of is gewijzigd, welke velden moeten worden hersteld en welke latere wijzigingen behouden moeten blijven.
Baken de scope af aan de hand van stabiele identificatoren, zoals de primaire sleutel, en niet alleen met waarden die mogelijk zijn veranderd, zoals de naam of het e-mailadres. Stel ook vast of het incident gerelateerde records raakt: een bestelling kan bijvoorbeeld afhankelijk zijn van regels, betalingen, adressen en statusgebeurtenissen. Alleen de hoofdrecord herstellen kan een inconsistente entiteit opleveren; de hele groep herstellen kan geldige wijzigingen omvatten die niet mogen worden teruggedraaid.
- Leg het symptoom, de geschatte periode en de melder van het probleem vast.
- Identificeer de relevante tabellen, primaire sleutels, foreign keys en beperkingen.
- Bepaal welke velden naar een eerdere waarde moeten worden teruggezet en welke ongewijzigd moeten blijven.
- Bepaal wie de bewerking goedkeurt en welke controles nodig zijn om deze als afgerond te beschouwen.
Een herstelpunt kiezen en de context reconstrueren
Kies een herstelpunt waarmee de vereiste status kan worden gereconstrueerd; dat hoeft niet per se een back-up van vóór de schade te zijn. Afhankelijk van het incident kan het nodig zijn meerdere back-ups, transactielogs en auditgegevens te vergelijken om vast te stellen welke informatie moet worden hersteld en welke latere context behouden moet blijven. Point-in-time recovery kan een tijdelijke database opleveren die bruikbaar is om gegevens uit te halen, maar dat betekent niet dat de volledige inhoud ervan veilig naar productie kan worden overgezet.
Controleer de datum en tijdzone, de dekking van de back-up, het schema waarmee deze is gemaakt en de resultaten van beschikbare integriteitscontroles. Een niet-geverifieerde back-up mag niet standaard als betrouwbare bron worden beschouwd. Controleer ook of identificatoren mogelijk opnieuw zijn gebruikt en of er tijdens het onderzoek processen naar de betreffende tabellen schrijven.
Herstel de back-up naar een geïsoleerde instantie met beperkte toegang en zonder schrijvende verbindingen met productie. De applicatie mag niet per ongeluk naar die instantie verwijzen en er mogen geen geplande taken op worden uitgevoerd. Als de gegevens persoonlijke of gevoelige informatie bevatten, beperk dan de toegang en pas de voor die gegevens bedoelde beschermingsmaatregelen toe. In de geïsoleerde omgeving kunt u statussen vergelijken zonder extra risico voor de actieve database.
Vergelijken zonder aan te nemen dat de back-up de huidige waarheid bevat
Vergelijk kandidaatrijen uit de back-up met de huidige rijen aan de hand van hun stabiele sleutels. Onderscheid per rij drie situaties: de record bestaat niet meer, de record bestaat maar bevat gewijzigde velden, of er zijn geen relevante verschillen. Gebruik bijwerkmarkeringen, gebeurtenisgeschiedenis of auditgegevens om te begrijpen wanneer en waarom de record is gewijzigd. Een tijdstempel alleen bewijst niet welke gebruiker de wijziging heeft aangebracht of dat deze behouden moet blijven.
Bij selectief herstel is één voorzorgsmaatregel essentieel: kopieer niet automatisch een volledige oude rij wanneer sommige velden ervan op geldige wijze zijn gewijzigd. Uit de vergelijking kan bijvoorbeeld blijken dat een record een beschrijvend veld is kwijtgeraakt, terwijl de status, eigenaar of relatie met een andere entiteit later is gewijzigd. Alleen het verloren veld herstellen kan veiliger zijn dan de hele rij vervangen, mits de bedrijfsregels dit toestaan.
Controleer ook op conflicten met unieke waarden, foreign keys, verplichte kolommen, standaardwaarden en regels die door de applicatie worden toegepast. Controleer bij systemen met soft deletes of de record als verwijderd is gemarkeerd in plaats van ontbreekt. Tabellen die deel uitmaken van dezelfde bedrijfsbewerking moeten mogelijk gezamenlijk worden gereconcilieerd om inconsistente saldi, statussen of verwijzingen te voorkomen.
Een beperkte en verifieerbare bewerking uitvoeren
Stel een plan op met de exacte set sleutels en kolommen die worden gewijzigd. Bewaar voordat u het uitvoert een kopie van de huidige status van die rijen of zorg voor een gelijkwaardig terugdraaimechanisme. Test het plan op een recente kopie van de actieve database en vergelijk het resultaat met wat u verwacht. De test moet de werkelijke beperkingen en afhankelijkheden omvatten, niet alleen een import van losse rijen.
Voer de wijzigingen, waar de database-engine en de bewerking dit toelaten, binnen een transactie uit. Een transactie vervangt de controle niet: sommige herstel- of importacties kunnen enginespecifiek gedrag vertonen en externe processen kunnen gegevens gelijktijdig bijwerken. Gebruik voorwaarden die onverwachte wijzigingen tussen de vergelijking en het schrijven detecteren. Komt de rij niet meer overeen met de gecontroleerde status, stop dan de bewerking en analyseer de rij opnieuw in plaats van deze ongemerkt te overschrijven.
In een PHP-applicatie kan een gecontroleerde taak of onderhoudsopdracht invoer valideren, het aantal betrokken sleutels beperken en resultaten vastleggen. Bouw geen SQL-instructies door waarden aan elkaar te plakken. Gebruik geparametriseerde queries en het transactiemechanisme van de data-accesslaag die de applicatie gebruikt. Houd de bewerking buiten openbare routes en zet geen inloggegevens of back-ups in tekstlogs.
Controleer voordat u de wijzigingen bevestigt het aantal gewijzigde rijen, de relevante beperkingen en relaties. Controleer daarna de herstelde waarden en het gedrag van de applicatie bij gerelateerde bedrijfsbewerkingen. Als een validatie mislukt voordat een transactie is bevestigd, draai de transactie dan terug. Als de transactie al is bevestigd of als er onomkeerbare effecten zijn, voer dan niet op eigen initiatief een nieuwe schrijfbewerking uit: activeer eerst het goedgekeurde rollback- of herstelplan en volg de beproefde procedure om de geaccepteerde status terug te zetten en te controleren. Als het plan geen coherente status kan herstellen, stop dan verdere wijzigingen, bewaar bewijsmateriaal en leg de beslissing voor aan de verantwoordelijken.
De beslissing vastleggen en bepalen wanneer automatisering achterwege blijft
Leg het incident, het gebruikte herstelpunt, de onderzochte sleutels, de herstelde velden en de behouden latere wijzigingen vast. Noteer wie de bewerking heeft gecontroleerd en goedgekeurd, wanneer deze is uitgevoerd, welke validaties zijn verricht en wat het resultaat was. Neem geen onnodige gevoelige gegevens op in het logboek. Deze traceerbaarheid maakt het mogelijk de beslissing toe te lichten en ondersteunt later onderzoek.
Kies voor handmatige reconciliatie als betrouwbare sleutels ontbreken, er conflicten zijn tussen bedrijfsbewerkingen, niet kan worden onderscheiden of een wijziging per ongeluk of legitiem is aangebracht, of het herstel relaties raakt waarvan de betekenis afhangt van de context. Een volledige restore kan passend zijn bij uitgebreide corruptie, maar vereist een beoordeling van de impact, onderbreking, het verlies van latere wijzigingen en de herstelprocedure. Kies hier niet alleen voor omdat de uitvoering eenvoudiger is.
- Selectief herstel: de schade is duidelijk afgebakend, de sleutels zijn betrouwbaar en de verschillen kunnen worden geverifieerd.
- Handmatige reconciliatie: er zijn gelijktijdige wijzigingen of bedrijfsregels die menselijk oordeel vereisen.
- Volledige restore: de schade is omvangrijk en er is een goedgekeurd plan om de onbeschikbaarheid en het verlies van wijzigingen te beheren.
Checklist voordat u het herstel afrondt
- Voorbereiding: Zijn de scope, sleutels, afhankelijkheden en verwachte uitkomst vastgesteld? Is een geschikt herstelpunt gekozen en geverifieerd?
- Omgeving en goedkeuring: Is de back-up geïsoleerd teruggezet, is de toegang beperkt en is de procedure getest? Hebben de verantwoordelijken de bewerking en het rollback- of herstelplan goedgekeurd?
- Uitvoering: Is de huidige status van de betrokken rijen bewaard, blijft het schrijven beperkt tot de beoogde sleutels en velden en worden gelijktijdige wijzigingen gedetecteerd?
- Verificatie: Zijn de betrokken rijen, beperkingen, verwijzingen en het bedrijfsproces gecontroleerd? Zijn bij een mislukte controle nieuwe schrijfbewerkingen gestopt en de goedgekeurde procedure geactiveerd?
- Traceerbaarheid: Zijn de beslissing, uitvoering, validaties, behouden wijzigingen en het resultaat vastgelegd, zonder onnodige gevoelige gegevens op te nemen?
Als u de relevante vragen niet bevestigend kunt beantwoorden, stel het schrijven naar productie dan uit. De keuze tussen selectief herstel, handmatige reconciliatie en een volledige restore moet zijn gebaseerd op de omvang van de schade, de betrouwbaarheid van het bewijsmateriaal, de operationele impact en de daadwerkelijke mogelijkheid om een coherente status te herstellen.
