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

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

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

Зачем бизнесу нужен регламент резервного копирования?

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

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

Пример: Менеджер был уверен, что резервное копирование данных учетной системы выполняет администратор, а администратор считал, что «это уже настроено автоматически». В результате сбоя оказались потеряны рабочие документы за несколько дней.

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

Пример: Компания в течение года исправно делала резервные копии на внешний диск. Когда потребовалось восстановить данные, диск не смонтировался из-за скрытой ошибки файловой системы, о которой никто не знал.

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

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

• Риски нарушения законодательства. Закон о персональных данных (152-ФЗ) и требования к бухгалтерскому учету часто прямо обязывают организации иметь письменную политику восстановления информации.

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

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

Масштаб проблемы: немного статистики

В 2024–2025 годах российский бизнес столкнулся с рекордным ростом инцидентов, связанных с шифровальщиками, человеческим фактором и отказами оборудования. По данным отраслевых отчетов (ФСТЭК, Positive Technologies, Group-IB), более 68% средних и крупных компаний РФ хотя бы раз за год сталкивались с попыткой шифрования данных, а среднее время восстановления без формализованного процесса превышало 10–14 суток. При этом прямой ущерб от простоя для российского среднего бизнеса оценивается регуляторами от 500 тыс. до 3 млн рублей в час.

Несмотря на это, данные опросов показывают, что системный подход к резервному копированию до сих пор не является нормой:

• Согласно исследованию, 26% компаний вообще не выполняли непрерывное резервное копирование, а 39% делали резервные копии лишь примерно 25% своих данных. Полную копию всех данных на регулярной основе создавали только 6% респондентов.
• В исследовании Linx Cloud и Global CIO, ситуация с планами восстановления после сбоев (Disaster Recovery, DR) выглядит так: 20% компаний имеют формализованную и регулярно тестируемую DR-стратегию, 38% обладают только базовыми документами без практической проверки, 42% не имеют DR-плана вовсе.

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

Как превратить разрозненное копирование в надежную систему, которая восстановит бизнес за часы, а не недели? Ответ очевиден — нужен четкий, закрепленный и регулярно тестируемый регламент резервного копирования.

Ниже мы разберем, из чего состоит регламент, как его правильно сформировать и заполнить.

Структура документа – из чего состоит регламент

Раздел 1. Область действия, цели и метрики восстановления

В данном разделе определяются защищаемые системы (ERP, CRM, файловые шары, корпоративная почта) и целевые показатели их восстановления. Первоочередная задача — выделить критичные данные и классифицировать информацию по степени важности для бизнеса.

Категории данных по важности:

1) Критичные (RTO < 4 часа): данные, потеря или недоступность которых останавливает основные бизнес-процессы. Сюда относятся базы 1С, CRM-системы, файлы с договорами и персональные данные клиентов (ПДн).
2) Важные (RTO < 24 часа): системы, чей простой ощутим, но не критичен в первые часы. Например: почта, корпоративный портал, данные о складских остатках.
3) Второстепенные (RTO > 24 часов): данные, влияющие на удобство работы, но не на выживание бизнеса. Типичные примеры — личные папки сотрудников и архивы маркетинговых материалов.

Пример: Для интернет-магазина критичны заказы и актуальные цены. Потеря фотографий товаров — неприятна, но не фатальна, поэтому такие данные можно отнести к второстепенным.

Чтобы план восстановления работал, необходимо задать две основные метрики для каждого типа данных:

• RPO (Recovery Point Objective) — допустимый объем потери данных во времени. Иными словами, насколько устаревшей копией можно обойтись.

Пример: Для интернет-магазина RPO = 15 минут (потеря содержимого корзин покупок за последние 15 минут признается допустимой). Для архива документов RPO может составлять 24 часа (допустимо потерять изменения за сутки).

• RTO (Recovery Time Objective) — целевое время простоя системы, то есть сколько времени система может оставаться недоступной с момента сбоя.

Пример: Для кассового сервера RTO = 2 часа — превышение этого срока приведет к сбою в работе точек продаж. Для внутреннего портала с отзывами RTO = 24 часа, так как его отсутствие не парализует основные операции компании.

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

• Метрики RTO и RPO: как обеспечить непрерывность бизнеса
• Лучшие практики: RTO и RPO
• Чек-лист «Как проверить RTO/RPO»

