Суть подхода
Резервное копирование, это страхование информационного капитала компании. Решение, что копировать и с какой частотой, перестаёт быть техническим вопросом и становится управленческим. Политика резервного копирования (Бэкап-политика), это документ, фиксирующий это управленческое решение. Его цель — не просто указать «бэкапить всё», а определить приоритеты и правила для данных разной ценности.
Формализация задачи: от хаоса к иерархии
Бэкап-политика формализует процесс через несколько ключевых разделов. Это превращает аморфную задачу защиты данных в конкретный график работ, распределение ответственности и техническое задание для инженеров.
Категории данных и их жизненный цикл
Первое, что нужно определить — какие данные создаются и хранятся в компании. Для этого создаётся классификация по критичности и частоте изменений. Простая трёхуровневая модель может выглядеть так:
- Критичные/живые данные (Tier 1). Данные первичных бизнес-процессов. Биллинг, управление производством, операционные журналы. Их потеря или недоступность остановит бизнес. Активно изменяются в реальном времени.
- Важные/неизменяемые данные (Tier 2). Документы, контракты, проектная документация, архивы переписки. Данные меняются периодически, но их целостность и неизменность часто важнее актуальности. Их потеря нанесёт репутационный и юридический ущерб.
- Вспомогательные/среды разработки (Tier 3). Тестовые стенды, среды разработки, журналы отладки, сборки ПО. Их восстановление возможно с некоторой задержкой и с использованием шаблонов.
После категоризации определяется жизненный цикл для каждой категории: как долго данные хранятся в оперативной системе, когда и как долго хранится их резервная копия, когда и по какому алгоритму данные (и их копии) подлежат уничтожению.
Эта классификация прямо укажет, что бэкапить в первую очередь: безусловно, Tier 1 и Tier 2.
Ключевые параметры политики
Просто сказать «копировать критичные данные» недостаточно. Политика должна задать конкретные числовые ориентиры для восстановления. Их два:
- Целевое время восстановления (RTO, Recovery Time Objective). Максимально допустимый простой системы или данных. Если RTO для биллинга — 4 часа, значит за это время должна быть восстановлена работоспособность из резервной копии. RTO определяет технологию восстановления: можно ли запустить систему с бэкапа напрямую (instant recovery), или нужно время на развёртывание.
- Целевая точка восстановления (RPO, Recovery Point Objective). Максимальный допустимый объём потерь данных. Если RPO — 15 минут, то резервная копия должна создаваться не реже этого времени. Это определяет технологию и частоту резервирования: транзакционные журналы СУБД (трансляция изменений), репликация виртуальных машин, ежечасно, ежедневно.
Частая ошибка — установить для всех данных одинаковые RTO и RPO. Для отчёта за прошлый год RPO может быть месяц, а для текущей финансовой транзакции — минуты. Политика должна зафиксировать эти различия.
Пирамида хранения данных и выбор носителей
Копии тоже имеют свою ценность и стоимость хранения. Стратегия «3-2-1» (три копии данных, на двух разных типах носителей, одна из которых вне площадки) получает конкретику через пирамиду хранения бэкапов:
- Горячий резерв / моментальные снапшоты. Хранятся на быстрых SSD/NVMe в основной инфраструктуре. Предназначены для восстановления отдельных файлов или отката недельной давности. RTO — минуты.
- Холодный/архивный резерв. Выгружается на ленточные библиотеки или S3/KVS-подобные хранилища с политиками перехода данных на холодные уровни. Используется для восстановления после катастрофических сбоев или для выполнения требований регуляторов по долгосрочному хранению первичных документов (например, 5 лет по 152-ФЗ). RTO — часы или дни.
- Изолированный резерв. Копия, физически или логически отделённая от основного центра обработки данных и основных систем резервного копирования. Защита от атак программ-вымогателей, которые целенаправленно уничтожают или шифруют доступные сетевые бэкапы. Часто реализуется через пневматическую (air-gapped) схему, где носитель регулярно подключается, обновляется и физически отключается.
Приоритеты при ограниченных ресурсах
Что бэкапить в первую очередь, если нет возможности или бюджета на резервирование всех данных подряд? Ответ лежит в плоскости бизнес-миссии компании. Приоритет определяет не ИТ-отдел, а владельцы процессов. Очередность может быть такой:
- Конфигурационные данные и доступы. Не сами данные, а ключи к ним. Бэкап матриц доступа, конфигурации систем управления доступом (Active Directory, LDAP), файлы закрытых ключей. Без них восстановленные данные окажутся недоступны.
- Живые данные коммерческих транзакций. Базы данных систем, обрабатывающих текущие операции (заказы, платежи, логистика). RPO и RTO здесь минимальны.
- Цифровые подписи и юридически значимые документы. Архивы электронных документов, заверенных ЭП (электронной подписью). Их потеря невозвратима, так как подпись привязана к определённому моменту времени и данным.
- Интеллектуальная собственность. Исходный код, патенты, конструкторская документация. Их восстановление займёт годы, если вообще возможно.
- Корпоративная инфраструктура. Конфигурационные файлы маршрутизаторов, коммутаторов межсетевых экранов, шаблоны виртуальных машин. Позволить быстро восстановить среду для загруженных выше данных.
- Пользовательские файлы и рабочие документы. Часто именно это копируется в первую очередь, так как пользователи «кричат» громче всех. Но потерю недельной работы можно компенсировать, потерю базы данных клиентов — нет.
Интеграция с регуляторными требованиями
В российском контексте бэкап-политика должна учитывать требования ФСТЭК России (особенно приказ №17 для ГИС) и 152-ФЗ «О персональных данных». Это не просто совет, а обязательное условие для ряда компаний. Ключевые требования:
- Шифрование резервных копий ПДн (персональных данных). Если на резервных лентах или дисках содержатся ПДн, они должны быть зашифрованы. Ключи шифрования должны храниться отдельно от самих данных.
- Учёт и контроль изъятия/возврата носителей. Для физических носителей (ленты, диски) должен вестись журнал движения. Кто, когда, с какой целью и на какой срок взял носитель из сейфа или хранилища. Это требование к обеспечению актуальности и доступности ПДн.
- Сроки хранения, определённые законом. Политика должна предписывать хранение налоговых, бухгалтерских и некоторых коммерческих документов в течение сроков, установленных законодательством РФ (4, 5, 10 лет и т.д.). Система резервного копирования должна технически поддерживать установление срока хранения для разных наборов данных и автоматическое уничтожение (или оповещение) по его истечении.
- Требования к тестированию восстановления. ФСТЭК рекомендует проводить плановые проверки восстановления данных из резервных копий. Политика должна закрепить периодичность таких проверок (например, раз в квартал) для наиболее критичных систем.
Процессы, а не только технологии
Лучшая технология бесполезна без прописанных процессов. Политика резервного копирования должна определить:
- Ответственных лиц. Кто утверждает политику, кто отвечает за её техническую реализацию, кто имеет право инициировать восстановление данных, кто утверждает уничтожение устаревших копий.
- Регламент восстановления. Пошаговая процедура на случай инцидента. Куда звонить, какую заявку создавать, какие разрешения получать, как проверять целостность восстановленных данных.
- Мониторинг и отчётность. Как отслеживается успешность бэкапов (не только завершение, но и проверка контрольных сумм). Какие отчёты и с какой периодичностью предоставляются руководству для подтверждения соответствия политике и регуляторным требованиям.
Только наличие этих процессов даёт уверенность, что при возникновении реального инцидента (вирусная атака, сбой оборудования, человеческая ошибка) система защиты данных сработает штатно.
Итог
Политика резервного копирования, это документ, который переводит страх потери данных в управляемую плоскость. Он заставляет бизнес расставить приоритеты, определяя, что действительно является кровью компании, а что — сопутствующей информацией. Для инженеров она служит техническим заданием, для аудиторов — доказательством зрелости процессов. В первую очередь копируется то, без чего бизнес не может существовать физически или юридически, а затем всё остальное — в порядке убывания значимости. Правильно построенная политика не просто создаёт копии, она обеспечивает путь обратно к рабочему состоянию после любого инцидента.