Колко често да тествате DRP?

Проверявайте автоматично дали копията все още стартират, поне веднъж месечно, и правете реално превключване с бизнес действие поне веднъж годишно. Повторете теста веднага щом се смени сървърът, мрежата, доставчикът или човекът, който държи ключа.

Актуализирано през октомври 2026 г.3 мин четене6 цитирани източника

Накратко

  • Всеки ден: преглед на неуспешните резервни копия. Всеки месец: техническо стартиране на резервната среда.
  • Всяко тримесечие: възстановяване с измерване на времето. Всяка година: реално превключване с връщане обратно.
  • NIST предвижда годишен тест на възможностите за възстановяване; ОРЗД и ANSSI (Франция) изискват редовни тестове.
  • Всяка съществена промяна (сървър, основна версия, администратор, доставчик, интернет връзка) налага тест.
  • Най-важното: записаната дата на последния тест и коригираните отклонения.

Какво казват референтните рамки

  • NIST. Ръководството SP 800-34, написано за федералните системи на САЩ, предвижда всяка година да се тестват възможностите за възстановяване и екипите, за да се открият слабостите им. Самият план трябва да се актуализира с честота, определена от организацията, например ежегодно, и след всяка съществена промяна.
  • ОРЗД. Член 32 изисква средства, позволяващи своевременно възстановяване на достъпността на личните данни, и процедура за редовно изпитване и оценка на ефективността на мерките за сигурност.
  • ANSSI (Франция). Според френската национална агенция по киберсигурност резервните копия трябва да се тестват редовно, а процедурата за възстановяване на информационната система трябва да бъде написана и редовно прилагана. За ученията по управление на кризи агенцията препоръчва многогодишна стратегия с формати, които постепенно стават по-амбициозни.

Нито един от тези текстове не налага „всеки месец в реални условия“. Всички те водят към чести проверки и пълен тест поне веднъж годишно.

Защо не „всеки месец в реални условия“

Реалното превключване прекъсва или рискува да прекъсне производствената среда. Ако се прави всеки месец, то струва скъпо като часове и умора, а екипите в крайна сметка го претупват. По-добре един сериозен годишен тест, отколкото месечен ритуал, при който никой не отваря приложението.

От друга страна, да чакате цяла година, за да откриете, че резервно копие вече не стартира, е твърде дълго. Оттук и честата, лека техническа проверка, и редкият, но пълен бизнес тест.

Реалистичен график за МСП

КогаКакво
Всеки денПреглед на неуспешните резервни копия. DRP, който се захранва от повредено копие, е повреден DRP
Всеки месецТехническо стартиране на резервната среда, без прекъсване на производствената
Всяко тримесечиеВъзстановяване на файл или база данни с измерване на времето
Всяка годинаРеално превключване или еквивалент, с бизнес потребител и връщане обратно
При всяка промянаНов сървър, нова основна версия, напускане на администратора, смяна на доставчика или на интернет връзката

Силно регулираните сектори или жизненоважните системи (здравеопазване, непрекъснато производство) скъсяват реда „всяка година“, понякога до шест месеца. Това не е минималната норма за МСП в сферата на услугите. Подробностите за всяко ниво са в Как да тествате DRP?.

Кое е по-важно от честотата

Записаната дата на последния тест и коригираните отклонения. DRP, тестван преди единадесет месеца, с протокол, е в по-добро състояние от DRP, „тестван постоянно“, без нито един запис за това какво е проверено. NIST изисква всяко учение да завършва с доклад, в който се записват наблюденията и препоръките за подобрение.

Ако последният тест е отпреди повече от дванадесет месеца, кажете го направо на ръководството. Това е информация, а не повод за срам. Грешката е да обявите пред клиент или застраховател, че планът е работещ.

След реален инцидент

Реалното бедствие е тест, при условие че в рамките на седмицата изготвите протокол: какво е отнело повече време от предвиденото, какво е липсвало, какво променяте в плана. Без това ще пострадате два пъти по един и същи начин. Вижте също Сървърът ми спря да работи: какво да направя?.

При WeDoBack

Проверката на стартирането е месечна и е включена в DRP, без да засяга производствената среда: тя покрива реда „всеки месец“ от таблицата – за образа, но не и за бизнес действието. Тестът в реални условия се планира, до десет часа, срещу индивидуална оферта: той е естественият кандидат за годишния ред. Нищо в офертата не тества вместо вас човешката процедура (кой решава, къде е ключът, как се уведомява екипът). Тази част следва ритъма на напусканията и назначенията, а не ритъма на софтуера.

Често задавани въпроси

Има ли законово задължение за честотата на тестовете?

Няма общо правило за всички МСП. ОРЗД (член 32) и ANSSI, френската агенция по киберсигурност, изискват „редовно“ тестване, без да определят ритъм. NIST, за федералните системи на САЩ, предвижда годишен тест. Някои регулирани сектори, както и вашите договори и застрахователят ви, могат да наложат по-чест ритъм.

Реалното бедствие брои ли се за тест?

Да, при условие че в рамките на седмицата изготвите протокол: какво е отнело повече време от предвиденото, какво е липсвало, какво се променя в плана. Без такъв запис инцидентът не помага за подобряване на плана.

Какво да кажете на клиент или застраховател, ако последният тест е отпреди повече от година?

Истината, с датата. Ако обявите, че планът е работещ, без скорошен тест, рискувате разминаване между обещанието и реалността в деня на бедствието. По-добре посочете планираната дата на следващия тест.

Проект за архивиране, DRP или BCP?

Над 20 години опит в защитата на корпоративни данни.

Поискайте оферта+33 9 72 50 78 28

Защитете данните си с WeDoBack

Криптирано архивиране извън обекта, неизменимо съхранение, DRP и BCP: опишете ни вашите сървъри и ние ще ви предложим подходящата комбинация.