Begrijpen van de doelstelling voor hersteltijd bij de planning van herstel na een ramp

Het instellen van uw recovery time objective (RTO) is cruciaal, vooral nu netwerkhacks en ransomware-aanvallen toenemen. U weet nooit wanneer u het volgende slachtoffer bent. Als uw RTO op dit moment niet is gedefinieerd, hoe zou u dan een back-up- en herstelplan voor uw gegevens opstellen?

In dit bericht wordt de doelstelling voor hersteltijd gedefinieerd en worden de factoren besproken waarmee u rekening moet houden bij het instellen van uw RTO.

Wat is de hersteltijddoelstelling?

Recovery time objective is een metriek die wordt gebruikt bij disaster recovery en business continuity planning. Het is de maximale duur dat een applicatie, netwerk, systeem of computer down kan zijn nadat een ramp of storing heeft plaatsgevonden voordat een organisatie aanzienlijke schade oploopt. Factoren zoals omzetverlies en een verstoring van de business continuity kunnen RTO beïnvloeden. RTO's variëren sterk, afhankelijk van de betrokken systemen en processen.

RTO-tijd geeft de tijd aan die nodig is om het systeemherstel van een defect systeem te herstellen en af ​​te ronden, zoals gedefinieerd in de service level agreement. De service level objective houdt rekening met de hersteltijd die de organisatie heeft ingesteld om haar bedrijfskritische IT-processen of -activiteiten te herstellen of te herstellen naar normaal vanaf het moment dat er een ramp plaatsvindt om de bedrijfscontinuïteit te waarborgen.

Pro Tip: U moet altijd streven naar de laagst mogelijke RTO om de impact van een ramp te minimaliseren. Om uw RTO te bepalen, moet u eerst het effect identificeren van de duur van de duur op uw bedrijf waarin de gegevens niet beschikbaar zijn.

Bijvoorbeeld:

• Als 10% van de gegevens binnen 24 uur beschikbaar moet zijn,
• En na een volledig verlies van de database moet 50% van de gegevens binnen 2 dagen beschikbaar zijn,
• De resterende 40% van de gegevens moet binnen de komende 5 dagen beschikbaar zijn.

Uw totale RTO is = 8 dagen.

Om nog een voorbeeld te noemen:

Stel dat de Exchange-server down is. Als uw RTO op vijf uur staat, kan uw organisatie downtime van vijf uur tolereren en zou de RTO van uw Exchange-server minder dan vijf uur moeten zijn. Uw disaster recovery-beleid moet de noodzakelijke stappen bevatten die de IT-afdeling neemt om een ​​back-up te maken van de gegevens en deze te herstellen.

Hersteltijddoelstellingen kunnen worden ingesteld om gegevens te herstellen, er is geen universele oplossing voor een bedrijfs continuiteits plan. RTO's kunnen worden ingesteld om gegevens te herstellen na een ramp. Mocht er zich echter een incident voordoen, dan zijn de praktische aspecten van uw noodherstelplan ook afhankelijk van de specifieke tools en technologie die worden gebruikt om herstel mogelijk te maken. Dus de mogelijkheid om RTO te bereiken varieert naarmate verschillende technologieën en DR-tools variëren in hun mogelijkheden. RTO wordt gemeten nog voordat de storing is begonnen en omvat de tijd die nodig is om de servers te repareren, prioriteitsapplicaties te installeren en gegevens te herstellen. Het bevat ook de herstelmethoden en de back-upgegevens die moeten worden hersteld.

Wat bepaalt RTO?

RTO is een beoogde duurtijd waarin applicaties, systemen en/of processen downtime overleven en niet meer functioneren voordat de verstoring begint. De RTO is van het grootste belang om de tijdsduur te bepalen om applicaties en processen binnen de RTO-parameters te prioriteren. In het gegevensbeschermingsplan en de strategie voor noodherstel beantwoordt RTO de vraag: "Wat is de beoogde tijd die is vastgesteld voor serviceherstel na een melding van een serviceonderbreking?"

RTO's kunnen bepalen:

• De tijd die nodig is om een ​​site in realtime te herstellen - vanaf het moment dat een incident optreedt totdat de activiteiten zijn hersteld
• Welke IT-voorbereidingen moeten worden ontworpen voor de uitvoering van het rampenherstelplan?
• Het niveau van gegevensverlies dat acceptabel is wanneer het systeem of de belangrijkste applicaties uitvallen

Hoe bereken je de RTO voor de planning van noodherstel?

