Стратегия резервного копирования данных

16 мин чтения·Для руководителя и лидера безопасности

Коротко

• Резервная копия, которую ни разу не восстанавливали, — это не копия, а надежда. Тест восстановления важнее частоты резервного копирования.
• Правило «3-2-1»: три копии, два типа носителей, одна — «вне офиса». Синхронизированная папка в облаке копией не считается: она синхронизирует и зашифрованные файлы тоже.
• От шифровальщика защищает только неизменяемая или изолированная копия, которую скомпрометированная учётная запись не может удалить.

Шифровальщик сработал в пятницу вечером. К понедельнику зашифрованы файловый сервер и подключённый к нему внешний диск. Облачная «резервная копия» в синхронизированной папке исправно синхронизировала и зашифрованные версии файлов тоже. Компания заплатила выкуп. Ключ расшифровки оказался с ошибками. Половина файлов восстановилась повреждёнными.

Такой сценарий повторяется в разных компаниях с пугающей регулярностью. Резервное копирование существовало на бумаге — на практике оно не сработало.

Эта глава закрывает этот разрыв. Вы выстроите резервное копирование, которое проверено тестами восстановления, а не только зафиксировано в документе на случай проверки.

Почему резервные копии подводят в нужный момент

У большинства компаний резервное копирование настроено. У большинства из них оно не сработает в реальной катастрофе. Вот пять причин, почему:

1. Восстановление никогда не тестировали. Резервная копия создаётся каждую ночь, но никто ни разу не пробовал из неё восстановиться. Что копии повреждены, выясняется уже во время катастрофы — когда исправить это поздно.

2. Единая точка отказа. Резервный диск подключён к серверу — оба зашифрованы. Резервная копия в том же облачном регионе — регион недоступен, и копия тоже.

3. Неполный охват. Резервируется файловый сервер, но не базы данных, SaaS-сервисы и файлы конфигурации. После восстановления половина систем не запускается.

4. Отсутствует документация. Сотрудник, настроивший резервное копирование, уволился два года назад. Никто не знает, как запускать восстановление, где хранятся ключи шифрования и что проверять в первую очередь.

5. Восстановление занимает слишком много времени. Резервная копия есть, но восстановление 5 терабайт данных занимает трое суток. Бизнес не выдерживает такой простой.

warning

Синхронизация — не резервное копирование. Папка, синхронизированная с облаком, повторяет каждое изменение файла — включая шифрование вымогательским ПО. Резервная копия, которую ни разу не тестировали на восстановление, тоже не работает как защита: она даёт лишь иллюзию безопасности.

Правило «3-2-1»: стандарт, проверенный временем

Правило «3-2-1» — основа резервного копирования уже несколько десятилетий:

• 3 копии данных (оригинал + 2 резервных)
• 2 разных типа носителя или хранилища
• 1 копия вне офиса (географически удалённая)

Она задаёт минимальный уровень избыточности, при котором единичный сбой не приводит к потере данных.

Почему каждое число важно

• 3 копии обеспечивают избыточность (redundancy). Если одна резервная копия повреждена, остаётся вторая. Диски ломаются, облачные сервисы становятся недоступны, файлы портятся. Две резервные копии позволяют пережить единичный сбой.

• 2 разных типа носителя защищают от отказа одного класса оборудования или сервиса. Если все копии хранятся на дисках одной модели с заводским дефектом партии, компания теряет всё сразу. Комбинируйте типы: локальное хранилище и объектное хранилище в облаке, либо NAS (сетевое хранилище данных) и ленточный накопитель.

• 1 копия вне офиса защищает от физических катастроф: пожара, затопления, кражи, шифровальщика, распространившегося на всю локальную сеть. Если офис недоступен, данные остаются целы — копия хранится в другом месте.

Расширенное правило «3-2-1-1-0»

Современная практика добавляет к формуле два элемента:

• +1 неизменяемая (immutable) или изолированная (air-gapped) копия. Её нельзя изменить или удалить, даже с правами администратора.
• +0 — ноль ошибок. Резервные копии регулярно проверяются и тестируются на восстановление.

