Резервное копирование для бизнеса: правило 3-2-1 и как оно работает на практике

Зачем бизнесу резервное копирование и почему копии файлов недостаточно

В бытовом понимании бэкап – это когда важные файлы время от времени копируют на другой диск, флешку или в облако. Для организации такой подход недостаточен. Резервное копирование – это управляемый процесс создания и хранения копий данных, из которых критичные системы можно восстановить после сбоя, ошибки сотрудника, повреждения оборудования или кибератаки.

Ключевой вопрос здесь не в том, есть ли где-то копия файла, а в том, можно ли из нее восстановить рабочую систему и сколько времени это займет.

Например, ежедневная копия базы может выглядеть надежной защитой. Но если после аварии выяснится, что последняя пригодная точка восстановления была создана сутки назад или развертывание системы занимает восемь часов при допустимом простое в два часа, схема резервного копирования не выполняет требования бизнеса.

Поэтому перед выбором ПО и хранилища нужно определить четыре вещи:

• какие данные и системы действительно критичны;
• сколько изменений допустимо потерять;
• сколько времени может занимать восстановление;
• сохранится ли хотя бы одна рабочая копия при отказе основной инфраструктуры или атаке.

RPO и RTO: сколько данных можно потерять и сколько можно простаивать

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

RPO – допустимая потеря данных

RPO, Recovery Point Objective – точка во времени, до которой необходимо восстановить данные после сбоя.

На практике RPO отвечает на вопрос: насколько старой может быть последняя пригодная точка восстановления?

• Если для системы установлен RPO в один час, после аварии должна существовать возможность вернуться к состоянию данных не старше одного часа.
• Если резервная копия создается только раз в сутки, такая схема это требование не выполняет.

RTO – допустимое время восстановления

RTO, Recovery Time Objective – время, за которое критичная система должна быть восстановлена после сбоя.

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

В этом случае резервное копирование работает, а требования к восстановлению – нет.

Именно поэтому RPO и RTO должны определяться до настройки расписаний и выбора хранилища. Для файлового архива и транзакционной базы они могут отличаться в разы.

Правило 3-2-1: базовый принцип резервного копирования

Правило 3-2-1 остается простой и понятной основой построения резервного контура:

• 3 экземпляра данных – рабочие данные и две дополнительные копии.
• 2 независимых места или типа хранения – отказ одного оборудования не должен уничтожить одновременно все экземпляры.
• 1 копия вне основной площадки – локальная авария не должна затронуть всю систему резервирования.

Например, если рабочий сервер и backup-хранилище находятся в одной серверной, такая схема может защитить от отказа отдельного диска или сервера, но не от пожара, затопления или другой аварии всей площадки.

Правило 3-2-1 снижает риск одновременной потери рабочих данных и резервных копий, но в современных инфраструктурах его часто дополняют дополнительными уровнями защиты.

Что означает правило 3-2-1-1-0

В практике резервного копирования используется расширенная схема 3-2-1-1-0.

Дополнительная 1 означает еще одну копию, которую нельзя изменить из основной инфраструктуры либо которая физически от нее изолирована.

Это может быть:

• offline-копия;
• ленточный носитель;
• физически изолированный репозиторий;
• immutable-хранилище с запретом изменения данных в течение заданного срока.

Такой уровень особенно важен при защите от ransomware. Рекомендации CISA предусматривают хранение критичных резервных копий offline, их защиту и регулярную проверку возможности восстановления.

0 означает отсутствие ошибок после проверки восстанавливаемости.

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

Что именно нужно резервировать

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

В него могут входить:

• виртуальные машины;
• физические серверы;
• файловые ресурсы;
• базы данных;
• 1С и другие бизнес-приложения;
• службы каталогов;
• конфигурации критичных систем;
• данные отдельных рабочих станций;
• данные облачных сервисов.

Не все системы требуют одинаковой защиты.

Например, архив документов может допускать RPO в сутки, а для активно изменяющейся базы этот показатель может быть значительно меньше. Поэтому копировать всю инфраструктуру по одному расписанию только ради удобства администрирования неправильно.

Полный, инкрементальный и дифференциальный бэкап

