Gids
Hoe test u een restore? RTO en RPO in de praktijk
Een backup die nooit teruggezet is, is een hoop. Wat RTO en RPO betekenen, de vier niveaus waarop u herstel kunt testen, hoe vaak, en hoe u de resultaten zo vastlegt dat ze als bewijs tellen.
Twee letters die uw nacht bepalen
RPO, recovery point objective: hoeveel data mag u maximaal kwijt zijn? Een nachtelijke backup geeft een RPO van 24 uur: een ramp om 16u betekent de hele werkdag opnieuw. Voor een boekhouding is dat vervelend, voor een webshop onbetaalbaar.
RTO, recovery time objective: hoe lang mag het duren voor alles weer draait? Niet het moment waarop de backup "gedownload" is, maar het moment waarop uw mensen weer kunnen werken.
Beide getallen staan vaak in een beleidsdocument. Veel minder vaak zijn ze gemeten. En een geschatte RTO is een gok.
Waarom backups in de praktijk mislukken bij een restore
- De backup liep, maar het pad was leeg of een databank werd overgeslagen.
- De repository leek gezond op de bronserver, maar is onleesbaar op een verse machine omdat de lokale cache alles maskeerde.
- De dump is er, maar niemand heeft ooit geprobeerd hem in te laden in een nieuwe databankversie.
- De sleutel staat op de server die net versleuteld is.
- Het terugzetten van 600 GB over een verbinding met uitgaande kosten en 100 Mbit duurt drie dagen, en kost geld dat niemand gebudgetteerd had.
Elk van die problemen komt pas aan het licht als u het echt probeert. Daarom test u.
Vier niveaus van testen
Niet elke test hoeft volledig te zijn. Zekura gebruikt vier niveaus, elk met een eigen frequentie, en dat model werkt ook los van Zekura:
| Niveau | Wat | Vraag die beantwoord wordt | Hoe vaak |
|---|---|---|---|
| L1 Integriteit | elk object van de snapshot teruglezen op een aparte machine, met lege cache, alle checksums controleren | Is alles er, en leesbaar vanaf nul? | na elke backup |
| L2 Steekproef | een steekproef van bestanden terugzetten en per sha256 vergelijken met het origineel | Komt wat terugkomt overeen met wat er stond? | dagelijks |
| L3 Toepassing | de databank laden in een wegwerp-instantie en natellen; de toepassing opstarten; een healthcheck draaien | Werkt het, niet alleen zijn de bytes juist? | wekelijks |
| L4 Opstarten | een volledige VM terugzetten en opstarten tot de guest agent antwoordt, en de tijd meten | Hoe lang duurt het echt tot het draait? | maandelijks |
De lege cache in L1 is geen detail. Een restore gebeurt altijd op een machine die de data nog niet kent. Testen vanaf de bron bewijst daar niets over.
Hoe u RTO écht meet
Meet het hele traject: van het moment dat u beslist te herstellen tot het moment dat de toepassing antwoordt. Noteer per systeem:
- de duur van de terugzetting (bytes per seconde zegt meer dan u denkt over uw netwerk en uw opslagaanbieder);
- de tijd om een databank op te starten en te controleren;
- de tijd om toegang te herstellen (DNS, certificaten, wachtwoorden die in de backup zaten).
Zekura noteert bij elke restore en elke proefrestore de gemeten duur en zet die in de bewijsketen. Het overzicht toont altijd het laatste bewezen herstel met zijn tijd: "9 seconden" of "11 minuten 42 seconden" is een feit dat een auditor kan controleren, "ongeveer een uur" niet.
Hoe u RPO verkleint zonder elk uur een volledige backup
Voor databanken bestaat point-in-time recovery: een wekelijkse basisbackup plus een continue stroom van wijzigingen (de write-ahead log bij PostgreSQL, de logbackups bij SQL Server). Het interval waarmee die log vertrekt, is uw RPO: elke vijf minuten geeft hooguit vijf minuten verlies. En u kunt terug naar elk tijdstip, ook naar 14u06, net vóór iemand de verkeerde tabel leegmaakte.
Testresultaten die als bewijs tellen
Een test die in een spreadsheet "ok" krijgt, is voor een auditor weinig waard. Wat telt:
- Wie of wat de test deed, en op welke machine (niet de bronserver).
- Wanneer, met een tijdstempel die niet achteraf aangepast kan zijn.
- Wat er precies gecontroleerd is: aantal objecten, aantal bestanden, rijentellingen.
- Het resultaat, inclusief de mislukkingen. Een register dat alleen successen bevat, is verdacht.
- De samenhang: elke test verwijst naar de backup waarop ze sloeg.
Bij Zekura komt elke verificatie ondertekend in de bewijsketen, met het bewijsmateriaal erbij. Mislukte verificaties ook; het register verzwijgt niets.
Een testplan voor een KMO
- Dagelijks, automatisch: integriteit van elke backup, steekproef van bestanden.
- Wekelijks, automatisch: één databank en één toepassing volledig terugzetten en controleren.
- Maandelijks, automatisch: één VM opstarten vanaf backup.
- Per kwartaal, met mensen: een begeleide hersteloefening van één scenario (ransomware, brand, fout van een medewerker), met een verslag. De SLA Business van Zekura bevat zo'n oefening elk kwartaal.
- Jaarlijks: de sleutel testen. Zonder sleutel is elke andere test zinloos.
Veelgestelde vragen
Is een proefrestore niet gevaarlijk voor productie?
Alleen als u over productie heen zet. Test altijd naar een aparte machine of een wegwerp-instantie. Zekura zet nooit over het origineel tenzij u dat expliciet vraagt.
Kost testen veel opslagverkeer?
Bij aanbieders die uitgaand verkeer aanrekenen wel, en dat is precies waarom er daar zo weinig getest wordt. Kies opslag zonder egress-kosten; Zekura gebruikt daarom Cubixion.
Wat is een goede RTO voor een KMO?
Die vraag beantwoordt u per systeem met uw mensen: wat kost een uur stilstand van de webshop, van de boekhouding, van de mail? Meet daarna of u het haalt. Vaak blijkt de werkelijke RTO een veelvoud van de geschatte.