Дополнительная «1» защищает от шифровальщиков, которые целенаправленно атакуют резервные копии: получив права администратора, они сначала удаляют резервные копии и только потом шифруют данные. Неизменяемая копия выживает даже в этом сценарии.

Что резервировать

Прежде чем настраивать инструменты, составьте инвентарь того, что реально нужно защитить.

Категории критичных данных

Бизнес-данные:

• Базы данных клиентов.
• Финансовая отчётность и первичные документы.
• Договоры и юридические документы.
• Кадровые документы.
• Исходный код, дизайны, интеллектуальная собственность.

Конфигурации систем:

• Конфигурации серверов и сетевых устройств.
• Настройки приложений.
• Инфраструктурный код (Infrastructure as Code).
• SSL-сертификаты и ключи.

Данные из SaaS-сервисов:

• Корпоративная почта и документы (Яндекс 360, VK WorkSpace, МойОфис).
• CRM, HelpDesk, система управления проектами.
• Мессенджеры (история переписки VK Teams, eXpress и т.п.).
• Бухгалтерские системы (1С и аналоги).

Базы данных:

• Производственные СУБД.
• Аналитические данные.

Учётные данные и ключи:

• Экспорт из менеджера паролей — Пассворк поддерживает зашифрованный экспорт; планируйте ежемесячные резервные выгрузки.
• Ключи шифрования самих резервных копий (хранить отдельно от бэкапов!).

Классификация по приоритету восстановления

Категория	Примеры	Частота бэкапа	Хранение	Приоритет восстановления
Критичная	БД клиентов, финансы	Часто / ежечасно	1+ год	Немедленно
Важная	Исходный код, конфиги	Ежедневно	90 дней	В течение часов
Стандартная	Внутренние документы	Ежедневно / еженедельно	30 дней	В течение суток
Низкий приоритет	Архивы, старые проекты	Еженедельно / ежемесячно	30 дней	По возможности

Приоритет восстановления выражают двумя числами — RPO и RTO. Их фиксируют в политике резервного копирования и проверяют на учениях.

Типы резервных копий

Полная (full) — полная копия всех данных. Дольше, больше места, но проще восстанавливать. Делается еженедельно или ежемесячно.

Инкрементальная (incremental) — только данные, изменившиеся с момента последнего бэкапа любого типа. Быстро, компактно, но восстановление требует всей цепочки — если одна инкрементальная копия повреждена, теряется всё после неё.

Дифференциальная (differential) — данные, изменившиеся с момента последней полной копии. Быстрее полной, надёжнее инкрементальной: восстановление требует только последней полной и последней дифференциальной.

Практическая рекомендация: полная копия еженедельно (воскресенье ночью) + инкрементальная или дифференциальная ежедневно. Хранить не менее 4 недель полных копий.

Современные инструменты (Restic, BorgBackup, коммерческие решения) автоматически работают с дедупликацией — вы получаете экономию инкрементального подхода при простоте полного.

Инструменты и решения

Серверы и инфраструктура

Open-source решения (бесплатно, размещение на своём сервере):

• Restic — быстрый, зашифрованный, с дедупликацией. Поддерживает объектные хранилища, SFTP, локальные диски. Хорошо документирован, активно поддерживается.
• BorgBackup — аналог Restic с отличной дедупликацией. Немного сложнее в настройке, но надёжен.

Оба инструмента упоминаются в брифе как допустимые open-source решения.

Российские коммерческие решения:

• Кибер Бэкап (Cyberprotect, ex-Acronis для корпоративного рынка) — комплексное решение для резервного копирования серверов, рабочих станций, виртуальных сред. Есть версия с сертификатами ФСТЭК.
• RuBackup — российская платформа корпоративного резервного копирования.
• Полибайт — российское решение для резервного копирования инфраструктуры.

Облачное хранилище для резервных копий

Российские объектные хранилища (S3-совместимые):

