Een back-up heeft alleen zin als het terugzetten lukt

Een ‘restore-first’-aanpak van back-ups voor kleine softwareteams, waarbij aandacht wordt besteed aan hersteldoelen, afhankelijkheden, inloggegevens en realistische verificatie.

Een geslaagde back-uptaak geeft aan dat een proces is voltooid. Het geeft echter geen uitsluitsel over de vraag of de applicatie kan worden hersteld. Dat verschil wordt pijnlijk duidelijk wanneer de oorspronkelijke server niet beschikbaar is en niemand zich meer kan herinneren waar de versleutelingssleutel was opgeslagen.

Voor een klein team wil ik een herstelplan dat een andere technicus onder druk kan volgen. Het plan moet de volgorde van de handelingen beschrijven en aangeven welk bewijs nodig is om de applicatie weer als bruikbaar te kunnen aanmerken.

Begin met twee zakelijke vragen

Hoeveel recente gegevens kan het bedrijf zich veroorloven te verliezen, en hoe lang mag de dienst onbeschikbaar zijn? Die antwoorden bepalen de herstelpunt- en hersteltijddoelstellingen. Hierover moet overeenstemming worden bereikt met de mensen die afhankelijk zijn van de applicatie.

Een dagelijkse databasekopie kan geschikt zijn voor een intern rapportagesysteem, maar onaanvaardbaar voor een druk ordersysteem. Evenzo kan een back-up waarvan het herstel vele uren in beslag neemt, technisch gezien weliswaar in orde zijn, maar toch niet voldoen aan de zakelijke eisen.

Ik noteer de aannames die ten grondslag liggen aan de doelstelling: gegevensvolume, beschikbare infrastructuur, toegang voor de operator en of het herstel bij dezelfde provider plaatsvindt. Een schatting van de hersteltijd die uitgaat van een werkende oorspronkelijke server is niet bruikbaar wanneer die server juist het defecte onderdeel is.

Maak een lijst van alles waarvan de database afhankelijk is

Voor het herstel van een applicatie zijn meestal meer dan alleen tabellen nodig. Geüploade bestanden, versleutelingssleutels, configuratiegegevens, schemamigraties, identiteitsinstellingen en implementatie-artefacten kunnen allemaal nodig zijn om de herstelde gegevens te interpreteren of te gebruiken.

Ik bewaar geheimen apart van gewone applicatiebestanden, maar voor de herstelprocedure is nog steeds een geautoriseerde manier nodig om ze op te halen. „De sleutels zijn veilig” en „de sleutels zijn herstelbaar” zijn twee verschillende eigenschappen.

In de inventaris moeten ook afhankelijkheden worden vastgelegd die niet in een back-up thuishoren, zoals de status van externe betalingen. Na het herstel kan het nodig zijn dat de applicatie haar lokale gegevens met die van een provider afstemt, in plaats van ervan uit te gaan dat beide systemen op hetzelfde moment zijn gestopt.

Terugzetten in een geïsoleerde omgeving

Een test moet worden gestart vanuit de opgeslagen back-up, niet vanuit een handige kopie van de actieve database. Ik wil dat de oefening de toegang, de ontsleuteling, de overdracht, het herstel en het opstarten van de applicatie test.

De herstelde applicatie mag geen e-mails naar klanten versturen, geen daadwerkelijke betalingstransacties uitvoeren en geen uitgaande webhooks opnieuw afspelen. Voordat ik de workers start, schakel ik die integraties uit of vervang ik de inloggegevens ervan door testgegevens. Anders kan een hersteloefening zelf een incident in de productieomgeving veroorzaken.

In de documentatie over SQL-dumps van PostgreSQL worden de werking en beperkingen van logische back-ups uitgelegd. Bij het kiezen van een back-upmethode moet rekening worden gehouden met de omvang van de database en de vereisten voor herstel; een logische dump is niet automatisch de juiste keuze voor elke werklast.

Controleer het gedrag, niet alleen het aantal rijen

Ik gebruik een korte checklist voor herstel op applicatieniveau:

  • Kan een geautoriseerde gebruiker inloggen?
  • Kan de applicatie representatieve recente en oudere gegevens lezen?
  • Komen de geüploade bestanden en de bijbehorende databaseverwijzingen met elkaar overeen?
  • Kan een testtransactie veilig worden voltooid?
  • Zijn de achtergrondprocessen klaar zonder dat er onbedoelde historische bewerkingen worden uitgevoerd?
  • Blijven de grenzen van de tenant na het herstel behouden?

Tellingen en controlesommen helpen bij het opsporen van ontbrekende gegevens, maar ze bewijzen niet dat de applicatie naar behoren functioneert. Ik noteer ook de daadwerkelijke duur van het herstel en in welke gevallen de operator op niet-gedocumenteerde kennis moest terugvallen.

Maak van verrassingen onderhoudswerkzaamheden

Een test waarbij een probleem aan het licht komt, heeft zijn doel bereikt. Het is goedkoper om ontbrekende machtigingen, verouderde instructies en incompatibele applicatieversies op te sporen zolang de productieomgeving nog goed functioneert.

Ik werk het runbook onmiddellijk bij en herhaal vervolgens het deel dat is mislukt. Het verslag moet de back-up-ID, de applicatieversie, de herstelomgeving, het resultaat en de resterende hiaten bevatten.

Mijn vertrouwen in een back-up is gebaseerd op een recente, herhaalbare herstelbewerking. De geplande taak zorgt voor het materiaal; de proef laat zien of het team dat materiaal weer tot een dienst kan omzetten.

Bijgewerkt op 25 september 2026.