Varmuuskopioinnin ja tietosuojan asiantuntijanne!Tarpeisiinne räätälöity ratkaisu
DRP ja BCP
Mikä on RTO?
RTO (Recovery Time Objective, palautumisaikatavoite) on pisin aika, jonka palvelu saa olla poissa käytöstä. Se mitataan häiriöstä tai siirtopäätöksestä siihen hetkeen, jolloin käyttäjä tekee jälleen tavallisen liiketoiminnan tehtävän. Ei siihen asti, kun käynnistyy kone, jonka sovellusta ei ole vielä tarkistettu.
Tärkeimmät asiat
- RTO on kuuden viiveen summa: havaitseminen, päätös, käyttöoikeuksien etsiminen, tekninen aika, liiketoiminnan tarkistus ja käyttäjien paluu.
- NIST erottaa sen suurimmasta siedettävästä katkosta (MTD): RTO:n on tavallisesti oltava MTD:tä lyhyempi.
- RTO kirjataan palveluittain: puhelinvaihteella ja arkistoilla ei ole samaa RTO:ta.
- Vain ajastettu testi kertoo, toteutuuko kirjattu RTO.
- Tuen aukioloajat ja päivystäjän puuttuminen kuuluvat todelliseen RTO:hon.
Virallinen määritelmä
NIST määrittelee RTO:n pisimmäksi ajaksi, jonka tietojärjestelmän resurssi voi olla poissa käytöstä ennen kuin vaikutus sen tukemiin toimintoihin muuttuu kestämättömäksi. Se erottaa RTO:n suurimmasta siedettävästä katkosta (MTD), joka on toiminnon kokonaiskatkon kesto, jonka johto hyväksyy. RTO:n on varmistettava, ettei MTD ylity: se on siis tavallisesti lyhyempi.
Ranskan kansallinen kyberturvallisuusvirasto ANSSI käyttää termiä suurin hyväksyttävä keskeytysaika (DMIA). Se edellyttää, että varmuuskopiointistrategia ottaa sen huomioon jokaisen liiketoiminta-arvon osalta ja että palautusjärjestys määritellään etukäteen riippuvuuksien (DNS, hakemistopalvelu…) ja sovellusten kriittisyyden mukaan.
Mistä RTO muodostuu
Tavanomaisessa palautuksessa:
- aika, joka kuluu vian huomaamiseen;
- aika päätöksen tekemiseen ja osaavan henkilön tavoittamiseen;
- aika avainten, salasanojen ja menettelyn löytämiseen;
- kopioinnin tai käynnistyksen tekninen aika;
- liiketoiminnan edustajan tekemään tarkistukseen kuluva aika;
- aika, jonka kuluessa työasemat tai etäasiakkaat saavat palvelun taas käyttöönsä (DNS, VPN, IP-osoitteet).
Ohjelmiston ilmoittama ”kahden tunnin” RTO kattaa usein vain vaiheen 4 laboratorio-olosuhteissa. Todellinen RTO on kaikkien kuuden summa. Öisin ja viikonloppuisin pelkkä vaihe 2 voi kestää yli kaksi tuntia, jos kukaan ei ole päivystysvuorossa.
BCP:ssä vaiheet 4 ja 6 on valmisteltu etukäteen. Jäljelle jäävät havaitseminen ja riski siitä, ettei kukaan uskalla hyväksyä siirtoa.
RTO:ta ja RPO:ta ei vaihdeta toisiinsa
RPO voi olla lyhyt (tiheät kopiot) ja RTO pitkä (suuren tietomäärän hidas palautus). RTO voi olla lyhyt (varaympäristö jo käynnissä) ja RPO heikko, jos varaympäristö on kaksi tuntia jäljessä. Molemmat luvut kirjataan.
RPOSuurin hyväksyttävä tietojen menetys
RTOSuurin hyväksyttävä katkon kesto
mitataan taaksepäin
mitataan eteenpäin
Tiedot ennen häiriötä
!Häiriö
Palveluiden uudelleenkäynnistys
| RPO | RTO | |
|---|---|---|
| Kysymys | Kuinka paljon työtä voidaan menettää? | Kuinka kauan toiminta voi olla pysähdyksissä? |
| Mitataan | Taaksepäin häiriöstä | Eteenpäin häiriöstä |
| Säädetään | Kopioiden tiheydellä | Varaympäristön valmistelulla |
| Tarkistetaan | Viimeisimmän onnistuneen kopion ajankohdasta | Ajastetulla testillä |
RTO palveluittain
Puhelinvaihteella ja arkistojen dokumenttienhallinnalla ei ole samaa RTO:ta. Jos koko yritykselle kirjataan ”RTO 4 tuntia”, joko dokumenttienhallinnasta maksetaan liikaa tai puhelinvaihteesta annetaan väärä kuva. Yksi rivi palvelua kohden riittää.
Miten tietää, toteutuuko RTO
Ainoastaan ajanotolla testin aikana. Jos testi kesti kuusi tuntia ja kirjattu RTO on kaksi tuntia, kirjattu RTO on väärä, kunnes arkkitehtuuri muuttuu. RTO:ta, jonka viimeisin mittaus on kumonnut, ei voi ”tavoitella”. ANSSI korostaa tätä: palautusmenettely on kirjattava ja toteutettava säännöllisesti. Testien tiheyttä käsitellään oppaassa Kuinka usein DRP pitää testata?.
WeDoBackilla
Sivustolla ei julkaista yhtä numeerista RTO:ta, ja sellaisen keksiminen olisi harhaanjohtavaa: se riippuu tietomäärästä, yhteydestä, instanssin koosta ja asiakkaan henkilöiden tavoitettavuudesta. Arkkitehtuuri muuttaa viiveen luonnetta. Tavallisessa palautuksessa tiedot on tuotava takaisin ja mahdollisesti asennettava järjestelmä uudelleen. DRP-palvelussa palvelimet käynnistyvät varainstansseissa valitusta versiosta: tekninen viive on tämän käynnistyksen kesto, ei uuden palvelimen hankinnan. Käynnistystesti tehdään kuukausittain tuotantoon koskematta. BCP-palvelussa pilvi-instanssit ovat jatkuvasti käynnissä, ja asiakkaan verkossa toimiva agentti ohjaa liikenteen niihin ilman IP-osoitteen muutosta: jäljelle jäävä RTO muodostuu lähinnä havaitsemisesta ja päätöksenteosta. Tietojen replikointi tai synkronointi BCP-instanssin ja alkuperäisen palvelimen välillä ei ole sisäänrakennettu: se edellyttää tarpeeseen sovitettua erillistä prosessia, jonka WeDoBack voi toteuttaa tarjouksen perusteella. Kaikissa kolmessa tapauksessa liiketoiminnan tarkistus sisältyy ajanottoon. Asiantuntijatuki on tavoitettavissa klo 9–13 ja 14–17.30 (Pariisin aikaa).
Usein kysytyt kysymykset
Mikä ero on RTO:lla ja MTD:llä?
MTD (Maximum Tolerable Downtime) on toiminnon kokonaiskatkon kesto, jonka johto hyväksyy kaikki vaikutukset huomioiden. RTO on IT-resurssin palauttamiseen käyttöön kuluva aika. NIST tarkentaa, että RTO:n on tavallisesti oltava MTD:tä lyhyempi, jotta toipumisen muille vaiheille jää pelivaraa.
Ohjelmisto lupaa muutaman minuutin RTO:n. Onko se realistista?
Luku kattaa yleensä vain teknisen käynnistysajan laboratorio-olosuhteissa. Siihen ei sisälly havaitsemista, valtuutetun henkilön tavoittamista eikä käyttäjän tekemää tarkistusta. Todellinen RTO:nne on se, jonka mittasitte viimeisimmässä testissä häiriöilmoituksesta ensimmäiseen onnistuneeseen liiketoiminnan tehtävään.
Onko RTO lakisääteinen velvoite?
Mikään säädös ei aseta pk-yritykselle numeerista kestoa. EU:n yleisen tietosuoja-asetuksen (GDPR) 32 artikla kuitenkin edellyttää keinoja, joilla henkilötietojen saatavuus ja pääsy niihin voidaan palauttaa häiriön sattuessa ”oikea-aikaisesti”. RTO on konkreettinen tapa määritellä tämä oikea-aikaisuus.
Lue lisää
Lähteet
Asiakirjat tarkistettu lokakuussa 2026.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Tietojärjestelmien varmuuskopiointi – perusteet (ANSSI-BP-100, v1.1, 27.11.2025, ranskaksi) — ANSSI (Ranskan virasto)
- Asetus (EU) 2016/679 (GDPR), 32 artikla — EUR-Lex
- DRP-palvelu: toiminnan palauttaminen vahingon jälkeen — WeDoBack
Onko teillä varmuuskopiointi-, DRP- tai BCP-hanke?
Yli 20 vuoden kokemus yritysten tietojen suojaamisesta.
Pyytäkää tarjous+33 9 72 50 78 28Suojatkaa tietonne WeDoBackin avulla
Salattu ulkoinen varmuuskopiointi, muuttumaton tallennus, toipumissuunnitelma (DRP) ja jatkuvuussuunnitelma (BCP): kertokaa meille palvelimistanne, niin ehdotamme teille sopivan kokonaisuuden.