Att ställa in dina mål för återställningstiden är avgörande, särskilt när nätverkshackar och ransomware -attacker ökar. Du vet aldrig när du är nästa offer. Om ditt mål för återhämtningstid inte är definierat vid denna tidpunkt, hur skulle du komma med en data -backup och återställningsplan?
Det här inlägget kommer att leda dig igenom grunderna i RTO och de faktorer du bör tänka på när du ställer in din RTO.
Vad är målet för återhämtningstid?
Recovery Time Objective (RTO) definieras som den maximala acceptabla tiden som en applikation kan vara nere eller det maximala tolerabla avbrottet som organisationen utsätts för utan att orsaka betydande skada på ett företag efter en katastrof, misslyckande eller någon oacceptabel händelse inträffar.
RTO-tid antyder den tid det tar att återställa och slutföra systemåterställning av ett misslyckat system enligt definitionen i servicenivåavtalet. Servicenivåmålet står för den återhämtningstid som organisationen ställt in för att återställa/återställa dess verksamhetskritiska IT-processer/drift till det normala från det att en katastrof inträffar för att säkerställa kontinuitet i verksamheten.
Proffstips: Du bör alltid sträva efter att uppnå lägsta möjliga RTO för att minimera konsekvenserna av en katastrof. För att fastställa din RTO måste du först identifiera effekten av varaktigheten på din verksamhet där data inte är tillgänglig.
Till exempel:
- Om 10 % av data måste vara tillgänglig inom 24 timmar,
- Och efter en fullständig förlust av databasen måste 50 % av data vara tillgänglig inom 2 dagar,
- De återstående 40 % av data måste vara tillgängliga inom de närmaste 5 dagarna, då
Din totala RTO är = 8 dagar.
För att nämna ett annat exempel:
Anta att Exchange-servern är nere. Om din RTO är på 5 timmar, är den maximala tolererbara driftstopptiden som ditt företag kan överleva 5 timmar, och din RTO för Exchange Server måste vara mindre än 5 timmar. Din återställningspolicy måste innehålla de nödvändiga åtgärder som vidtagits av IT-avdelningen för att säkerhetskopiera och återställa data.
Därför, samtidigt som man ställer in målet för tiden till återhämtning, finns det ingen enstaka lösning för en kontinuitetsplan. RTO:er kan ställas in för att återställa data efter en katastrof. Men om en incident skulle inträffa beror de praktiska funktionerna i din katastrofåterställningsplan också på specifika verktyg och teknik som används för att ge återhämtning. Så, möjligheten att träffa RTO varierar eftersom olika tekniker och DR-verktyg varierar i deras kapacitet. RTO mäts redan innan avbrottet har börjat och inkluderar den tid det tar att reparera servrarna, installera prioriterade applikationer och återställa data. Det inkluderar också metoderna för återställning och säkerhetskopierade data som behöver återställas.
Vad bestämmer RTO?
Återställningstidsmålet är en avsedd varaktighetstid där applikationer, system och/eller processer överlever driftstopp och inte fungerar innan avbrottet börjar. RTO är av största vikt för att bestämma hur lång tid det tar att prioritera applikationer och processer inom RTO-parametrarna. I dataskyddsplanen och katastrofåterställningsstrategin svarar RTO på frågan "vilken måltid är fastställd för återställning av tjänster efter ett meddelande om tjänstavbrott?"
RTO:er kan bestämma:
- Den varaktighet i realtid som ska ställas in för att återställa en plats från den tidpunkt då incidenten avbryter det normala operationsflödet tills det återställs
- Vilka IT-förberedelser som bör utformas för att implementera katastrofåterställningsplanen
- Den acceptabla risknivån för dataförlust när systemet eller viktiga applikationer går offline.
Hur beräknar man RTO för planering av katastrofåterställning?
Ett RTO-mått anger målförväntningarna för IT-teamet i förväg eftersom det bestämmer tröskeln för hur snabbt systemet eller applikationen kan återställas efter driftstoppet och få ditt system online igen. Efter att ha definierat detta mått i termer av mängden "realtid" för att återställa systemet, kan du sedan planera din återställningsstrategi för att få tjänsten i drift igen. För att beräkna RTO måste du överväga de förluster som är förknippade med ett avbrott i (BCP) Business Continuity Plan återställningstidsmålet. Inkludera även en konsekvensanalys som förklarar de kortsiktiga eller långsiktiga effekterna av affärsavbrott i tjänster. Detta inkluderar risker, förlorade intäkter, utgifter, kundnära applikationer, verksamhetskritiska applikationer och mindre prioriterade applikationer som påverkas eller kommer att bli otillgängliga. RTO är mer bekymrad över driftstopp och tidsbegränsningar för dataåterställningsprocessen.
För att räkna ut en RTO kan du behöva flera RTO-kategorier eftersom vissa avbrott kanske inte behöver mycket återhämtningstid, medan vissa kan kräva olika långsiktiga skyddslösningar. Till exempel kan RTO vara mycket längre för mindre verksamhetskritiska tillämpningar (används inte ofta). Baserat på komplexiteten hos flera säkerhetssystem i drift, kan du behöva ställa in RTO:n enligt korta och långa säkerhetskopior. Detta kan hända på grund av en ransomware-händelse eller annan massiv katastrofincident.
Primära faktorer som ska beaktas vid beräkning av RTO
- Kostnad / nytta-ekvation för återvinningslösningar
- Prioriterade tillämpningar av enskilda system och data
- Åtgärder som ska vidtas av IT-avdelningen baserat på processer, automatiserade tekniker eller teknologier för att återställa IT-infrastrukturen
- Avbrott och begränsningskostnad
- Återställningsförfarandets komplexitet
RTO-provintervall
Att uppnå en RTO nära noll är kostsamt för de flesta IT-företag, men det är möjligt att uppnå om du prioriterar applikationer och data. För mindre affärskritiska applikationer kan RTO-klockan förbruka längre objektiva tider än vanligt. Nära noll RTO-planer för verksamhetskritiska applikationer kan kräva att du överväger omedelbar failover-kapacitet.
Beroende på hur allvarligt avbrottet är kan du ställa in den uppnåeliga måltiden för RTO. Men RTO-återställningstiden beror också på IT-organisationens begränsningar. Till exempel, om återställning av alla IT-funktioner och operationer tar 3 timmar, måste RTO vara minst 3 timmar.
Anmärkningar: Ur ett katastrofåterställningsperspektiv (DR) startar RTO-klockan precis när återställningsprocesserna startar.
När du beräknar RTO (Recovery Time Objective) för dina affärsenheter, överväg dessa exempelintervall:
1 timme
Detta intervall är för redundant säkerhetskopiering på externa hårddiskar.
5 Days
I det här fallet skulle den mest kostnadseffektiva lösningen vara att säkerhetskopiera data med en cd-skiva, ett band eller en annan disklagring.
Uppnå RTO, Zmanda Way
Återhämtningstidsmål (RTO) och Recovery Point Objective (RPO) är otroligt viktiga mål och är grunden för en återhämtningsplan. Hur bestämmer du stegen för praktiska mål för återhämtning? Det är här vi kan hjälpa till!
Med Zmandas DRaaS-plan och anpassade servicenivåavtal, oavsett storleken på ditt företag, kan vi hjälpa dig att korta avbrottstider och undvika smärtan av stillestånd beroende på dina affärsbehov. Förutom hybrid backup för att stödja övergången och uppnå relativt snabbare RTO:er, kombinerar vår företagslösning Amazon Glacier med en 20X lägre kostnad för långsiktig dataarkivering som distribuerar en robust hög tillgänglighet och säkerställer kontinuitet i verksamheten.
Vår företagslösning för säkerhetskopiering förenar säkerhetskopiering, katastrofåterställning och arkivering av långtidslagringar speciellt anpassade för kundernas behov. Detta ger säkerhet, tillförlitlighet, skalbarhet och tillgänglighet samtidigt som du återställer din miljö även vid tider av totalt serverfel.
Se det själv! Låt oss börja med en fri rättegång för att lägga strategi på din datasäkerhetskopiering eller begära en demo. Har du några frågor? Vänligen kontakta oss här..