Раздел 2. Роли, ответственность и процедура утверждения

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

Пример назначения ролей:

• Ежедневный запуск резервного копирования выполняет ИТ-специалист (ФИО)
• Ежемесячную проверку возможности восстановления проводит другой ИТ-специалист (ФИО)
• На случай отпуска или болезни первого резервным ответственным назначается старший администратор (ФИО)

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

Например: Акт об успешном резервном копировании подписывает руководитель ИТ-отдела не позднее 10:00 следующего рабочего дня.

Раздел 3. Расписание, типы копирования и правила хранения резервных копий

В данном разделе фиксируется частота создания копий (например, ежечасная или ежедневная), а также типы резервного копирования: полное (копируются все данные целиком) и инкрементное (копируются только изменения, накопленные с момента последней копии любого типа).

Пример расписания:

• Полная копия всех баз данных — каждое воскресенье в 02:00.
• Инкрементная копия (изменения с момента предыдущей любой копии) — каждый час с 09:00 до 20:00.

Более подробно о типах резервного копирования писали в статье «Методы резервного копирования данных: полный, инкрементный, дифференциальный»

Важно: окно резервного копирования не должно накладываться на периоды пиковой нагрузки на систему. 

Например, если складской комплекс активно работает с 22:00 до 23:00, категорически не рекомендуется запускать полное резервное копирование WMS (системы управления складом) в 22:30 — это приведет к деградации производительности и возможным сбоям.

Золотое правило резервного копирования: «3-2-1»

Для обеспечения надежности резервного копирования применяется правило «3-2-1»

1) Три копии данных — одна рабочая (основная) и две резервные.
2) Два разных типа носителей — например, основной SSD-диск сервера + внешний HDD или ленточная библиотека. Это защищает от одновременного выхода однотипных устройств.
3) Одна географически удаленная копия — размещается в другом офисе, ЦОДе в ином регионе РФ или облачном хранилище. Такая копия сохранит данные при пожаре, затоплении или краже в основной локации.

Более подробно правило резервного копирования разбирали в этих статьях:

• Правило «3-2-1» в резервном копировании: надёжная стратегия защиты данных
• Правило «3-2-1»: достаточно ли его сегодня для защиты от реальных угроз?

Сроки хранения резервных копий (Retention Period)

Сроки зависят от типа данных, содержащихся в резервной копии. Например, бухгалтерия и договоры должны храниться 5 лет (ГК РФ, Налоговый кодекс РФ), кадровые документы и личные дела сотрудников — 50-75 лет (Закон об архивном деле, 125-ФЗ), а персональные данные сотрудников — 3-5 лет. 

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

Пример настройки хранения

Рекомендуемая политика ротации и геораспределения:

• Ежедневные копии — хранить 7 дней (для быстрого отката на день-два)
• Еженедельные копии — хранить 1 месяц (для восстановления состояния недельной давности)
• Ежемесячные копии — хранить 1 год (для аудита и долгосрочных запросов)
• Одна ежемесячная копия — обязательно выгружается в облачное хранилище (например, S3-совместимое: Яндекс Облако, VK Cloud и т.п.) для выполнения правила «3-2-1» и обеспечения геораспределенного хранения

Более подробно о сроках хранения резервных копий писали в статье «Как определить оптимальные сроки хранения резервных копий?»

Все перечисленные параметры (типы носителей, сроки, ротация) должны быть зафиксированы в регламенте резервного копирования и регулярно проверяться на соответствие законодательству.

Раздел 4. Процедура восстановления данных

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

Пример 1. Случайное удаление файла пользователем

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

Пример 2. Полный отказ дискового массива (аппаратная авария)

Руководитель ИТ-службы официально объявляет режим аварии. В течение 2 часов ИТ-специалисты разворачивают резервную систему на подготовленном резервном оборудовании, используя полную копию данных. Затем, после запуска базовой системы, каждый час данные восстанавливаются из инкрементных копий, чтобы минимизировать потерю данных.

Требование к каналу связи и ответственным

При любой аварии (от сбоя одного файла до выхода из строя массива) первое сообщение должно быть отправлено на установленный адрес электронной почты или в соответствующий канал в корпоративном чате. Ответственный за отправку — сотрудник, обнаруживший проблему. Это является единственным официальным способом оповещения для ИТ-команды.