Основные типы резервного копирования различаются объемом сохраняемых данных и зависимостью между точками восстановления.

Универсального расписания вроде «полная копия раз в неделю, инкрементальная каждый день» не существует.

Схема определяется RPO, RTO, объемом ежедневных изменений, производительностью сети и хранилищ, доступным окном резервного копирования и глубиной хранения.

Где хранить резервные копии

Выбирать хранилище лучше не по принципу «куда помещаются данные», а по тому, от какого риска оно должно защитить.

Копия на другом виртуальном диске того же физического сервера не защищает от отказа самого хоста. Аналогично backup-сервер в той же серверной не закрывает риск потери всей площадки.

В корпоративных инфраструктурах могут использоваться дисковые репозитории, NAS и СХД, объектные хранилища, облачные площадки, ленточные библиотеки и offline-носители.

Часто разные уровни хранения используются одновременно, потому что быстрое восстановление и долгосрочная защищенная копия решают разные задачи.

Почему простого копирования файлов может быть недостаточно

Для документов обычной файловой копии иногда достаточно. Для работающих приложений и СУБД ситуация сложнее.

В момент создания копии часть информации может находиться:

• в открытых файлах;
• в памяти приложения;
• в журнале транзакций;
• в нескольких взаимосвязанных файлах базы.

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

В Windows для получения согласованного состояния данных используется, в частности, Volume Shadow Copy Service. VSS координирует работу приложения, системы резервного копирования и хранилища.

В зависимости от конкретной информационной системы могут применяться:

• VSS;
• application-aware backup;
• штатные механизмы СУБД;
• дампы;
• журналы транзакций;
• специализированные агенты и API.

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

Как защитить резервные копии от шифровальщика

Backup-сервер нельзя считать защищенным только потому, что он предназначен для резервного копирования.

Если злоумышленник получает административные права и может из основной инфраструктуры удалить или изменить содержимое backup-репозитория, резервные копии также становятся частью зоны атаки.

При проектировании защиты нужно проверить:

• кто имеет право удалять резервные копии;
• используются ли отдельные административные учетные записи;
• доступен ли репозиторий обычным пользователям и серверам;
• есть ли offline- или immutable-уровень;
• защищена ли конфигурация самой backup-системы;
• можно ли восстановиться при полной недоступности основной площадки.

Неизменяемое хранилище также не является универсальной гарантией. Нужно правильно выбрать срок неизменяемости и глубину хранения, чтобы после обнаружения атаки сохранилась чистая точка восстановления.

Как проверить, что резервная копия действительно работает

Один из самых важных этапов резервного копирования – тестовое восстановление.

Для критичной системы проверка может выглядеть так:

1. Выбрать конкретную точку восстановления.
2. Развернуть систему в изолированной среде.
3. Проверить запуск операционной системы или виртуальной машины.
4. Запустить приложение.
5. Проверить работоспособность базы данных.
6. Убедиться в доступности нужных данных.
7. Зафиксировать фактическое время восстановления.
8. Сравнить его с установленным RTO.

Такой тест отвечает сразу на два вопроса: работает ли резервная копия и успеет ли компания восстановиться за допустимое время.

Для критичных систем результаты проверок лучше документировать: дата теста, выбранная точка, результат восстановления, фактическое время и обнаруженные проблемы.

Статус «backup успешно завершен» такой информации не дает.

5 ошибок, из-за которых бэкап не спасает при аварии

1. Копии создаются, но никогда не восстанавливаются

Успешное выполнение задания подтверждает создание копии, но не работоспособность восстановленной системы.

2. Все копии зависят от одного оборудования

Резервная копия на другом диске того же физического сервера не спасет при отказе самого хоста.

3. Резервирование выполняется вручную

Если процесс зависит от того, вспомнил ли администратор скопировать данные в конце недели, его нельзя считать надежной системой резервного копирования.

4. У backup-инфраструктуры слишком широкие права доступа

Компрометация одной административной учетной записи не должна позволять одновременно уничтожить рабочие данные и все резервные копии.

5. Не учитывается специфика приложений

