Jūsų atsarginių kopijų ir duomenų apsaugos ekspertas!Jūsų poreikiams pritaikytas sprendimas
DRP ir BCP
Kas yra RTO?
RTO (Recovery Time Objective, atkūrimo laiko tikslas) – tai didžiausia trukmė, kurią paslauga gali būti nepasiekiama. Ji matuojama nuo incidento arba sprendimo perjungti iki momento, kai naudotojas vėl atlieka įprastą darbinį veiksmą. Ne iki kompiuterio įjungimo, kai jo programa dar nepatikrinta.
Svarbiausia
- RTO sudaro šešių intervalų suma: aptikimas, sprendimas, prieigų paieška, techninis laikas, darbinis patikrinimas, naudotojų sugrįžimas.
- NIST jį atskiria nuo didžiausios toleruojamos prastovos trukmės (MTD): RTO paprastai turi būti trumpesnis už MTD.
- RTO nustatomas kiekvienai paslaugai: telefono stotelė ir archyvai turį skirtingą.
- Tik bandymas matuojant laiką parodo, ar užrašyto RTO laikomasi.
- Pagalbos darbo valandos ir budėjimo nebuvimas yra faktinio RTO dalis.
Oficiali apibrėžtis
NIST RTO apibrėžia kaip didžiausią trukmę, kurią informacinės sistemos išteklius gali būti nepasiekiamas, kol poveikis jo palaikomoms veikloms tampa nepriimtinas. Jis atskiria jį nuo didžiausios toleruojamos prastovos trukmės (MTD), t. y. bendros prastovos trukmės, kurią vadovybė pripažįsta priimtina tam tikrai veiklai. RTO turi užtikrinti, kad MTD nebūtų viršyta: todėl paprastai jis yra trumpesnis.
ANSSI, Prancūzijos nacionalinė kibernetinio saugumo agentūra, vartoja terminą didžiausia leistina sutrikimo trukmė (DMIA). Ji reikalauja, kad atsarginių kopijų strategija atsižvelgtų į ją kiekvienai verslo vertybei ir kad atkūrimo tvarka būtų nustatyta iš anksto, atsižvelgiant į priklausomybes (DNS, katalogo tarnyba ir kt.) ir programų kritiškumą.
Iš ko susideda RTO
Įprasto atkūrimo atveju:
- laikas, per kurį pastebimas gedimas;
- laikas, per kurį priimamas sprendimas ir susisiekiama su tuo, kas moka tai padaryti;
- laikas, per kurį surandami raktai, slaptažodžiai ir procedūra;
- techninis kopijavimo ar paleidimo laikas;
- laikas, per kurį verslo atstovas patikrina veikimą;
- laikas, per kurį darbo vietos ar nutolę klientai vėl pasiekia paslaugą (DNS, VPN, IP).
Programinės įrangos skelbiamas „dviejų valandų“ RTO dažnai apima tik 4 etapą laboratorijos sąlygomis. Faktinis RTO sudeda visus šešis. Naktį ir savaitgalį vien 2 etapas gali užtrukti ilgiau nei dvi valandas, jei niekas nebudi.
BCP atveju 4 ir 6 etapai parengiami iš anksto. Lieka aptikimas ir rizika, kad niekas nedrįs patvirtinti perjungimo.
RTO ir RPO nekeičiami vienas į kitą
Galima turėti trumpą RPO (dažnos kopijos) ir ilgą RTO (lėtas didelės apimties atkūrimas). Galima turėti trumpą RTO (atsarginė aplinka jau veikia) ir prastą RPO, jei atsarginė aplinka atsilieka dviem valandomis. Abu skaičiai turi būti užrašyti.
RPODidžiausias priimtinas duomenų praradimas
RTODidžiausia priimtina prastovos trukmė
matuojama atgal
matuojama į priekį
Duomenys prieš incidentą
!Incidentas
Paslaugų paleidimas iš naujo
| RPO | RTO | |
|---|---|---|
| Klausimas | Kiek darbo galime prarasti? | Kiek laiko galime nedirbti? |
| Matuojama | Atgal nuo incidento | Į priekį nuo incidento |
| Reguliuojama | Kopijų dažnumu | Atsarginės aplinkos pasirengimu |
| Tikrinama | Paskutinės sėkmingos kopijos data | Bandymu matuojant laiką |
Atskiras RTO kiekvienai paslaugai
Telefono stotelė ir archyvų dokumentų valdymo sistema neturi vienodo RTO. Užrašius „RTO 4 valandos“ visai įmonei, tenka arba permokėti už dokumentų valdymo sistemą, arba meluoti apie telefono stotelę. Pakanka vienos eilutės kiekvienai paslaugai.
Kaip sužinoti, ar RTO laikomasi
Tik chronometru per bandymą. Jei bandymas truko šešias valandas, o užrašytas RTO yra dvi valandos, klaidingas yra užrašytas RTO, kol nepasikeis architektūra. Negalima „siekti“ RTO, kurį paskutinis matavimas paneigė. ANSSI tai pabrėžia: atkūrimo procedūra turi būti parengta ir reguliariai vykdoma. Bandymų ritmas aptariamas straipsnyje Kaip dažnai išbandyti DRP?.
WeDoBack sprendimas
Svetainėje neskelbiamas vienas skaitinis RTO, ir jį išgalvoti būtų klaidinanti: jis priklauso nuo duomenų apimties, ryšio, egzemplioriaus dydžio ir kliento pusės darbuotojų pasiekiamumo. Architektūra keičia termino pobūdį. Paprasto atkūrimo atveju reikia sugrąžinti duomenis ir galbūt iš naujo įdiegti sistemą. Naudojant DRP, serveriai paleidžiami atsarginiuose egzemplioriuose iš pasirinktos versijos: techninis terminas yra šio paleidimo laikas, o ne serverio įsigijimo laikas. Paleidimo bandymas atliekamas kas mėnesį, neliečiant gamybinės aplinkos. Naudojant BCP, debesijos egzemplioriai veikia nuolat ir yra susieti per agentą kliento tinkle, nekeičiant IP adreso: likutinį RTO daugiausia sudaro aptikimas ir sprendimas. Duomenų replikacija ar sinchronizavimas tarp BCP egzemplioriaus ir pirminio serverio nėra įdiegtas standartiškai: tam reikia specialaus, poreikiams pritaikyto proceso, kurį WeDoBack gali įdiegti pagal kainos pasiūlymą. Visais trimis atvejais darbinis patikrinimas lieka chronometro dalimi. Specialistų pagalba pasiekiama 9:00–13:00 ir 14:00–17:30 (Paryžiaus laiku).
Dažniausiai užduodami klausimai
Kuo skiriasi RTO ir MTD?
MTD (Maximum Tolerable Downtime) – tai bendra prastovos trukmė, kurią vadovybė pripažįsta priimtina tam tikrai veiklai, įvertinus visą poveikį. RTO – tai IT ištekliaus atkūrimo terminas. NIST patikslina, kad RTO paprastai turi būti trumpesnis už MTD, kad liktų atsarga kitiems atkūrimo etapams.
Programinės įrangos gamintojas skelbia kelių minučių RTO. Ar tai realu?
Šis skaičius paprastai apima tik techninį paleidimo laiką laboratorijos sąlygomis. Jis neįskaičiuoja nei aptikimo, nei laiko, per kurį susisiekiama su įgaliotu asmeniu, nei naudotojo atliekamo patikrinimo. Jūsų faktinis RTO yra tas, kurį išmatavote per paskutinį bandymą – nuo pranešimo apie incidentą iki pirmojo sėkmingo darbinio veiksmo.
Ar RTO yra teisinis reikalavimas?
Joks teisės aktas MVĮ nenustato konkrečios trukmės. Tačiau BDAR (32 straipsnis) reikalauja priemonių, leidžiančių incidento atveju „laiku“ atkurti asmens duomenų prieinamumą ir prieigą prie jų. RTO yra konkretus būdas apibrėžti tą tinkamą terminą.
Daugiau šia tema
Šaltiniai
Dokumentai peržiūrėti 2026 m. spalio mėn.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Informacinių sistemų atsarginės kopijos. Pagrindai (ANSSI-BP-100, v1.1, 2025 m. lapkričio 27 d.) — ANSSI (Prancūzijos agentūra)
- Reglamentas (ES) 2016/679 (BDAR), 32 straipsnis — EUR-Lex
- DRP pasiūlymas: veiklos atkūrimas po nelaimės — WeDoBack
Planuojate atsarginio kopijavimo, DRP ar BCP projektą?
Daugiau nei 20 metų patirtis saugant įmonių duomenis.
Gauti pasiūlymą+33 9 72 50 78 28Apsaugokite savo duomenis su WeDoBack
Šifruotas atsarginis kopijavimas už įmonės ribų, nekeičiama saugykla, DRP ir BCP: aprašykite mums savo serverius, o mes pasiūlysime tinkamiausią sprendimų derinį.