IT-инфраструктура

Резервное копирование данных: правило 3-2-1, RPO и RTO

Дмитрий Савицкий — Системный архитектор
Дмитрий Савицкий Системный архитектор
29 мая 2026 · 1 мин чтения
Резервное копирование данных: правило 3-2-1, RPO и RTO

Резервное копирование данных — это создание и хранение копий информации, чтобы восстановить её после сбоя, ошибки, атаки или потери оборудования. Без бэкапа любой инцидент — выход из строя диска, шифровальщик, случайное удаление — может означать безвозвратную потерю данных. Надёжная стратегия резервного копирования строится по правилу 3-2-1 и регулярно проверяется тестовым восстановлением.

Ключевые выводы

  • Резервное копирование защищает данные от сбоев, атак и человеческих ошибок.
  • Правило 3-2-1: три копии, два носителя, одна копия вне площадки.
  • Бывает полным, инкрементным и дифференциальным.
  • Бэкап без проверки восстановления не считается надёжным.
  • Критичны два показателя — RPO (допустимая потеря данных) и RTO (время восстановления).
Правило 3-2-1
3
копии данных

оригинал + две резервные копии.

2
типа носителей

разные среды: диск + лента/облако.

1
копия офсайт

хранится вне основной площадки.

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

Резервное копирование — обязательный элемент надёжной IT-инфраструктуры предприятия. Разберём правило 3-2-1, виды бэкапа и как проверить, что данные действительно восстановятся.

Правило 3-2-1

Это базовый стандарт надёжного резервного копирования. Он прост и проверен практикой:

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

Хранение копии за пределами офиса хорошо сочетается с размещением в дата-центре, где обеспечены безопасность и резервирование.

Виды резервного копирования

ВидЧто копируетсяОсобенность
ПолноеВсе данные целикомНадёжно, но дольше и занимает много места.
ИнкрементноеТолько изменения с прошлого бэкапаБыстро и экономно, восстановление по цепочке.
ДифференциальноеИзменения с последнего полногоКомпромисс между скоростью и простотой восстановления.

RPO и RTO: два ключевых показателя

  • RPO (Recovery Point Objective): какой объём данных бизнес готов потерять. Если RPO — 1 час, бэкап должен делаться не реже раза в час.
  • RTO (Recovery Time Objective): за какое время сервис должен восстановиться. Чем меньше RTO, тем быстрее должна работать схема восстановления.

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

Защита от шифровальщиков

Современные вирусы-шифровальщики целенаправленно ищут и уничтожают резервные копии. Поэтому важны неизменяемые (immutable) бэкапы и копии, отключённые от сети (air gap). Раннее обнаружение атаки через мониторинг помогает остановить шифрование до того, как оно затронет резервные копии.

Проверка восстановления

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

Часто задаваемые вопросы о резервном копировании

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

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

Можно ли считать синхронизацию с облаком резервным копированием?

Нет, это разные вещи. Синхронизация мгновенно повторяет изменения на всех устройствах, поэтому удалённый или зашифрованный вирусом файл так же быстро «разъедется» по всем копиям. Резервная копия фиксирует состояние данных на момент времени, и к ней можно откатиться. Хранение версий и копия вне площадки — то, что отличает бэкап от обычной синхронизации.

Где безопаснее хранить копию вне площадки?

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

Нужно ли шифровать резервные копии?

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

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

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

Заключение

Резервное копирование данных — это страховка бизнеса от потери информации. Надёжная схема строится по правилу 3-2-1, учитывает RPO и RTO, защищена от шифровальщиков и регулярно проверяется восстановлением. Настроенный и протестированный бэкап превращает потенциальную катастрофу в управляемый инцидент.

Нужна надёжная защита данных? Genesis Systems спроектирует и внедрит резервное копирование данных по правилу 3-2-1 с проверкой восстановления. Свяжитесь с нами: +375 (17) 336-07-67, info@genesis-systems.by.

Остались вопросы?

Оставьте заявку — специалисты Genesis Systems оценят ваши данные и предложат схему резервного копирования.


    Нужна услуга, а не только теория? Genesis Systems оказывает «Резервное копирование данных» под ключ — от аудита до внедрения и сопровождения.

    Заказать услугу →

    Дмитрий Савицкий — Системный архитектор
    Об авторе

    Дмитрий Савицкий

    Системный архитектор

    Системный архитектор Genesis Systems. Проектирует системы защиты информации и IT-инфраструктуру, готовит объекты к аттестации по требованиям ОАЦ Республики Беларусь. Автор материалов блога об информационной безопасности и защите персональных данных.

    Поделиться: Telegram VK WhatsApp
    Читайте также

    Похожие статьи

    Нужна помощь по теме статьи?

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

    Связаться с нами