• Yandex Object Storage — S3-совместимое, надёжное, есть сервер-сайд шифрование.
• VK Cloud Storage (Mail.ru Cloud Solutions) — S3-совместимое объектное хранилище.
• Selectel Object Storage — аналогично, датацентры в России.
• Cloud.ru Object Storage — входит в экосистему Cloud.ru.

Все они совместимы с инструментами, работающими с S3-протоколом (Restic, BorgBackup, Кибер Бэкап).

SaaS-данные: отдельная история

Корпоративные сервисы хранят ваши данные, но не дают гарантий восстановления на нужную дату.

• Яндекс 360: встроенные инструменты хранения — не полноценный бэкап. Уточните у провайдера возможности резервирования и проработайте процесс ручного или автоматического экспорта критичных данных.

• 1С: как правило, имеет собственные механизмы выгрузки базы. Убедитесь, что выгрузка происходит автоматически, хранится вне сервера с 1С и периодически тестируется.

• Остальные SaaS: для сервисов без встроенного бэкапа — настройте регулярный ручной или API-экспорт. Задокументируйте, как и где хранятся экспорты.

Kubernetes и контейнеры

Velero — стандарт для резервного копирования Kubernetes. Создаёт снапшоты пространств имён и хранилищ, хранит в S3-совместимом хранилище. Для российских Kubernetes-платформ (Deckhouse, Yandex Managed Kubernetes, VK Cloud Kubernetes) — уточните совместимость и поддерживаемые провайдеры хранилищ.

Неизменяемые и изолированные копии: защита от шифровальщиков

Операторы шифровальщиков целенаправленно атакуют резервные копии. Если они могут их удалить — жертва вынуждена платить выкуп.

Неизменяемое хранилище (immutable storage)

Неизменяемое хранилище запрещает модификацию и удаление данных в течение заданного периода — даже для администраторов с полными правами доступа. Российские облачные провайдеры предоставляют аналог S3 Object Lock:

• Yandex Object Storage — поддерживает Object Lock с режимами Governance и Compliance для версионируемых бакетов (Yandex Cloud, документация).
• Selectel S3 — поддерживает временную и бессрочную блокировку объектов в режимах Governance и Compliance (Selectel, документация).
• VK Cloud Object Storage — поддерживает блокировку объектов (Object Lock) через retention period и legal hold для защиты от удаления и перезаписи (VK Cloud, документация).

Режим Governance допускает переопределение блокировки — но только для пользователя со специальной ролью администратора хранилища. Режим Compliance не допускает снятие блокировки никем, включая владельца аккаунта, до истечения установленного срока. Для защиты от шифровальщиков нужен именно Compliance: если атакующий получает полный доступ к облачному аккаунту, Governance-блокировку он теоретически может обойти, Compliance — нет.

Изолированные копии (air-gapped)

Физическая изоляция:

• Внешние диски, которые подключаются только во время резервного копирования, затем хранятся отдельно.
• Ленточные резервные копии, хранящиеся вне офиса.
• Ротация носителей: один диск в офисе (только что записан), другой — вне офиса (предыдущая запись).

Логическая изоляция:

• Резервное копирование в отдельный облачный аккаунт без сетевого пути из производственной среды.
• Бэкапы «вытягиваются» (pull), а не «толкаются» (push): система резервного копирования сама забирает данные, не имея обратного доступа к источнику.
• Учётные данные для записи и удаления — разные; сервис резервного копирования может только записывать.

Рекомендуемая архитектура

Производственная среда
        │
        ▼
[Первичный бэкап] ──────► Yandex Object Storage (основной аккаунт)
        │                  Ежедневно, хранение 30 дней
        │
        ▼
[Вторичный бэкап] ──────► Selectel / VK Cloud Storage (отдельный аккаунт)
        │                  Object Lock включён
        │                  Кросс-аккаунт, без права удаления
        │
        ▼
[Третичный бэкап] ──────► Изолированный носитель
                           Еженедельно, хранение вне офиса

