RPO ja RTO – palautumispisteen tavoite ja palautumisaikatavoite – ovat tärkeitä mittareita kehitettäessä katastrofipalautussuunnitelmia ja -strategiaa.
Ne ovat olennaisia yksityiskohtien selvittämisessä siitä, kuinka voit toipua odottamattomasta katkoksesta, olipa kyseessä tekninen tai yhä useammin haitallisten tarkoitusten, kuten kiristysohjelmien, seurauksena.
Tämä johtuu siitä, että organisaatiosi vaatimukset sen suhteen, kuinka paljon dataa sinulla on varaa menettää ja kuinka kauan sinulla on varaa olla järjestelmien poissa käytöstä, sanelevat tallennuksen ja tietosuojan tekniikat ja tuotteet, jotka sinun on määritettävä.
Tässä artikkelissa tarkastellaan, kuinka määrittelemme RPO:n ja RTO:n, miksi ne ovat tärkeitä ja miten ne lasketaan organisaatiollesi ja sen toiminnoille.
Määrittele RTO ja RPO
RTO on määritelty maailmanlaajuisessa katastrofipalautuksen ICT-standardissa ISO/IEC 27031:2011 seuraavasti: "Ajanjakso, jonka kuluessa palveluiden ja/tai tuotteiden vähimmäistasot ja tukijärjestelmät, sovellukset tai toiminnot on palautettava häiriön ilmetessä."
RPO puolestaan määritellään seuraavasti: "Ajankohta, johon mennessä tiedot on palautettava häiriön ilmetessä."
Selvästi englanniksi sanottuna RTO on aika, jonka ajan sinulla on varaa olla järjestelmien ja tietojen poissa käytöstä. Se mitataan ajassa ja on ajanjakso, jonka kuluessa järjestelmät on palautettava katkon jälkeen.
RPO on datamäärä, jolla sinulla on varaa menettää. Sitäkin mitataan ajassa, mutta se nähdään sen linssin läpi, kuinka paljon dataa sinulla on varaa menettää. Joten se määräytyy sen mukaan, kuinka kauan viimeinen varmuuskopiointi ja/tai tilannekuva on tehty tai kuinka tuoreet tiedot ovat sivustossa, johon siirryt.
Joten esimerkiksi organisaatio voi määrittää, että se voi työskennellä yhden tunnin RTO:lla ja kahden tunnin RPO:lla.
Kuva ei kuitenkaan todennäköisesti ole yhtä yksinkertainen.
Eri RTO:t ja RPO:t eri sovelluksille?
Mutta organisaation sisäinen sovellusmaisema ei sovellu kokonaisvaltaisille mittareille, jotka kattavat kaiken.
Todellisuus on, että rakeiset RTO:t ja RPO:t ovat luultavasti se, mitä tarvitaan reagoimaan todellisiin tilanteisiin.
Jos esimerkiksi kaikki järjestelmäsi hajoavat, ensisijaisena olisi palauttaa ne, jotka ovat julkisia ja tuottavat tuloja, mukaan lukien erittäin aikakriittiset tapahtumasovellukset.
Nämä olisivat ensisijaisia, ja ne olisivat jatkumon vastakkaisessa päässä kuin esimerkiksi pitkään säilytetyt ja käyttämättömät arkistoidut tiedot tai strukturoimattomat tiedot ilman liiketoiminnan kannalta kriittisiä aikarajoituksia.
Käytännön seurausten osalta erot näkyvät eri tallennusluokkien ja tietosuojan käytössä.
RTO:n ja RPO:n laskeminen
Aloitus on määrittää riskin taso järjestelmien organisoinnille, että järjestelmät eivät ole käytettävissä, ja kuinka kauan se voidaan sietää.
On järkevää luokitella ja priorisoida järjestelmät ja esittää kysymyksiä, kuten:
RPO- ja RTO-esimerkit
Ihanteellinen RPO- ja RTO-arvo olisi nolla. Mutta mitä lähemmäs nollaa pääset, sitä enemmän se maksaa.
Joten nolla ei ole vaihtoehto useimmille järjestelmille, mutta jotkut tarvitsevat sitä – nimittäin pankkitapahtumajärjestelmät, jotka eivät kestä lähes mitään tietojen katoamista tai järjestelmän epäkäytettävyyttä.
Todellisemmin katsottuna luokittelet sovellukset ja järjestelmät tason mukaan. Eli esimerkiksi:
RTO/RPO-taso ja tietosuojamenetelmä
Taso määrittää suurelta osin tietosuojan tason. Joten esimerkiksi tason 1 järjestelmät tarvitsevat kaksinkertaista kirjoitusta ja/tai tietojen toistuvaa replikointia suojautuakseen paikallisilta ongelmilta. Se tarvitsee todennäköisesti myös kyvyn siirtyä nopeasti etäsijaintiin sivustotason uhkien sattuessa.
Tier 2 -järjestelmät tarvitsevat harvemmin tietojen kopioimista, mutta niiden on myös kyettävä siirtymään vikasietojärjestelmiin. Kaikki tasot tukisivat päivittäisiä varmuuskopioita sekä pilvi- ja/tai nauha-arkistoihin siirtämistä tietojen ikääntyessä.
Organisaatiosi kyky täyttää RTO- ja RPO-palvelutason sopimukset (SLA) määräytyy käyttökatkon laajuuden mukaan, joten se on laadittava yhdessä riskiarvioinnin ja liiketoimintavaikutusanalyysin kanssa, jossa tarkastellaan todennäköistä vaihteluväliä. Mahdolliset seisokkien syyt ja luokitellaan ne todennäköisyyden ja vaikutuksen perusteella. Levyvika on selvästi vähemmän vaikuttava kuin esimerkiksi tulvinut paikka.
Pilvitallennus ja RTO/RPO
Kun selvität organisaatiollesi sopivia tallennus- ja tietosuojatyyppejä sekä erilaisia järjestelmiä, joita sen on toimittava ja suojattava, joudut yhä todennäköisemmin käyttämään pilvipalvelua. varastointi huomioon.
Pilven käyttö palvelinkeskuksen rinnalla on melko yleistä, ja tutkimuksissa lähes puolet asiakkaista käyttää pilvipalvelua jollakin tavalla katastrofien palautumiseen.
RPO- ja RTO-vaatimusten ja laskelmien vaikeus on se, että olet nyt riippuvainen ulkoisesta palveluntarjoajasta. Muista siis keskustella perusteellisesti RPO- ja RTO-vaatimuksistasi eri tietoluokille ja sitoa palveluntarjoaja mahdollisimman paljon selkeillä SLA-sopimuksilla. Pilvipalveluntarjoajan ja etäsivustojen kanssa työskentelyssä voi olla muitakin hankaluuksia.
Joten, saatat jopa ajatella, että joitain järjestelmiä ja tietoja ei voida jättää kolmannen osapuolen kanssa solmittujen palvelusopimusten hallintaan, ja huomaat, että haluat palauttaa ne talon sisällä.
