Backups en disaster recovery voor je applicatie

Een backup telt pas als je hem hebt teruggezet. Bepaal daarom per systeem hoeveel data je mag verliezen en hoe lang je plat mag liggen, bewaar kopieën volgens de 3-2-1-regel en test het terugzetten op een vast schema. Voor een database betekent dat meestal point-in-time recovery plus een eigen kopie buiten je cloudaccount.

RPO en RTO in gewone woorden

RPO (recovery point objective) is hoeveel data je kunt missen, uitgedrukt in tijd. Maak je één backup per nacht, dan kun je tot 24 uur aan werk kwijtraken. RTO (recovery time objective) is hoe lang het mag duren tot alles weer draait.

De eigenaar van het product kiest die getallen, het team zegt wat het kost om ze te halen. Per systeem liggen ze anders, bijvoorbeeld:

Hoe kleiner de getallen, hoe duurder de oplossing. Schrijf ze ook op als ze ruim zijn, dan weet iedereen waar hij aan toe is als het misgaat.

De 3-2-1-regel in de cloud

De Amerikaanse cybersecuritydienst CISA beschrijft de 3-2-1-regel zo: houd drie kopieën van belangrijke bestanden (het origineel en twee backups), op twee verschillende soorten media, en bewaar één kopie op een andere locatie.

In de cloud is de tweede soort opslag een andere dienst, bijvoorbeeld object storage naast de snapshots van je database. De andere locatie is een ander account of een andere provider, met eigen inloggegevens.

Dat laatste weegt het zwaarst. Wie bij je productieaccount kan, door een gelekte key of een fout in een script, mag niet ook je backups kunnen wissen. Zet versiebeheer of een retentieslot op de bucket als je opslag dat ondersteunt, zodat een backup een tijd lang niet te verwijderen is. Hoe je die keys zelf beschermt, lees je in secrets en API-keys veilig beheren.

Databases: dumps, snapshots en point-in-time recovery

Voor Postgres heb je twee soorten backups. Een pg_dump is een logische kopie van één moment, handig als extra kopie buiten je account en om een losse tabel terug te halen. Wijzigingen van na dat moment kun je met een dump niet opnieuw afspelen.

Point-in-time recovery werkt met een base backup en de WAL-bestanden die daarna zijn gearchiveerd. Daarmee kun je de database terugzetten naar elk moment sinds die base backup. Je RPO gaat dan van een dag naar minuten of minder, afhankelijk van hoe vaak je WAL archiveert.

Bij een managed database regelt de provider dit meestal. Op Amazon RDS stel je een bewaartermijn in van 0 tot 35 dagen (0 zet automatische backups uit), en binnen die termijn kun je naar elk moment terugzetten. Let wel op bij het verwijderen van de instance: kies je dan niet voor "Retain automated backups", dan verdwijnen de automatische backups met de database mee. Handmatige snapshots blijven wel bestaan.

Mijn advies is om naast de backups van de provider een eigen kopie te houden, bijvoorbeeld een dagelijkse pg_dump naar opslag in een ander account. Dan heb je ook iets als het account zelf het probleem is.

Een backup die niemand terugzet

GitLab publiceerde in 2017 een openbare analyse van een incident op 31 januari. Een engineer verwijderde per ongeluk data op de primaire productiedatabase, terwijl hij die van een replica wilde wissen. Toen bleek dat de backups met pg_dump niet werkten. Ze draaiden met pg_dump 9.2 tegen PostgreSQL 9.6 en faalden daardoor. De mails over die fout werden geweigerd, dus niemand wist het.

GitLab zette uiteindelijk een LVM-snapshot terug die ongeveer zes uur voor het incident was gemaakt. De databasewijzigingen van die uren gingen verloren, en GitLab.com lag ongeveer achttien uur plat.

Ik haal er twee lessen uit. Dat een backupjob geen foutmeldingen stuurt, betekent nog niet dat hij werkt, dus je wilt een seintje als het succesbericht uitblijft. Daarnaast weet je pas of een backup bruikbaar is als je hem hebt teruggezet.

Test je restore op een vast schema

Automatiseer een kleine restoretest. Een nachtelijke job zet de laatste backup terug in een tijdelijke database en controleert een paar dingen:

• of de restore lukt en hoe lang die duurt, vergeleken met je RTO;
• of het nieuwste record niet ouder is dan je RPO toestaat;
• of het aantal rijen in de belangrijkste tabellen ongeveer klopt;
• of je applicatie tegen die database kan opstarten.

Laat de job een signaal sturen als hij slaagt, en laat je monitoring alarm slaan als dat signaal uitblijft. Dan merk je ook dat de job zelf niet meer draait.

Doe daarnaast een of twee keer per jaar een volledige oefening: zet een complete omgeving terug vanuit backups, met iemand aan het stuur die het systeem niet zelf heeft gebouwd. Zo test je ook het runbook. Alles wat die persoon moet navragen, schrijf je er daarna in.

Meer dan alleen de database

Loop na wat je nodig hebt om de hele applicatie opnieuw op te bouwen:

• uploads en andere bestanden in object storage, met versiebeheer aan;
• secrets en configuratie, met een kopie van de vault of een beschreven manier om ze opnieuw aan te maken;
• je infrastructuur als code, zodat je een omgeving kunt neerzetten zonder te klikken;
• DNS-instellingen en certificaten;
• data in SaaS-tools waar je proces op leunt.

Backups kosten opslag, en zonder bewaarbeleid groeien ze elke maand. Spreek af hoe lang je dagelijkse, wekelijkse en maandelijkse kopieën bewaart, en neem dat mee in je maandelijkse kostenreview. Backups bevatten meestal ook persoonsgegevens. Versleutel ze en neem ze mee in je afspraken onder de AVG.

Valt je organisatie onder NIS2, dan is dit geen vrije keuze. De richtlijn noemt backupbeheer en disaster recovery bij de maatregelen voor bedrijfscontinuïteit (artikel 21). Wat NIS2 verder voor je team betekent, staat in NIS2 en je developmentteam.

Bronnen

• CISA: Data Backup Options (pdf)
• PostgreSQL: continuous archiving en point-in-time recovery
• Amazon RDS: introductie tot backups
• Amazon RDS: bewaartermijn van backups
• GitLab: postmortem van de database-uitval van 31 januari 2017
• EUR-Lex: NIS2-richtlijn (EU) 2022/2555