Тестирование восстановления: ключевой элемент

Резервная копия не завершена, пока вы не восстановились из неё.

Почему тестирование обязательно

• Файлы бэкапа могут быть повреждены.
• Процедура восстановления могла измениться.
• Критичные данные могут быть упущены из охвата.
• Человек, знающий процедуру, может быть недоступен в момент катастрофы.

График тестирования

Тип теста	Частота	Что проверяем
Восстановление файла	Ежемесячно	Случайный файл из бэкапа в тестовую директорию
Восстановление БД	Квартально	Восстановление в тестовую среду, проверка данных
Восстановление системы	Ежегодно	Полное восстановление сервера или сервиса
Учения по катастрофе	Ежегодно	Симуляция полного сбоя, замер RTO/RPO

Как проводить тест восстановления БД

1. Создать тестовую среду — никогда не восстанавливать поверх рабочей.
2. Восстановить из бэкапа в тестовую среду.
3. Проверить целостность данных — сравнить количество записей, проверить дату последних транзакций, запустить smoke-тесты приложения.
4. Задокументировать результаты — время восстановления, ошибки, что нужно улучшить.

Учения по катастрофе (раз в год)

1. Выбрать некритичную систему или тестовую среду.
2. Смоделировать полное уничтожение оригинала — не трогать его во время учений.
3. Восстанавливать только из резервных копий.
4. Замерить фактические RTO и RPO.
5. Зафиксировать: что сработало, что было сложно, что отсутствовало.

Только так обнаруживаются пробелы, которые не видны при бумажном анализе.

Соответствие требованиям законодательства РФ

Если вы обрабатываете персональные данные или работаете с корпоративными клиентами — резервное копирование часто не просто хорошая практика, а требование закона.

152-ФЗ «О персональных данных»

Закон прямо не говорит «иметь резервные копии», но требует обеспечить возможность восстановления персональных данных в случае инцидента. Это автоматически означает:

• Бэкапы систем с ПДн обязательны. Любая система, где обрабатываются ПДн, должна резервироваться.
• Шифрование бэкапов. Приказ ФСТЭК № 21 требует шифрования ПДн — требование распространяется и на резервные копии.
• Локализация. Согласно 242-ФЗ, ПДн граждан РФ должны храниться на территории России — включая резервные копии. Российские облачные провайдеры (Yandex Cloud, VK Cloud, Selectel) обеспечивают хранение в российских датацентрах.
• Сроки хранения. Резервные копии подпадают под требования о сроках хранения и удаления ПДн — бэкапы не хранятся вечно.

Проблема права на удаление: субъект ПДн вправе потребовать удаления своих данных. Удалить конкретные записи из бэкапов технически сложно. Принятый подход: удалить из продуктивной системы немедленно, зафиксировать, что данные присутствуют в резервных копиях с конкретной датой истечения, при восстановлении — применить удаление повторно, не восстанавливать удалённые данные в продакшн.

Уведомление об утечке: если произошла утечка ПДн из резервных копий — уведомить Роскомнадзор (24 часа на факт, 72 часа на результаты расследования).

ГОСТ Р ИСО/МЭК 27001-2021 (СМИБ)

Российский стандарт, соответствующий международному ISO 27001. Приложение А содержит конкретные требования к резервному копированию:

Контроль A.12.3.1: требует регулярного создания и тестирования резервных копий данных, программного обеспечения и образов систем.

Что означает «регулярного тестирования»:

• Частота тестирования определена в политике (рекомендуется: ежемесячно).
• Результаты тестов документируются.
• Резервное копирование включено в область СМИБ и проходит внутренние аудиты.

Смежные контроли:

• A.8.2: классификация информации — сроки хранения бэкапов соответствуют классификации данных.
• A.11.1: физическая защита носителей резервных копий.
• A.12.4: логирование — доступ к резервным копиям должен журналироваться.

Аттестация по требованиям ФСТЭК России

Для компаний, которые проходят аттестацию или оценку соответствия по ФСТЭК (аналог SOC 2 в российском контексте), потребуются:

