• Auteur: root
  • Datum: 4-02-2019

In geval er een incident in de ICT infrastructuur plaatsvindt en data is verdwenen en teruggehaald moet worden uit een backup, dient er een Disaster Recovery Plan klaar te liggen welke gevolgd dient te worden. In een disaster recovery plan dient aangegeven te worden hoe lang het kan duren voordat de situatie hersteld is en hoeveel data daarbij mogelijk verdwenen kan zijn. Dit wordt samen gevat in zgn. RPO en RTO objectives:

RTO Recovery Time Objective

Kortweg wordt hiermee aangeduid hoe lang het kan (of mag) duren om de situatie vanuit de backup of een failover systeem weer online te krijgen. Dit kan variëren van de tijd die benodigd is om handmatig een database slave als master te promoten, tot de tijd die nodig is om hardware te vervangen. In het eerste geval kan de RTO kort zijn, mogelijk binnen een half uur, in het laatste geval kan de RTO zelfs dagen in beslag nemen. Vooral als er naar klanten toe een SLA (Service Level Agreement) wordt afgegeven, is het goed om van een worst-case scenario uit te gaan.

RPO Recovery Point Objective

Hiermee wordt aangegeven hoeveel data er verloren kan (of mag) gaan bij een disaster. Meestal is het maximum de interval tussen backup, replicatie of synchronisatie. Toch kun je hiermee voor een verrassing komen te staan.


Voorbeeld

Stel, je maakt 1x per dag een backup van alle data. Dan ben je geneigd te denken dat je RPO in een worst-case scenario maximaal 24 uur is. Meestal is dat zo, maar wat als het incident zich binnen de backup cyclus voordoet en de backup op dat moment corrupt is.  Een wekelijkse full-backup kan uren duren (we hebben voorbeelden van volledige server backups die 12 uur of meer in beslag nemen). Als aan het einde van de backup zich een ernstige server crash, een disaster, voordoet, dan is naar verwachting de laatste full-backup corrupt geraakt en kan niet voor de restore gebruikt worden. In dat geval zal naar de voorlaatste, incrementele, backups worden teruggegrepen tot aan de vorige volledige server backup.

Dit is niet alleen van invloed op je RPO, je bent mogelijk tussen de 24 en 36 uur aan data kwijt, maar ook op je RTO, de restore vanuit incrementele backups kan veel langer duren van vanuit één full-backup.

Houd rekening met een worst-case scenario

Houd met het maken van een disaster recovery plan dus altijd rekening met een worst-case scenario. Hardware kan kapot gaan, de backup kan niet beschikbaar zijn, de vervangende server kan langzamer zijn, een restore van data overdag kan langer duren dan een backup ‘s nachts enz.

Rekening houden met worst-case scenario’s kan de pijnlijke plekken binnen je ict infrastructuur blootleggen en je helpen deze zo in te richten dat de gewenste RPO en RTO in geval van een disaster ook werkelijk gehaald kunnen worden.  Zoals wel vaker het geval is geldt hier ook: hoe korter de RPO en RTO, hoe duurder je ict oplossing wordt.

Bij Root helpen we onze klanten graag het bepalen van een acceptabele RPO en RTO en het opstellen van een disaster recovery plan.

Neem contact op met
een van onze specialisten