Een RTO-metriek stelt vooraf de doelverwachting voor het IT-team vast, omdat het de drempelwaarde bepaalt voor hoe snel het systeem of de applicatie kan worden hersteld na de downtime en uw systeem weer online kan worden gebracht. Nadat u deze meting hebt gedefinieerd in termen van de hoeveelheid "real-time" om het systeem te herstellen, kunt u uw herstelstrategie plannen om de service weer operationeel te krijgen. Om RTO te berekenen, moet u rekening houden met de verliezen die gepaard gaan met een onderbreking in de (BCP) Business Continuity RTO. Neem ook een impactanalyse op die de kortetermijn- of langetermijneffecten van bedrijfsonderbreking van services verklaart. Dit omvat risico's, verloren inkomsten, kosten, klantgerichte applicaties, bedrijfskritische applicaties en minder prioritaire applicaties die worden beïnvloed of niet meer beschikbaar zullen zijn. RTO houdt zich meer bezig met de downtime en tijdsbeperkingen voor het gegevensherstelproces.

Om een ​​RTO uit te werken, hebt u mogelijk meerdere RTO-categorieën nodig, omdat bepaalde storingen mogelijk niet veel hersteltijd vergen, terwijl andere mogelijk andere langetermijnbeschermingsoplossingen vereisen. De RTO kan bijvoorbeeld veel langer zijn voor minder bedrijfskritieke toepassingen (niet vaak gebruikt). Op basis van de complexiteit van meerdere beveiligingssystemen die in bedrijf zijn, moet u de RTO mogelijk instellen op basis van back-ups met korte en lange intervallen. Dit kan gebeuren als gevolg van een ransomware-gebeurtenis of een ander grootschalig catastrofe-incident.

Belangrijke factoren om te overwegen bij het berekenen van RTO

• Kosten-batenvergelijking voor hersteloplossingen
• Prioritaire toepassingen van individuele systemen en gegevens
• Door de IT-afdeling te nemen stappen op basis van de processen, geautomatiseerde technieken of technologieën om de IT-infrastructuur te herstellen
• Storings- en beperkingskosten
• De complexiteit van de invorderingsprocedure 

RTO-monsterintervallen

Het bereiken van een RTO van bijna nul is kostbaar voor de meeste IT-ondernemingen, maar het is mogelijk om dit te bereiken als u prioriteit geeft aan applicaties en gegevens. Voor minder bedrijfskritieke toepassingen kan de RTO-klok langere objectieve tijden in beslag nemen dan normaal. Bij bijna-nul RTO-plannen voor bedrijfskritieke toepassingen moet u mogelijk onmiddellijke failover-mogelijkheden overwegen. 

Afhankelijk van de ernst van de storing kunt u de haalbare doel-RTO-tijd instellen. De hersteltijd van de RTO is echter ook afhankelijk van de beperkingen van de IT-organisatie. Als het herstellen van alle IT-functies en bewerkingen bijvoorbeeld 3 uur duurt, moet de RTO minimaal 3 uur zijn.

Note: Vanuit het perspectief van noodherstel (DR) begint de RTO-klok precies wanneer de herstelprocessen beginnen.

Wanneer u de RTO voor uw bedrijfseenheden berekent, kunt u de volgende voorbeeldintervallen gebruiken:

Een uur

Dit interval is voor redundante gegevensback-up op externe harde schijven.

Vijf dagen

In dit geval zou de meest kosteneffectieve oplossing het maken van een back-up van gegevens zijn met behulp van een compact disk, tape of externe schijfopslag.

Bereik RTO, op de Zmanda manier

RTO en Herstelpuntdoelstelling (RPO) zijn ongelooflijk belangrijke doelen en vormen de basis van een herstelplan. Hoe bepaal je de reeks stappen van praktische hersteldoelen? Dit is waar we kunnen helpen!

met Het DRaaS-plan van Zmanda en aangepaste service level agreements, ongeacht de omvang van uw bedrijf, kunnen we u helpen de uitvaltijden te verkorten en de pijn van downtime te vermijden, afhankelijk van uw bedrijfsbehoeften. Naast hybride back-ups om de overgang te ondersteunen en relatief snellere RTO's te bereiken, combineert onze enterprise-oplossing Amazon Glacier met 20x lagere kosten voor langetermijngegevensarchivering die een robuuste hoge beschikbaarheid implementeert en bedrijfscontinuïteit garandeert. 

Wij stemmen onze enterprise back-upoplossing af op uw vereisten en bieden een product dat back-upprocessen, datacontinuïteit en archivering van langetermijnopslag integreert. Krijg de betrouwbaarheid en beveiliging die u nodig hebt wanneer het onverwachte gebeurt, zelfs in het geval van een totale serverstoring.

Wilt u Zmanda Pro zelf uitproberen?

Ontdek hoe Zmanda Pro u kan helpen uitvaltijden te verkorten en downtime te voorkomen. Meld u aan voor een gratis proefperiode van Zmanda Pro en strategiseer uw hersteltijddoelstellingen. Tijdens de proefperiode van 14 dagen hebt u volledige toegang tot alle functies en houden we u op de hoogte van de status van uw proefperiode. Als u vragen hebt over onze oplossingen, neem contact op met onze experts.