Для работающих СУБД и информационных систем могут потребоваться специальные механизмы создания согласованной точки восстановления. Простого копирования файлов бывает недостаточно.

Как самостоятельно проверить резервное копирование в компании

Для первичного аудита ответьте на десять вопросов:

• Какие системы критичны для работы компании?
• Какой RPO установлен для каждой из них?
• Какой RTO требуется?
• Где физически находятся резервные копии?
• Есть ли копия вне основной площадки?
• Есть ли offline- или immutable-копия?
• Кто может изменить или удалить резервные данные?
• Как контролируются ошибки заданий?
• Когда последний раз выполнялось тестовое восстановление?
• Сколько времени оно заняло?

Если известно, что «бэкап выполняется каждый день», но никто не может назвать RPO, RTO и дату последнего успешного восстановления, резервное копирование пока нельзя считать полностью управляемым процессом.

Нужно ли менять систему резервного копирования в 2026 году

Не обязательно. Если действующая система поддерживается, защищает необходимые нагрузки, позволяет выполнить требования по RPO и RTO и обеспечивает нужную изоляцию копий, менять ее только ради нового продукта нет смысла.

Пересмотреть архитектуру стоит, если:

• появились платформы или приложения, которые текущая система не защищает;
• значительно вырос объем данных;
• перестал выполняться RPO;
• восстановление не укладывается в RTO;
• резервные копии невозможно надежно изолировать;
• действующее ПО перестало получать необходимую поддержку;
• инфраструктура изменилась, а схема резервирования осталась прежней;
• тестовое восстановление никогда не выполнялось.

Для инфраструктур, где требуется российская система резервного копирования, в качестве возможных решений могут рассматриваться, например, Кибер Бэкап и RuBackup.

Это лишь примеры платформ. Конкретную СРК необходимо оценивать по поддержке используемых гипервизоров, ОС, СУБД, хранилищ и необходимых сценариев восстановления.

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

Частые вопросы

Как часто нужно делать резервные копии?

Частота определяется RPO. Если компания допускает потерю изменений максимум за один час, схема должна обеспечивать точки восстановления, позволяющие выполнить это требование. Для другой системы приемлемым может быть RPO в сутки.

Сколько времени нужно хранить резервные копии?

Единого срока нет. Он зависит от требуемой глубины восстановления, объема хранилища, внутренних политик и нормативных требований. Для разных систем внутри одной организации сроки могут отличаться.

Нужно ли делать резервные копии данных, которые уже находятся в облаке?

Сам факт размещения данных в облаке не означает автоматически, что требования по резервному копированию выполнены. Нужно проверить, какие механизмы предоставляет конкретный сервис: snapshots, versioning, soft delete, retention, встроенный backup, а также соответствуют ли они вашим RPO и RTO.

Спасает ли резервное копирование от шифровальщика?

Резервные копии позволяют восстановить данные после атаки, если сохранилась пригодная точка восстановления и злоумышленник не смог уничтожить все экземпляры. Поэтому важны изоляция, ограничение прав, offline- или immutable-копия и регулярное тестирование восстановления.

Чем резервное копирование отличается от репликации?

Репликация поддерживает дополнительный экземпляр данных или системы и помогает быстро переключиться при отказе. Но ошибочное удаление, повреждение или вредоносное изменение данных также может быть передано на реплику.

Резервное копирование сохраняет отдельные точки во времени, к которым можно вернуться. Поэтому репликация и backup решают разные задачи и могут использоваться совместно.

Главное

Надежность резервного копирования определяется не количеством терабайт в backup-хранилище и не числом успешно завершенных заданий.

После аварии важны три вопроса:

• Какая точка восстановления доступна?
• Можно ли из нее действительно восстановить систему?
• Сколько времени это займет?

Если ответы известны и подтверждены тестовым восстановлением, резервное копирование выполняет свою задачу. Если нет – наличие ежедневных копий само по себе еще не означает готовность бизнеса к серьезному сбою.

Смотрите видео-гайд

В видео показываем практическую сторону резервного копирования на примере одной из СРК: создание задания, выбор данных для защиты, настройку расписания и выбор хранилища для выполнения правила 3-2-1.

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