Мы задаём этот вопрос на каждом обследовании и почти всегда получаем один ответ.
— За сколько вы поднимете основную систему, если сервер сгорит сегодня ночью?
— У нас есть резервное копирование.
Это ответ на другой вопрос. Наличие резервного копирования говорит о том, что копия существует. Он ничего не говорит о том, за сколько из неё можно развернуть работающую систему и сколько данных при этом потеряется.
Два этих числа называются RTO и RPO. Они звучат как консультантский жаргон, но за ними стоит очень конкретная вещь: сколько денег и работы вы теряете в день аварии.
Что означают эти два числа
RTO — время восстановления. Сколько проходит от момента аварии до момента, когда люди снова работают. Не «когда файлы скопировались», а когда бухгалтер открыл программу и провёл документ.
RPO — допустимая потеря данных. За какой период работа будет потеряна безвозвратно. Если копия снимается раз в сутки ночью, а сервер умер вечером — потерян весь рабочий день.
Разница между ними важнее, чем кажется. Организация может пережить сутки простоя и не пережить потерю дня операций — или наоборот. Это разные риски, и закрываются они разными деньгами.
Почему норма не назовёт вам эти числа
Многие ждут, что регулятор скажет: восстановиться нужно за столько-то часов. Не скажет.
Требование сформулировано иначе. Мера ОДТ.5 обязывает обеспечить возможность восстановления данных из резервных копий «в течение установленного временного интервала». Смысл: интервал устанавливаете вы — во внутреннем документе, — а дальше обязаны его выдерживать.
Рядом стоят соседние меры того же блока:
ОДТ.4 — периодическое резервное копирование персональных данных на резервные машинные носители.
ОДТ.3 — контроль безотказного функционирования технических средств, обнаружение и локализация отказов, принятие мер по восстановлению отказавших средств и их тестирование.
Обратите внимание на ОДТ.3: там прямо сказано «и их тестирование». Проверка восстановления — не добрая воля, а часть требования.
Кого именно это касается. Меры из приложения к приказу применяются не ко всем одинаково: состав зависит от уровня защищённости системы. ОДТ.4 и ОДТ.5 входят в базовый набор для уровней 2 и 1, ОДТ.3 — только для уровня 1. Для систем уровней 4 и 3 эти меры в базовом наборе не значатся — что не отменяет ни здравого смысла, ни договорных обязательств, но означает: ссылаться на них как на всеобщую обязанность нельзя.
Практический вывод. Если у вас нигде не написано, за сколько система должна подниматься, то формально невыполнима сама мера: нет установленного интервала — нечего обеспечивать. А неформально ещё хуже: в момент аварии никто не знает, сколько ждать, и решения принимаются в панике.
Почему бэкап есть, а восстановления нет
Пять причин, которые мы встречаем чаще всего. Все пять обнаруживаются только проверкой.
1. Копия есть, а проверки не было. Задание отрабатывает, отчёт зелёный, письмо приходит. Разворачивали ли из этой копии хоть раз — никто не помнит. Классический исход: копия снимается, но не той базы, или базы без нужного компонента.
2. Копия лежит рядом с оригиналом. На соседнем диске того же сервера или в той же серверной. Это защищает от удаления файла и не защищает ни от пожара, ни от кражи, ни от шифровальщика.
3. Копия доступна с той же учётной записи, что и данные. Тогда шифровальщик, получивший права администратора, шифрует и её. За последние годы это самый частый способ потерять «надёжный бэкап».
4. Восстановление упирается не в данные, а в среду. Копия целая, но разворачивать её некуда: сервера нет, дистрибутива нет, лицензии не найдены, а человек, который это настраивал, уволился в позапрошлом году. Данные восстановятся за час, работоспособность — за неделю.
5. Никто не считал, сколько это займёт физически. Терабайт по гигабитной сети в идеальных условиях едет не мгновенно, а восстановление базы после копирования — отдельное время. Скорость упирается и в систему хранения, с которой копия читается. Реальный RTO часто в разы больше ожидаемого, и узнают об этом в день аварии.
Как назначить свои RTO и RPO за один разговор
Это делается без консультантов, силами руководителя и ИТ, и занимает час.
Шаг 1. Перечислите системы, а не серверы. Учётная система, почта, файлы, сайт, телефония, пропускная система. Пять–десять строк.
Шаг 2. По каждой спросите бизнес, а не ИТ: сколько часов организация проживёт без неё, прежде чем начнутся потери, которые нельзя наверстать. Ответ «нисколько» не принимается — попросите назвать число.
Шаг 3. Отдельно спросите про данные: какой объём работы допустимо переделать вручную. Час операций? Рабочий день? Неделя?
Шаг 4. Разнесите системы на три группы. Критичные — часы. Важные — сутки. Остальные — неделя. Обычно оказывается, что критичных две-три, а не все.
Шаг 5. Спросите ИТ, укладываетесь ли вы сейчас. И попросите не оценку, а проверку.
Шаг 6. Запишите результат в документ и утвердите. Это и есть тот «установленный временной интервал», которого требует норма. Без него дальше не о чем говорить ни с регулятором, ни с подрядчиком.
Разрыв между тем, что назвал бизнес на шаге 2, и тем, что показала проверка на шаге 5, — это ваш объём работ. Не абстрактное «надо улучшить резервное копирование», а конкретная дельта в часах.
Как проверить реальный RTO, ничего не сломав
Единственный способ узнать время восстановления — восстановить. Но делать это на живой системе нельзя, поэтому порядок такой:
- Выберите одну систему — самую критичную из списка.
- Разверните её из копии в отдельной среде, изолированной от рабочей сети.
- Засеките время целиком: от «начали» до «человек вошёл и увидел свои данные». Не время копирования файлов.
- Проверьте содержимое, а не факт запуска: открылись ли последние документы, на какую дату данные, всё ли на месте.
- Запишите, что пошло не так. Не нашли дистрибутив, не вспомнили пароль, не хватило места — это и есть настоящие находки, а не сама цифра.
- Повторяйте раз в год и после каждого крупного изменения.
Первая такая проверка почти всегда неприятна. Это нормально: лучше узнать в спокойной обстановке, чем ночью в аварии.
Что стоит между «часами» и «сутками»
Короткий ориентир, к чему готовиться, если бизнес назвал жёсткие числа:
| что нужно | что для этого требуется |
|---|
| RTO неделя, RPO сутки | копия вне серверной + проверка раз в год |
| RTO сутки, RPO сутки | плюс отдельный доступ к копиям и понятная процедура восстановления |
| RTO часы, RPO часы | плюс резервное оборудование и более частые копии |
| RTO минуты, RPO близко к нулю | резервирование на уровне систем, вторая площадка — совсем другой бюджет |
Если инфраструктура виртуальная, отдельно смотрят схему копирования виртуальных машин — разбор в статье про правило 3-2-1.
Правило, которое экономит деньги: жёсткие RTO и RPO нужны не всей инфраструктуре, а двум-трём системам. Требование «поднимаем всё за час» обычно означает, что список систем никто не разбирал.
Если под оборудование только подбирается помещение, требования к нему разобраны отдельно — что обязательно для серверной, а что нет.
Что делаем мы
Замеряем ваш реальный RTO и RPO — не по документам, а разворачиванием из копии в изолированной среде, и показываем разрыв между тем, что нужно бизнесу, и тем, что есть сейчас.
Дальше проектируем и внедряем то, что этот разрыв закрывает: схему копирования, изоляцию копий, резервирование, регламент восстановления и порядок регулярной проверки — тот самый, которого требует ОДТ.3.
Работаем на вашей площадке. Мы не размещаем ваши данные у себя и не сдаём мощности в аренду.
Оставьте контакт — развернём одну критичную систему из вашей копии в изолированной среде и вернём честные цифры RTO и RPO со списком того, что помешало. Тула и область.
