Jūsu eksperts datu dublēšanā un aizsardzībā!Jūsu vajadzībām pielāgots risinājums
DRP un BCP
Kas ir RTO?
RTO (Recovery Time Objective, atjaunošanas laika mērķis) ir maksimālais laiks, cik ilgi pakalpojums var būt nepieejams. To mēra no incidenta vai lēmuma pārslēgties līdz brīdim, kad lietotājs atkal veic parastu darba darbību. Nevis līdz brīdim, kad ieslēdzas iekārta, kuras lietotne vēl nav pārbaudīta.
Galvenais
- RTO ir sešu laika posmu summa: atklāšana, lēmums, piekļuves datu meklēšana, tehniskais laiks, biznesa pārbaude, lietotāju atgriešanās.
- NIST to nodala no maksimālā pieļaujamā pārtraukuma ilguma (MTD): RTO parasti jābūt īsākam par MTD.
- RTO nosaka katram pakalpojumam: telefona centrālei un arhīviem tas nav vienāds.
- Tikai tests ar laika mērīšanu parāda, vai noteiktais RTO tiek ievērots.
- Atbalsta darba laiks un dežūru trūkums ir daļa no faktiskā RTO.
Oficiālā definīcija
NIST definē RTO kā maksimālo laiku, cik ilgi informācijas sistēmas resurss var būt nepieejams, pirms ietekme uz tā atbalstītajām darbībām kļūst nepieļaujama. To nodala no maksimālā pieļaujamā pārtraukuma ilguma (MTD), kas ir kopējais dīkstāves ilgums, ko vadība pieļauj kādai darbībai. RTO jāgarantē, ka MTD netiek pārsniegts: tāpēc tas parasti ir īsāks.
ANSSI, Francijas valsts kiberdrošības aģentūra, lieto terminu maksimālais pieļaujamais pārtraukuma ilgums (DMIA). Tā prasa, lai dublēšanas stratēģija to ņemtu vērā katrai biznesa vērtībai un lai atjaunošanas secība tiktu noteikta iepriekš, atkarībā no atkarībām (DNS, direktorijs…) un lietotņu kritiskuma.
No kā sastāv RTO
Klasiskas atjaunošanas gadījumā:
- laiks, lai pamanītu kļūmi;
- laiks, lai pieņemtu lēmumu un sazinātos ar cilvēku, kurš zina, kā rīkoties;
- laiks, lai atrastu atslēgas, paroles un procedūru;
- tehniskais kopēšanas vai startēšanas laiks;
- laiks, kas vajadzīgs biznesa darbiniekam pārbaudei;
- laiks, līdz darbstacijas vai attālie klienti atkal piekļūst pakalpojumam (DNS, VPN, IP).
Programmatūras solītais «divu stundu» RTO bieži ietver tikai 4. posmu laboratorijas apstākļos. Faktiskais RTO ir visu sešu summa. Naktī un brīvdienās 2. posms viens pats var pārsniegt divas stundas, ja neviens nav dežūrā.
BCP gadījumā 4. un 6. posms ir sagatavoti iepriekš. Paliek atklāšana un risks, ka neviens neuzdrošinās apstiprināt pārslēgšanu.
RTO un RPO nav savstarpēji aizstājami
Var būt īss RPO (biežas kopijas) un garš RTO (liela apjoma lēna atjaunošana). Var būt īss RTO (rezerves vide jau ieslēgta) un vidējs RPO, ja rezerves vide atpaliek par divām stundām. Abi skaitļi ir jāieraksta.
RPOMaksimālais pieļaujamais datu zudums
RTOMaksimālais pieļaujamais dīkstāves laiks
mēra atpakaļ
mēra uz priekšu
Dati pirms incidenta
!Incidents
Pakalpojumu atkārtota startēšana
| RPO | RTO | |
|---|---|---|
| Uzdotais jautājums | Cik daudz darba drīkstam zaudēt? | Cik ilgi drīkstam stāvēt dīkstāvē? |
| Mēra | Atpakaļ no incidenta | Uz priekšu no incidenta |
| Regulē ar | Kopēšanas biežumu | Rezerves vides sagatavošanu |
| Pārbauda ar | Pēdējās veiksmīgās kopijas datumu | Testu ar laika mērīšanu |
RTO katram pakalpojumam
Telefona centrālei un arhīvu dokumentu pārvaldības sistēmai RTO nav vienāds. Ierakstot «RTO 4 stundas» visam uzņēmumam, nākas vai nu pārmaksāt par dokumentu pārvaldības sistēmu, vai melot par telefona centrāli. Pietiek ar vienu rindu katram pakalpojumam.
Kā zināt, vai RTO tiek ievērots
Tikai ar hronometru testa laikā. Ja tests ilga sešas stundas, bet ierakstītais RTO ir divas stundas, tad kļūdains ir ierakstītais RTO, kamēr nemainās arhitektūra. Nevar «tiekties» uz RTO, ko pēdējais mērījums ir atspēkojis. ANSSI to uzsver: atjaunošanas procedūrai jābūt uzrakstītai un regulāri izpildītai. Testu biežums aplūkots rakstā Cik bieži testēt DRP?.
WeDoBack pieeja
Vietnē nav publicēts viens skaitlisks RTO, un to izdomāt būtu maldinoši: tas ir atkarīgs no datu apjoma, pieslēguma, instances lieluma un klienta puses cilvēku pieejamības. Arhitektūra maina termiņa raksturu. Vienkāršas atjaunošanas gadījumā dati jāatgriež un, iespējams, jāveic pārinstalēšana. Ar DRP serveri tiek atkārtoti startēti rezerves instancēs no izvēlētās versijas: tehniskais termiņš ir šīs startēšanas ilgums, nevis servera iegādes laiks. Startēšanas tests notiek katru mēnesi, neskarot ražošanas vidi. Ar BCP mākoņa instances ir pastāvīgi ieslēgtas, un tās pārraida aģents klienta tīklā, nemainot IP adresi: atlikušais RTO galvenokārt ir atklāšanas un lēmuma pieņemšanas laiks. Datu replicēšana vai sinhronizācija starp BCP instanci un sākotnējo serveri nav iebūvēta: tā notiek ar īpašu, vajadzībām pielāgotu procesu, ko WeDoBack var ieviest pēc cenu piedāvājuma. Visās trīs situācijās biznesa pārbaude paliek hronometra laikā. Klientu atbalsts ir sasniedzams no 9:00 līdz 13:00 un no 14:00 līdz 17:30 (pēc Parīzes laika).
Biežāk uzdotie jautājumi
Kāda ir atšķirība starp RTO un MTD?
MTD (Maximum Tolerable Downtime) ir kopējais dīkstāves ilgums, ko vadība pieļauj kādai darbībai, ņemot vērā visu ietekmi. RTO ir IT resursa darbības atjaunošanas termiņš. NIST precīzē, ka RTO parasti jābūt īsākam par MTD, lai atstātu rezervi pārējiem atjaunošanas posmiem.
Programmatūra sola RTO dažu minūšu laikā. Vai tas ir reāli?
Šis skaitlis parasti ietver tikai tehnisko startēšanas laiku laboratorijas apstākļos. Tas neietver ne atklāšanu, ne laiku, kas vajadzīgs, lai sazinātos ar pilnvaroto personu, ne lietotāja veiktu pārbaudi. Jūsu faktiskais RTO ir tas, ko izmērījāt pēdējā testā – no incidenta paziņošanas līdz pirmajai veiksmīgajai biznesa darbībai.
Vai RTO ir juridisks pienākums?
Neviens normatīvais akts MVU neuzliek konkrētu skaitlisku termiņu. Tomēr VDAR (32. pants) prasa līdzekļus, kas incidenta gadījumā ļauj «savlaicīgi» atjaunot personas datu pieejamību un piekļuvi tiem. RTO ir konkrēts veids, kā definēt šo savlaicīgo termiņu.
Lasiet arī
Avoti
Dokumenti skatīti 2026. gada oktobrī.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Informācijas sistēmu datu dublēšana – pamatprincipi (ANSSI-BP-100, v1.1, 2025. gada 27. novembris) — ANSSI (Francijas aģentūra)
- Regula (ES) 2016/679 (VDAR), 32. pants — EUR-Lex
- DRP piedāvājums: darbības atjaunošana pēc katastrofas — WeDoBack
Plānojat rezerves kopēšanas, DRP vai BCP projektu?
Vairāk nekā 20 gadu pieredze uzņēmumu datu aizsardzībā.
Pieprasīt piedāvājumu+33 9 72 50 78 28Aizsargājiet savus datus ar WeDoBack
Šifrēta ārpusvietas rezerves kopēšana, nemainīga krātuve, DRP un BCP: aprakstiet mums savus serverus, un mēs piedāvāsim piemērotāko risinājumu kombināciju.