Журнал "Information Security/ Информационная безопасность" #4, 2026

За последние несколько лет отноше- ние заказчиков к резервному копирова- нию заметно изменилось. Раньше о СРК нередко вспоминали ближе к концу про- екта, а теперь ее поддержку проверяют заранее. Например, при выборе новой системы виртуализации заказчику важно понимать, сможет ли существующая СРК с ней работать. Если интеграции нет, это может стать препятствием для всего проекта. Особенно хорошо это было видно на первых этапах импортозамещения. Неко- торые отечественные продукты, в част- ности почтовые системы, поначалу про- ектировались почти без учета резерв- ного копирования. Иногда разработчики исходили из того, что высокая доступ- ность и кластеризация позволяют обой- тись без отдельной СРК. Но заказчики довольно быстро стали требовать пол- ноценного резервного копирования и для таких систем: высокая доступность сама по себе его не заменяет. В этом случае возможность резервного копирования лучше предусматривать еще при разработке платформы. Мы работаем с производителями систем виртуализа- ции, почтовых решений, СУБД и других продуктов, чтобы необходимые механиз- мы появлялись в них заранее. Так интег- рацию сделать гораздо проще, чем дора- батывать уже готовую систему после выхода на рынок и первых внедрений. Есть и вполне понятный экономиче- ский расчет. Заказчик сопоставляет стоимость приобретения и внедрения СРК с возможными потерями при сбое. Здесь уместна аналогия со страховкой: инцидента может и не быть, но, если он произойдет, подготовленная система поможет сократить простой и быстрее вернуть инфраструктуру в рабочее состояние. Как и в случае со страховкой, ценность такой системы становится осо- бенно заметной в момент инцидента. До этого она может восприниматься как расходы на защиту от маловероятного события, но после серьезного сбоя имен- но наличие заранее выстроенной систе- мы восстановления определяет, сколько времени бизнес будет оставаться без критически важных ИТ-сервисов. Но резервная копия ценна только тогда, когда из нее действительно можно восстановиться. Важно заранее пони- мать, сколько это займет времени и в какой последовательности придется возвращать в работу разные системы. Внимание заказчиков смещается от соз- дания копий к восстановлению – именно в этот момент и становится понятно, насколько хорошо работает СРК. Масштабирование инфраструктуры На раннем этапе импортозамещения заказчикам было важно прежде всего выполнить требование регулятора и получить поддержку нужных отечествен- ных платформ. Сейчас одного этого уже недостаточно: в крупных проектах на первый план выходят производитель- ность и масштабирование. Растут объе- мы данных и число рабочих нагрузок, поэтому СРК должна расширяться вме- сте с инфраструктурой без существенной перестройки системы. Одно из направлений работы – про- изводительность продукта. "Кибер Бэкап" 2 уже 10 лет на рынке, по мере развития в нем неизбежно остаются компоненты, которые с ростом нагрузки могут ста- новиться узкими местами. Мы регу- лярно проводим нагрузочное тестиро- вание, находим такие участки и пере- рабатываем их. Это постоянная работа, а не оптимизация под отдельный релиз. Результат хорошо виден на конкрет- ных сценариях. Несколько лет назад один сервер управления мог работать примерно с 6–8 тыс. почтовых ящиков, сейчас – примерно с 80 тыс. При этом через сервер управления не проходит весь поток резервируемых данных: он управляет процессом и распределяет задания между агентами. Второй способ увеличить производи- тельность – распределить нагрузку. В крупной инфраструктуре нет смысла пытаться пропустить все данные через один компонент. Можно добавить агентов, распределить между ними сегменты сети или рабочие нагрузки и выполнять опе- рации параллельно. Так систему можно масштабировать без полной перестройки архитектуры резервного копирования. Но чем крупнее инфраструктура, тем сложнее ею управлять. Когда объектов уже сотни или тысячи, настраивать каж- дый вручную становится слишком трудо- емко. Появляется потребность в группо- вых операциях, автоматизации типовых действий, централизованном мониторин- ге и разделении прав. Например, одним сотрудникам нужно управлять заданиями резервного копирования, другим – только следить за состоянием системы, а спе- циалистам службы безопасности может потребоваться доступ к журналу событий без возможности что-либо менять. Централизация упрощает работу и службе информационной безопасно- сти. Когда резервное копирование раз- ных систем собрано в одном контуре, его проще контролировать и аудировать, а права пользователей – разграничивать. События из СРК можно и нужно переда- вать в SIEM, чтобы включить резервное копирование в общий мониторинг ИБ. 36 • СПЕЦПРОЕКТ Архитектура восстановления с “Кибер Бэкапом” езервная копия имеет ценность только тогда, когда в нужный момент из нее можно быстро и предсказуемо вернуть систему в работу. С ростом инфраструктуры эта задача усложняется: приходится учитывать производительность, интеграцию с раз- ными платформами, миграцию рабочих нагрузок и проверку сценариев восстановления. Все эти требования определяют развитие “Кибер Бэкапа”, системы резервного копирования компании “Киберпротект” 1 . Р Дмитрий Антонов, директор направления систем резервного копирования компании “Киберпротект” Фото: Киберпротект 1 https://cyberprotect.ru/ 2 https://cyberprotect.ru/products/backup/