Сценарий, при котором корпоративная инфраструктура защищается по частям, возникает «сам собой». Системный администратор настраивает резервное копирование виртуальных машин с помощью моментальных снимков гипервизора. Базы данных бэкапятся внутренними средствами создания дампов. Файловые серверы защищаются скриптами и штатными утилитами.
Разработчики ОС, гипервизоров и СУБД действительно встраивают в свои продукты базовые механизмы резервного копирования. Их цель — обеспечить автономность конкретного компонента. Однако у этой автономности есть и весомые ограничения: встроенная утилита «не видит» смежные сервисы. Она не рассчитана на координацию сложных связей внутри корпоративной сети, и чаще всего ее запускают вручную или через скрипт.
В итоге, вместо централизованной защиты компания получает разрозненный набор средств, где каждый сервис защищается по своим правилам. Разберем, к каким рискам это приводит и почему инфраструктуре требуется единая система резервного копирования.
4 скрытых риска фрагментации бэкапа
По мере масштабирования ИТ-ландшафта использование десятка разрозненных утилит перестает быть рабочим инструментом и становится источником уязвимостей.
- «Слепые зоны» и отсутствие единого мониторинга
Без единой панели управления администраторам приходится ежедневно проверять отчеты в разных интерфейсах и системных журналах. Ошибки выполнения скриптов или переполнение дисков часто фиксируются постфактум. В таких условиях нерабочий бэкап критического сервиса может быть обнаружен только в момент аварии, когда восстанавливать данные уже поздно. - Рассинхронизация связанных сервисов
Корпоративные системы - это цепочка взаимозависимых компонентов: приложения, сервисы, базы данных и др. Если снимок виртуальной машины, дамп базы данных и копия архива почты создаются в разное время, при сбое восстановить рабочее состояние связки сервисов на единую точку во времени (Point-in-Time Recovery) без потери транзакций или нарушения целостности данных крайне сложно. - Уязвимость перед вредоносным ПО
Штатные средства операционных систем и СУБД выгружают резервные копии в стандартные файловые каталоги. У них нет встроенных механизмов защиты от перезаписи. При компрометации сетевого периметра вредоносное ПО получает доступ к этим директориям и блокирует копии данных вместе с рабочими. - Зависимость от ключевых сотрудников и скрытый рост TCO
Кажущаяся экономия на отказе от централизованной системы резервного копирования оборачивается высокими расходами на сопровождение. Эксплуатация сложной связки из самописных скриптов и точечных обходных решений держится на компетенциях конкретных инженеров. Если автор скрипта покидает компанию, контроль над процессами утрачивается. Это сказывается на совокупной стоимости владения (TCO) инфраструктурой.
Встроенные средства vs Единая СРК
Чтобы наглядно оценить разницу подходов, сравним базовые утилиты системного ПО и возможности централизованной системы резервного копирования.
Опыт российской компании
Рассмотрим ситуацию, характерную для средней организации. ИТ-ландшафт включает Microsoft Active Directory, 1С, файловые серверы, СУБД Microsoft SQL Server и PostgreSQL, а также узлы кластера Hyper-V. Общий объем защищаемых данных - около 30 ТБ. Именно такой набор - разнородные системы, каждая со своей спецификой - чаще всего и становится причиной, по которой компании живут с разрозненными бэкапами.
Перед ИТ-отделом стояла задача выбрать отечественную систему резервного копирования, которая закроет всю эту инфраструктуру. Специалисты опирались на опыт использования зарубежных СРК и сравнивали российские разработки с их возможностями.
Кибер Бэкап закрыл задачу как универсальное решение: одна система защищает платформы и приложения из единой консоли, без необходимости держать отдельные утилиты под каждую систему.
Подробности этого кейса, включая сроки реализации проекта, результаты и комментарии специалистов, доступны на нашем сайте.
Самоаудит для руководителя
Проверьте, готова ли ваша инфраструктура к отказу от фрагментированного подхода. Если вы согласны хотя бы с одним утверждением из списка ниже, встроенные утилиты перестали справляться с задачами бизнеса:
- Резервное копирование разных сегментов инфраструктуры контролируется из трех и более не связанных между собой интерфейсов.
- В регламентах компании не зафиксированы измеримые и регулярно проверяемые показатели RTO (допустимое время восстановления) и RPO (допустимый объем потери данных).
- Резервные копии хранятся в том же сегменте и на тех же дисковых массивах, где функционируют основные рабочие сервисы.
- Процедура восстановления систем не формализована и требует обязательного участия конкретных специалистов, настраивавших скрипты.
Заключение
Использование встроенных утилит оправдано на этапе запуска базовой инфраструктуры или в изолированных тестовых средах. Для стабильно работающего бизнеса фрагментация процессов резервного копирования оборачивается простоями, рисками рассинхронизации данных и нерациональными трудозатратами ИТ-команды.
Переход на централизованную СРК, такую как Кибер Бэкап, позволяет устранить слепые зоны в мониторинге, размещать резервные копии в защищенных изолированных хранилищах и обеспечить прогнозируемое время восстановления для всех критичных систем.
Листайте дальше, чтобы перейти на сайт Киберпротекта, узнать больше о возможностях Кибер Бэкапа и получить бесплатную пробную версию.