• Документированная политика резервного копирования.
• Журналы выполнения резервного копирования.
• Доказательства тестирования восстановления (с датами и результатами).
• Управление доступом к системам резервного копирования.
• Определённые и задокументированные RTO и RPO.

ГОСТ Р 57580.1 (для финансового сектора)

Если вы работаете с платёжными данными или относитесь к финансовому сектору — действуют требования ГОСТ Р 57580.1 (информационная безопасность финансовых организаций) и положения Банка России. Требования к резервированию существенно строже: непрерывность операций, короткие RTO, тестирование по утверждённому плану.

Сводная таблица требований

Требование	152-ФЗ	ГОСТ Р ИСО/МЭК 27001	Аттестация ФСТЭК	Ваш статус
Документированная политика	✓	✓	✓	☐
Шифрование в покое	✓	✓	✓	☐
Шифрование при передаче	✓	✓	✓	☐
Определённые сроки хранения	✓	✓	✓	☐
Задокументированные тесты	Косвенно	✓	✓	☐
Контроль доступа и журналирование	✓	✓	✓	☐
Хранение в РФ (для ПДн граждан РФ)	✓	—	—	☐
Определённые RTO/RPO	Косвенно	✓	✓	☐

Политика резервного копирования: документ

Создайте письменную политику — чтобы все знали план и он не зависел от памяти одного человека.

Шаблон политики

Готовый шаблон политики с графиком резервного копирования, правилом 3-2-1, RTO/RPO и ответственными.

DOCXПолитика резервного копирования

Шаблон из курса·Бесплатно·Открыть шаблон

Скачать DOCX

Все шаблоны — в библиотеке шаблонов.

Типичные ошибки

Резервная копия на том же сервере

Шифровальщик шифрует и сервер, и подключённый диск. Синхронизированные папки (как Яндекс.Диск, Google Drive в режиме синхронизации) — не резервная копия: они синхронизируют зашифрованные файлы так же исправно.

Исправление: бэкапы — на отдельных системах с отдельными учётными данными.

Нет копии вне офиса

Пожар, затопление, кража или сотрудник с административным доступом могут уничтожить локальные бэкапы.

Исправление: хотя бы одна копия в российском облаке.

Никогда не тестировали восстановление

Узнаёте, что бэкап не работает, именно тогда, когда он нужен.

Исправление: запланированные тесты с документацией результатов.

Бэкапят не то

Файловый сервер резервируется, а БД, SaaS-данные и конфиги — нет. После восстановления система не работает.

Исправление: полная инвентаризация данных до настройки чего угодно.

Нет мониторинга

Бэкапы падают тихо. Никто не замечает месяцами.

Исправление: автоматические оповещения при сбое задачи резервного копирования.

Ключ шифрования в одном месте

Пароль шифрования хранился на сервере, который зашифровали. Или знал только уволившийся сотрудник.

Исправление: ключи шифрования хранить в Пассворке (passwork.ru), доступны минимум двум уполномоченным людям. Бумажная копия в сейфе. Ежегодная проверка, что ключи работают.

Управление доступом к резервным копиям

Резервные копии часто содержат более чувствительные данные, чем продакшн — они снапшот всего. При этом доступ к ним — нередко самое слабое место.

Реестр доступа

Сотрудник	Роль	Уровень доступа	Дата выдачи	Последняя проверка
[Имя]	лидер безопасности	Полный (шифрование/дешифрование/восстановление)	—	—
[Имя]	DevOps-лид	Только чтение/восстановление	—	—
[Имя]	CTO	Экстренный доступ (запечатанные учётные данные)	—	—

Правила доступа

1. Минимально необходимый доступ. Большинству разработчиков доступ к резервным копиям не нужен.
2. Учётные данные бэкапа — отдельно от продакшн. Компрометация продакшн не должна давать доступ к резервным копиям.
3. Ревью ежеквартально. Удалять доступ уволившихся и сменивших роль.
4. Журналирование. Фиксировать, кто и когда обращался к резервным копиям.
5. Правило двух лиц для критичных данных. Для восстановления наиболее чувствительных данных — требовать подтверждения двух уполномоченных.