Раздел 5. Контроль и аудит резервного копирования

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

Обязательное правило: раз в 3 месяца проводятся плановые учения. Для этого в тестовом (не боевом) контуре намеренно удаляется папка, база данных или набор файлов, после чего ИТ-специалист восстанавливает их из резервной копии по реальной процедуре.

Пример исполнения

Каждый первый вторник квартала (раз в три месяца) назначенный ИТ-специалист выборочно восстанавливает 5 случайных файлов из каждого набора резервных копий по отдельности:

• Файловый сервер
• База 1С
• CRM-система

Результат аудита — служебная записка, в которой перечислены проверенные наборы копий, время восстановления и выявленные замечания. Записка обязательно подписывается начальником ИТ-отдела и хранится в папке с документацией по резервному копированию.

Раздел 6. Действия при сбоях процесса резервного копирования

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

Пример сценария «Резервная копия не создалась»

Если автоматическое задание резервного копирования завершилось с ошибкой (что зафиксировано в журналах логов), система через 15 минут отправляет уведомление ИТ-специалисту по установленному адресу электронной почты или в соответствующий канал в корпоративном чате. ИТ-специалист обязан в течение 1 часа:

1) Установить и устранить причину сбоя (например, нехватка места, проблемы с сетью, остановленная служба)
2) Вручную запустить план резервного копирования для создания внеочередной копии

Пример сценария «Резервная копия повреждена»

Если в ходе ежеквартальных учений (см. раздел 5) или при проверке контрольных сумм выяснилось, что резервная копия испорчена и восстановление невозможно, ИТ-специалист инициирует создание новой полной копии текущих данных, не дожидаясь следующего планового окна. Старая поврежденная копия не удаляется до момента успешного создания новой полной копии и ее проверки.

Примеры из российской практики (по отраслям)

Банк (регулируется ЦБ РФ)

Требования к резервному копированию прописаны в нормативах Банка России. Пример реализации:

• Резервное копирование баз данных выполняется каждые 30 минут
• Срок хранения резервных копий — 5 лет
• Копии хранятся одновременно в двух географически распределенных центрах обработки данных (ЦОД), например, в Москве и Екатеринбурге
• Раз в месяц проводится плановое отключение основного узла обработки данных: ИТ-система должна полностью переключиться на резервный ЦОД и работать от него без остановки бизнес-процессов

Медицинская клиника (персональные данные — ПДн пациентов)

Здесь критичны долгосрочное хранение и защита от утечки. Пример:

• Ежедневное шифрованное копирование электронных медицинских карт на выделенный стойкий сервер внутри клиники
• Раз в неделю — экспорт данных на LTO-ленту (магнитная лента для долговременного архивного хранения). Лента вывозится и помещается в опечатанный сейф, который расположен в другом кабинете (физическая изоляция от основного сервера)
• Срок хранения истории болезни одного пациента — 50 лет согласно законодательству об охране здоровья

Промышленное предприятие (объект КИИ)

Важна не просто копия данных, а непрерывность работы оборудования. Пример:

• Создаются не только резервные копии данных, но и резервируется оборудование — полностью дублирующие серверы, контроллеры, дисковые полки (hot-standby)
• Даже при внезапном выходе из строя основной дисковой полки система управления станком с ЧПУ не останавливается: автоматическое переключение на резервное оборудование происходит без участия оператора и без прерывания производственного цикла

Чек-лист для разработки и проверки регламента

Данный чек-лист можно использовать при создании регламента и при его ежегодной актуализации.

Как использовать чек-лист: если по какому-то пункту статус «Нет» — инициируем изменение регламента. Заполненный чек-лист подписывает руководитель ИТ и утверждает гендиректор (или руководитель службы ИБ).

Заключение

Наличие регламента переводит резервное копирование из зоны ответственности отдельных инженеров в плоскость контролируемых бизнес-процессов. Документ фиксирует измеримые метрики RPO/RTO, закрепляет зоны ответственности за сотрудниками и определяет четкий алгоритм действий при авариях. Регулярная актуализация регламента по чек-листу и проведение тестовых проверок гарантируют, что ИТ-инфраструктура компании будет восстановлена в заданные сроки при любом сценарии сбоя.