DRP и BCP
Колко често да тествате DRP?
Проверявайте автоматично дали копията все още стартират, поне веднъж месечно, и правете реално превключване с бизнес действие поне веднъж годишно. Повторете теста веднага щом се смени сървърът, мрежата, доставчикът или човекът, който държи ключа.
Актуализирано през октомври 2026 г.3 мин четене6 цитирани източника
Накратко
- Всеки ден: преглед на неуспешните резервни копия. Всеки месец: техническо стартиране на резервната среда.
- Всяко тримесечие: възстановяване с измерване на времето. Всяка година: реално превключване с връщане обратно.
- NIST предвижда годишен тест на възможностите за възстановяване; ОРЗД и ANSSI (Франция) изискват редовни тестове.
- Всяка съществена промяна (сървър, основна версия, администратор, доставчик, интернет връзка) налага тест.
- Най-важното: записаната дата на последния тест и коригираните отклонения.
Какво казват референтните рамки
- NIST. Ръководството SP 800-34, написано за федералните системи на САЩ, предвижда всяка година да се тестват възможностите за възстановяване и екипите, за да се открият слабостите им. Самият план трябва да се актуализира с честота, определена от организацията, например ежегодно, и след всяка съществена промяна.
- ОРЗД. Член 32 изисква средства, позволяващи своевременно възстановяване на достъпността на личните данни, и процедура за редовно изпитване и оценка на ефективността на мерките за сигурност.
- ANSSI (Франция). Според френската национална агенция по киберсигурност резервните копия трябва да се тестват редовно, а процедурата за възстановяване на информационната система трябва да бъде написана и редовно прилагана. За ученията по управление на кризи агенцията препоръчва многогодишна стратегия с формати, които постепенно стават по-амбициозни.
Нито един от тези текстове не налага „всеки месец в реални условия“. Всички те водят към чести проверки и пълен тест поне веднъж годишно.
Защо не „всеки месец в реални условия“
Реалното превключване прекъсва или рискува да прекъсне производствената среда. Ако се прави всеки месец, то струва скъпо като часове и умора, а екипите в крайна сметка го претупват. По-добре един сериозен годишен тест, отколкото месечен ритуал, при който никой не отваря приложението.
От друга страна, да чакате цяла година, за да откриете, че резервно копие вече не стартира, е твърде дълго. Оттук и честата, лека техническа проверка, и редкият, но пълен бизнес тест.
Реалистичен график за МСП
| Кога | Какво |
|---|---|
| Всеки ден | Преглед на неуспешните резервни копия. DRP, който се захранва от повредено копие, е повреден DRP |
| Всеки месец | Техническо стартиране на резервната среда, без прекъсване на производствената |
| Всяко тримесечие | Възстановяване на файл или база данни с измерване на времето |
| Всяка година | Реално превключване или еквивалент, с бизнес потребител и връщане обратно |
| При всяка промяна | Нов сървър, нова основна версия, напускане на администратора, смяна на доставчика или на интернет връзката |
Силно регулираните сектори или жизненоважните системи (здравеопазване, непрекъснато производство) скъсяват реда „всяка година“, понякога до шест месеца. Това не е минималната норма за МСП в сферата на услугите. Подробностите за всяко ниво са в Как да тествате DRP?.
Кое е по-важно от честотата
Записаната дата на последния тест и коригираните отклонения. DRP, тестван преди единадесет месеца, с протокол, е в по-добро състояние от DRP, „тестван постоянно“, без нито един запис за това какво е проверено. NIST изисква всяко учение да завършва с доклад, в който се записват наблюденията и препоръките за подобрение.
Ако последният тест е отпреди повече от дванадесет месеца, кажете го направо на ръководството. Това е информация, а не повод за срам. Грешката е да обявите пред клиент или застраховател, че планът е работещ.
След реален инцидент
Реалното бедствие е тест, при условие че в рамките на седмицата изготвите протокол: какво е отнело повече време от предвиденото, какво е липсвало, какво променяте в плана. Без това ще пострадате два пъти по един и същи начин. Вижте също Сървърът ми спря да работи: какво да направя?.
При WeDoBack
Проверката на стартирането е месечна и е включена в DRP, без да засяга производствената среда: тя покрива реда „всеки месец“ от таблицата – за образа, но не и за бизнес действието. Тестът в реални условия се планира, до десет часа, срещу индивидуална оферта: той е естественият кандидат за годишния ред. Нищо в офертата не тества вместо вас човешката процедура (кой решава, къде е ключът, как се уведомява екипът). Тази част следва ритъма на напусканията и назначенията, а не ритъма на софтуера.
Често задавани въпроси
Има ли законово задължение за честотата на тестовете?
Няма общо правило за всички МСП. ОРЗД (член 32) и ANSSI, френската агенция по киберсигурност, изискват „редовно“ тестване, без да определят ритъм. NIST, за федералните системи на САЩ, предвижда годишен тест. Някои регулирани сектори, както и вашите договори и застрахователят ви, могат да наложат по-чест ритъм.
Реалното бедствие брои ли се за тест?
Да, при условие че в рамките на седмицата изготвите протокол: какво е отнело повече време от предвиденото, какво е липсвало, какво се променя в плана. Без такъв запис инцидентът не помага за подобряване на плана.
Какво да кажете на клиент или застраховател, ако последният тест е отпреди повече от година?
Истината, с датата. Ако обявите, че планът е работещ, без скорошен тест, рискувате разминаване между обещанието и реалността в деня на бедствието. По-добре посочете планираната дата на следващия тест.
Източници
Документи, прегледани през октомври 2026 г.
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
- Регламент (ЕС) 2016/679 (ОРЗД), член 32 — EUR-Lex
- Резервно копиране на информационните системи – Основи (ANSSI-BP-100, v1.1, 27 ноември 2025 г.) — ANSSI (френска агенция)
- Организиране на учение по управление на киберкриза — ANSSI (френска агенция)
- SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (септември 2006 г.) — NIST
- Оферта DRP: възстановяване на дейността след бедствие — WeDoBack
Проект за архивиране, DRP или BCP?
Над 20 години опит в защитата на корпоративни данни.
Поискайте оферта+33 9 72 50 78 28Защитете данните си с WeDoBack
Криптирано архивиране извън обекта, неизменимо съхранение, DRP и BCP: опишете ни вашите сървъри и ние ще ви предложим подходящата комбинация.