Управленческое задание

Блок 1 — инвентаризация и классификация (45 минут):

1. Составить полный список данных, требующих резервного копирования.
2. Классифицировать по приоритету: критичные, важные, стандартные, низкий.
3. Определить пробелы в текущем покрытии.
4. Зафиксировать, где физически хранятся каждый тип данных.

Блок 2 — настройка основного бэкапа (60 минут):

1. Выбрать инструмент (Restic/BorgBackup для open-source, Кибер Бэкап или аналог для коммерческого).
2. Настроить для критичных данных.
3. Задать расписание.
4. Убедиться, что первый бэкап выполнился успешно.
5. Задокументировать конфигурацию.

Блок 3 — вторичный и изолированный бэкап (45 минут):

1. Создать вторичное хранилище (другой провайдер или аккаунт).
2. Включить неизменяемость, если доступна.
3. Настроить репликацию из первичного.
4. Проверить, что резервная копия доходит до вторичного хранилища.

Блок 4 — тест восстановления (30 минут):

1. Взять случайный файл из резервной копии.
2. Восстановить в тестовую директорию.
3. Проверить содержимое.
4. Задокументировать процедуру восстановления.

Блок 5 — документация (30 минут):

1. Написать политику резервного копирования (шаблон выше).
2. Задокументировать процедуры восстановления.
3. Сохранить учётные данные в Пассворке.
4. Запланировать регулярные тесты восстановления.

Артефакты на выходе:

• Инвентарь данных составлен.
• Автоматические бэкапы работают для критичных данных.
• Вторичный или неизменяемый бэкап настроен.
• Первый тест восстановления проведён.
• Политика задокументирована, процедуры восстановления описаны.
• Учётные данные в Пассворке, мониторинг настроен.

✓Управленческий чек-лист

Охват резервного копирования

• Инвентарь данных для резервного копирования составлен.
• Производственные базы данных резервируются.
• Файловые серверы и хранилища резервируются.
• Критичные SaaS-данные включены в план.
• Конфигурации систем резервируются.

Реализация правила 3-2-1

• Не менее трёх копий критичных данных.
• Резервные копии на разных носителях или у разных провайдеров.
• Хотя бы одна копия в облаке (российский датацентр).
• Хотя бы одна неизменяемая или изолированная копия.

Автоматизация и мониторинг

• Резервное копирование выполняется автоматически по расписанию.
• Оповещение при сбое настроено.
• Журналы хранятся и проверяются.

Тестирование и документация

• Проведён хотя бы один тест восстановления.
• Политика резервного копирования задокументирована.
• Процедуры восстановления описаны.
• Учётные данные хранятся в Пассворке, доступны двум уполномоченным.
• График тестирования восстановления составлен.

Безопасность и соответствие требованиям

• Резервные копии зашифрованы (в покое и при передаче).
• Ключи шифрования хранятся отдельно от самих бэкапов.
• Для ПДн граждан РФ: хранение в российских датацентрах подтверждено.
• Сроки хранения определены и соблюдаются.
• Не менее двух сотрудников могут получить доступ к учётным данным резервного копирования.

Управление доступом

• Реестр доступа к резервным копиям актуален.
• Учётные данные бэкапа отличаются от продакшн.
• Процедура экстренного доступа задокументирована и протестирована.

Если закрыто 18 пунктов из 26 — можно двигаться дальше.

См. также

• Плейбуки реагирования — плейбук атаки шифровальщика
• Политики безопасности — как зафиксировать правила документом
• Соответствие требованиям — требования к хранению данных

Что дальше

Система резервного копирования выстроена. Осталась ещё одна быстрая победа из этого модуля.

Следующая глава: защита сайта — анти-DDoS и WAF — как защитить публичный сайт компании от атак, ботов и уязвимостей.