DRP и BCP
Как да определите своя RTO?
RTO се определя с две числа. Първото е икономическо: след колко часа прекъсване цената надвишава това, което сте готови да платите, за да го избегнете. Второто е техническо: колко време е отнело последното реално възстановяване. Записаният RTO трябва да е поне толкова дълъг, колкото второто число, и достатъчно кратък, за да остане първото поносимо; ако те си противоречат, се променя архитектурата, а не хронометърът.
Актуализирано през октомври 2026 г.3 мин четене4 цитирани източника
Накратко
- Икономическо число: блокирани служители × часова цена, загубени продажби, неустойки. Изчислява се за всяка услуга.
- Техническо число: измерено от „обявяваме инцидент“ до първото успешно бизнес действие.
- Без тест нямате технически RTO, а само надежда.
- Ако двете числа не се срещат: намалете обема, подгответе образи, преминете към DRP или BCP или приемете писмено описан ограничен режим.
- RTO се записва според работното време на поддръжката, с която реално разполагате.
Икономическото число
NIST нарича тази стъпка определяне на максимално толерираната продължителност на прекъсването (MTD): това, което дейността понася общо, с всички последици. RTO на ИТ системите трябва да остане под нея. За дадена услуга оценете:
- блокираните служители × пълната часова цена;
- продажбите или услугите, които не могат да бъдат наваксани (загубен клиент, отменен час за лечение);
- договорните неустойки, ако има такива;
- срока, след който се засяга репутацията на предприятието, дори ако е субективен: запишете го все пак.
Пример. Осем блокирани служители, 35 € на час с всички разходи, без неустойки. Всеки час струва 280 € плюс нереализирания оборот. Ако ръководството приема смущения за 1 000 €, икономическият RTO е около три до четири часа. Ако приема един ден, защото поръчките просто се отлагат, RTO може да бъде от 8 до 24 часа.
Направете това изчисление за всяка услуга. Телефонната централа може да има RTO от един час, а документното архивиране – RTO от една седмица.
Техническото число
Вземете последния тест или направете един сега върху тестово копие. Пуснете хронометъра при „обявяваме инцидент“, а не при „софтуерът приключи копирането“. Спрете го, когато потребител успешно извърши обичайно действие.
Ако никога не сте тествали, нямате технически RTO. Имате надежда. В такъв случай неотложната задача е тестът, а не изборът между DRP и BCP. ANSSI, френската национална агенция по киберсигурност, напомня: процедурата за възстановяване трябва да бъде написана и редовно прилагана, а редът на възстановяване – определен предварително според зависимостите (DNS, директорийна услуга) и критичността на приложенията. Бизнес сървър, който чака директорийната услуга, наследява нейния RTO.
Изчислителен фиш
| Услуга | Цена на един час прекъсване | Икономически RTO | Продължителност на последния тест | Разлика | Решение |
|---|---|---|---|---|---|
| Софтуер за оферти | 280 € + продажби | 4 ч. | 9 ч. | 5 ч. | DRP или ограничен режим |
| Електронна поща | Ниска, ако има телефон | 24 ч. | 6 ч. | Няма | Резервното копиране е достатъчно |
| Архиви | Пренебрежима | 1 седмица | 2 дни | Няма | Резервното копиране е достатъчно |
Стойностите по-горе са примерни. Заменете ги с вашите измервания.
Когато двете числа не се срещат
Възстановяването е отнело девет часа, а бизнесът приема само два.
- Намалете обема за възстановяване (отделете архивите от активните данни).
- Разполагайте с образи, готови за стартиране, вместо с преинсталиране.
- Прехвърлете тази услуга към DRP (подготвена резервна среда) или BCP (вече работеща резервна среда). Вижте DRP или BCP: кое да изберете?.
- Или приемете писмено, че реалният RTO е девет часа, и организирайте ограничен режим на хартия за тези девет часа. Това е легитимен избор, ако е направен съзнателно.
ANSSI, в своето ръководство за управление на киберкризи, настоява на тази последна точка: организацията трябва да е способна да поддържа най-критичните си дейности, евентуално в ограничен режим, дори без цифрови услуги. След атака възстановяването може да отнеме няколко седмици: RTO при хардуерна повреда не важи за ransomware.
Не забравяйте работното време
RTO от четири часа, който предполага наличен техник, не се спазва в неделя, ако поддръжката работи в делнични дни от 9:00 до 17:30 ч. Запишете RTO в работни часове на поддръжката, с която разполагате, или платете за дежурство. Иначе RTO в петък в 18:00 ч. в действителност е „понеделник сутринта плюс четири часа“.
При WeDoBack
Човешката поддръжка е на разположение от 9:00 до 13:00 ч. и от 14:00 до 17:30 ч. (парижко време) на +33 9 72 50 78 28 и на [email protected]. Наблюдението на резервните копия обаче работи 24/7: това съкращава откриването на неуспешно копиране, но не и срока за възстановяване в неделя. DRP съкращава техническия срок, като рестартира сървърите в резервни инстанции, без да се чака заменящ сървър; всеки месец се прави тест на стартирането, а тест в реални условия до 10 часа е възможен срещу индивидуална оферта, за да се измери вашият RTO. BCP го съкращава още повече, защото инстанцията вече е включена. Нито едното, нито другото не елиминира времето за вземане на решение и за бизнес проверка, които остават във вашия RTO.
Често задавани въпроси
Как да пресметнете цената на един час прекъсване?
Съберете пълната часова цена на блокираните служители, приходите, които не могат да бъдат наваксани, и евентуалните договорни неустойки. Например осем души по 35 € на час (с всички разходи) струват 280 € на час, преди загубените продажби. Тази стойност служи за сравнение с годишната цена на DRP или BCP.
RTO и максималната продължителност на прекъсването едно и също ли са?
Не съвсем. Максимално толерираната продължителност на прекъсването (MTD според NIST, DMIA според ANSSI) е това, което дейността понася общо. RTO е срокът за възстановяване на ИТ системите. NIST препоръчва RTO да бъде по-кратък от MTD, за да се запази резерв.
Какво да направите, ако изчисленият RTO е непостижим?
Или променяте архитектурата (образи, готови за стартиране, DRP, BCP), или записвате реалния RTO и организирате работа в ограничен режим за цялата му продължителност. И двата подхода са легитимни. Нелегитимно е да запазите стойност, която последният тест е опровергал.
Източници
Документи, прегледани през октомври 2026 г.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Резервно копиране на информационните системи – Основи (ANSSI-BP-100, v1.1, 27 ноември 2025 г.) — ANSSI (френска агенция)
- Киберкриза: ключовете за оперативно и стратегическо управление (декември 2021 г.) — ANSSI (френска агенция)
- Оферта DRP: възстановяване на дейността след бедствие — WeDoBack
Проект за архивиране, DRP или BCP?
Над 20 години опит в защитата на корпоративни данни.
Поискайте оферта+33 9 72 50 78 28Защитете данните си с WeDoBack
Криптирано архивиране извън обекта, неизменимо съхранение, DRP и BCP: опишете ни вашите сървъри и ние ще ви предложим подходящата комбинация.
