Váš expert na zálohovanie a ochranu údajov!Riešenie prispôsobené vašim potrebám
DRP a BCP
Čo je RTO?
RTO (Recovery Time Objective, cieľový čas obnovy) je maximálna doba, počas ktorej môže byť služba nedostupná. Meria sa od incidentu alebo od rozhodnutia o prepnutí až po chvíľu, keď používateľ znova vykoná bežný pracovný úkon. Nie len po zapnutie stroja, ktorého aplikácia ešte nie je overená.
To najdôležitejšie
- RTO je súčtom šiestich časov: zistenie, rozhodnutie, hľadanie prístupov, technický čas, overenie prevádzkou, návrat používateľov.
- NIST ho odlišuje od maximálnej tolerovateľnej doby výpadku (MTD): RTO má byť spravidla kratšie ako MTD.
- RTO sa stanovuje pre každú službu: telefónna ústredňa a archívy nemajú rovnaké.
- Len test s meraním času ukáže, či je zapísané RTO dodržané.
- Prevádzkové hodiny podpory a chýbajúca pohótovosť sú súčasťou skutočného RTO.
Oficiálna definícia
NIST definuje RTO ako maximálnu dobu, počas ktorej môže byť zdroj informačného systému nedostupný, kým dopad na činnosti, ktoré podporuje, nebude neprijateľný. Odlišuje ho od maximálnej tolerovateľnej doby výpadku (MTD), teda celkovej doby výpadku, ktorú vedenie pre danú činnosť akceptuje. RTO má zaručiť, že MTD nebude prekročená: preto je spravidla kratšie.
ANSSI, francúzska národná agentúra pre kybernetickú bezpečnosť, používa pojem maximálna prípustná doba prerušenia (DMIA). Požaduje, aby ju stratégia zálohovania zohľadňovala pre každé podnikové aktívum a aby bolo vopred stanovené poradie obnovy podľa závislostí (DNS, adresárová služba…) a kritickosti aplikácií.
Z čoho sa RTO skladá
Pri klasickej obnove:
- čas potrebný na zistenie poruchy;
- čas na rozhodnutie a zastihnutie osoby, ktorá vie, čo robiť;
- čas na nájdenie kľúčov, hesiel a postupu;
- technický čas kopírovania alebo štartu;
- čas na overenie niekým z prevádzky;
- čas, kým pracovné stanice alebo vzdialení klienti znova získajú prístup k službe (DNS, VPN, IP).
RTO „dve hodiny“ deklarované softvérom často zahŕňa len krok 4 v laboratórnych podmienkach. Skutočné RTO je súčtom všetkých šiestich. V noci a cez víkend môže už samotný krok 2 presiahnuť dve hodiny, ak nikto nemá pohótovosť.
Pri BCP sú kroky 4 a 6 pripravené vopred. Zostáva zistenie incidentu a riziko, že si nikto netrúfne prepnutie schváliť.
RTO a RPO sa navzájom nevymieňajú
Môžete mať krátke RPO (časté kópie) a dlhé RTO (pomalá obnova veľkého objemu dát). Môžete mať krátke RTO (záložné prostredie už beží) a slabé RPO, ak má záložné prostredie dvojhodinové oneskorenie. Zapisujú sa obe čísla.
RPOMaximálna prípustná strata dát
RTOMaximálna prípustná doba výpadku
meria sa späť
meria sa dopredu
Dáta pred incidentom
!Incident
Opätovné spustenie služieb
| RPO | RTO | |
|---|---|---|
| Otázka | Koľko práce môžeme stratiť? | Ako dlho môžeme stáť? |
| Meria sa | Späť, od incidentu | Dopredu, od incidentu |
| Nastavuje sa | Frekvenciou kópií | Prípravou záložného prostredia |
| Overuje sa | Dátumom poslednej úspešnej kópie | Testom s meraním času |
RTO pre každú službu
Telefónna ústredňa a systém na správu archívnych dokumentov nemajú rovnaké RTO. Zapísať „RTO 4 hodiny“ pre celú firmu núti buď preplatiť správu dokumentov, alebo klamať pri ústredni. Postačí jeden riadok na službu.
Ako zistiť, či je RTO dodržané
Jedine meraním času pri teste. Ak test trval šesť hodín a zapísané RTO je dve hodiny, chybné je zapísané RTO, kým sa nezmení architektúra. Nemôžete „mieriť“ na RTO, ktoré posledné meranie vyvrátilo. ANSSI na tom trvá: postup obnovy musí byť spísaný a pravidelne vykonávaný. Frekvencii testov sa venuje článok Ako často testovať DRP?.
Vo WeDoBack
Na webe nie je zverejnené žiadne jednotné číselné RTO a bolo by zavádzajúce si ho vymyslieť: závisí od objemu dát, pripojenia, veľkosti inštancie a dostupnosti ľudí na strane zákazníka. Architektúra mení povahu tohto času. Pri jednoduchej obnove treba dáta preniesť späť a prípadne systém preinštalovať. S ponukou DRP sa servery spustia na záložných inštanciách zo zvolenej verzie: technický čas je časom tohto spustenia, nie nákupu servera. Test štartu prebieha každý mesiac bez zásahu do prevádzky. S ponukou BCP sú cloudové inštancie nepretržite spustené a agent v sieti zákazníka na ne presmeruje prevádzku bez zmeny IP adresy: zvyškové RTO tvorí najmä čas zistenia a rozhodnutia. Replikácia alebo synchronizácia dát medzi inštanciou BCP a pôvodným serverom nie je natívna: vyžaduje osobitný proces prispôsobený potrebe, ktorý môže WeDoBack zaviesť na základe cenovej ponuky. Vo všetkých troch prípadoch zostáva overenie prevádzkou súčasťou meraného času. Ľudská podpora je dostupná od 9:00 do 13:00 a od 14:00 do 17:30 (parížskeho času).
Časté otázky
Aký je rozdiel medzi RTO a MTD?
MTD (Maximum Tolerable Downtime) je celková doba výpadku, ktorú vedenie pre danú činnosť akceptuje, vrátane všetkých dopadov. RTO je čas potrebný na obnovenie prevádzky IT zdroja. NIST spresňuje, že RTO má byť spravidla kratšie ako MTD, aby zostala rezerva na ostatné kroky obnovy.
Softvér uvádza RTO niekoľko minút. Je to realistické?
Toto číslo spravidla zahŕňa len technický čas štartu v laboratórnych podmienkach. Nezahŕňa zistenie incidentu, čas potrebný na zastihnutie oprávnenej osoby ani overenie používateľom. Vaše skutočné RTO je to, ktoré ste namerali pri poslednom teste, od ohlásenia incidentu po prvý úspešný pracovný úkon.
Je RTO zákonnou povinnosťou?
Žiadny predpis neukladá malej a strednej firme konkrétnu číselnú hodnotu. GDPR (článok 32) však požaduje prostriedky, ktoré pri incidente umožnia obnoviť dostupnosť osobných údajov a prístup k nim „včasným spôsobom“. RTO je konkrétnym spôsobom, ako tento primeraný čas definovať.
Ďalšie čítanie
Zdroje
Dokumenty preštudované v októbri 2026.
Plánujete projekt zálohovania, DRP alebo BCP?
Viac ako 20 rokov skúseností s ochranou firemných údajov.
Vyžiadať cenovú ponuku+33 9 72 50 78 28Chráňte svoje údaje s WeDoBack
Šifrované zálohovanie mimo pracoviska, nemenné úložisko, DRP a BCP: opíšte nám svoje servery a my vám navrhneme vhodnú kombináciu.