DRP и BCP
Какво е RTO?
RTO (Recovery Time Objective, целево време за възстановяване) е максималната продължителност, през която дадена услуга може да бъде недостъпна. Той се измерва от инцидента или от решението за превключване до момента, в който потребител отново извършва нормално бизнес действие. А не до включването на машина, чието приложение все още не е проверено.
Актуализирано през октомври 2026 г.3 мин четене4 цитирани източника
Накратко
- RTO събира шест срока: откриване, решение, намиране на достъпите, техническо време, бизнес проверка, връщане на потребителите.
- NIST го разграничава от максимално толерираната продължителност на прекъсването (MTD): RTO обикновено трябва да е по-кратък от MTD.
- RTO се определя за всяка услуга: телефонната централа и архивите нямат един и същ RTO.
- Само тест с измерване на времето показва дали записаният RTO се спазва.
- Работното време на поддръжката и липсата на дежурства са част от реалния RTO.
Официално определение
NIST определя RTO като максималната продължителност, през която ресурс на информационната система може да бъде недостъпен, преди въздействието върху дейностите, които поддържа, да стане неприемливо. Той го разграничава от максимално толерираната продължителност на прекъсването (MTD), която е общата продължителност на прекъсването, приета от ръководството за дадена дейност. RTO трябва да гарантира, че MTD няма да бъде надвишена: затова обикновено е по-кратък.
ANSSI, френската национална агенция по киберсигурност, използва термина максимално допустима продължителност на прекъсването (DMIA). Тя изисква стратегията за резервно копиране да я отчита за всеки бизнес актив и редът на възстановяване да бъде определен предварително според зависимостите (DNS, директорийна услуга…) и критичността на приложенията.
От какво се състои RTO
При класическо възстановяване:
- времето да забележите повредата;
- времето да решите и да се свържете с човека, който знае какво да прави;
- времето да намерите ключове, пароли и процедура;
- техническото време за копиране или стартиране;
- времето за проверка от човек от бизнеса;
- времето, докато работните станции или отдалечените клиенти отново получат достъп до услугата (DNS, VPN, IP).
RTO „от два часа“, обявен от софтуер, често отчита само стъпка 4, в лабораторни условия. Реалният RTO събира всичките шест. През нощта и уикенда само стъпка 2 може да надхвърли два часа, ако никой не е дежурен.
При BCP стъпки 4 и 6 са подготвени предварително. Остават откриването и рискът никой да не смее да одобри превключването.
RTO и RPO не се договарят един за сметка на друг
Може да имате кратък RPO (чести копия) и дълъг RTO (бавно възстановяване на голям обем). Може да имате кратък RTO (резервната среда вече е включена) и посредствен RPO, ако резервната среда изостава с два часа. И двете стойности трябва да бъдат записани.
Данни преди инцидента
Рестартиране на услугите
| RPO | RTO | |
|---|---|---|
| Въпрос | Колко работа можем да загубим? | Колко време можем да останем спрени? |
| Измерва се | Назад, от инцидента | Напред, от инцидента |
| Регулира се чрез | Честотата на копията | Подготовката на резервната среда |
| Проверява се чрез | Датата на последното успешно копие | Тест с измерване на времето |
RTO за всяка услуга
Телефонната централа и системата за управление на архивни документи нямат един и същ RTO. Да запишете „RTO 4 часа“ за цялото предприятие ви кара или да плащате твърде много за архива, или да заблуждавате за централата. Достатъчен е по един ред за всяка услуга.
Как да разберете дали RTO се спазва
Само с хронометър по време на тест. Ако тестът е продължил шест часа, а записаният RTO е два часа, грешен е записаният RTO – докато архитектурата не се промени. Не можете да „целите“ RTO, който последното измерване е опровергало. ANSSI настоява на това: процедурата за възстановяване трябва да бъде написана и редовно прилагана. Честотата на тестовете е разгледана в Колко често да тествате DRP?.
При WeDoBack
На сайта не е публикуван единен цифров RTO и би било подвеждащо да се измисли такъв: той зависи от обема, връзката, размера на инстанцията и наличността на хората от страна на клиента. Архитектурата променя естеството на срока. При обикновено възстановяване данните трябва да бъдат върнати и евентуално да се направи преинсталиране. С DRP сървърите се стартират в резервни инстанции от избраната версия: техническият срок е този на рестартирането, а не на покупката на сървър. Всеки месец се прави тест на стартирането, без да се засяга производствената среда. С BCP облачни инстанции работят постоянно и се свързват чрез агент в мрежата на клиента, без промяна на IP адреса: остатъчният RTO е преди всичко този на откриването и решението. Репликацията или синхронизацията на данните между BCP инстанцията и изходния сървър не е вградена: тя минава през специфичен процес, адаптиран към нуждите, който WeDoBack може да внедри срещу индивидуална оферта. И в трите случая бизнес проверката остава в измерваното време. Човешката поддръжка е на разположение от 9:00 до 13:00 ч. и от 14:00 до 17:30 ч. (парижко време).
Често задавани въпроси
Каква е разликата между RTO и MTD?
MTD (Maximum Tolerable Downtime) е общата продължителност на прекъсването, която ръководството приема за дадена дейност, включително всички последици. RTO е срокът за възстановяване на един ИТ ресурс. NIST уточнява, че RTO обикновено трябва да е по-кратък от MTD, за да остане време за останалите етапи на възстановяването.
Софтуер обявява RTO от няколко минути. Реалистично ли е това?
Тази стойност обикновено отчита само техническото време за стартиране в лабораторни условия. Тя не включва нито откриването, нито времето да се свържете с оправомощеното лице, нито проверката от потребител. Вашият реален RTO е този, който сте измерили при последния си тест – от обявяването на инцидента до първото успешно бизнес действие.
Законово задължение ли е RTO?
Нито един текст не налага на МСП конкретна продължителност. Същевременно ОРЗД (член 32) изисква средства, позволяващи да се възстанови достъпността на личните данни и достъпът до тях „своевременно“ при инцидент. RTO е конкретният начин да се определи този подходящ срок.
Източници
Документи, прегледани през октомври 2026 г.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Резервно копиране на информационните системи – Основи (ANSSI-BP-100, v1.1, 27 ноември 2025 г.) — ANSSI (френска агенция)
- Регламент (ЕС) 2016/679 (ОРЗД), член 32 — EUR-Lex
- Оферта DRP: възстановяване на дейността след бедствие — WeDoBack
Проект за архивиране, DRP или BCP?
Над 20 години опит в защитата на корпоративни данни.
Поискайте оферта+33 9 72 50 78 28Защитете данните си с WeDoBack
Криптирано архивиране извън обекта, неизменимо съхранение, DRP и BCP: опишете ни вашите сървъри и ние ще ви предложим подходящата комбинация.
