# Настройка резервного копирования данных: как убедиться, что бизнес восстановится
Редакция SGI24. Материал основан на практике SGI24 по сохранности данных и рекомендациях NIST и CISA. [О бюро](/company).
Резервная копия нужна не ради зелёной отметки в панели администратора. Она нужна, чтобы вернуть конкретный процесс после сбоя: открыть расписание, продолжить приём заявок, восстановить документы или снова провести оплату.
Поэтому настройка начинается не с выбора облака и объёма диска. Сначала руководитель отвечает, какие данные критичны, сколько информации допустимо потерять и как долго организация сможет работать без системы.
Если эти ответы не записаны, исполнитель может добросовестно копировать не то, слишком редко или в хранилище, которое исчезнет вместе с основной системой.
Разобрать резервное копирование
Что именно требуется сохранить
Фраза «мы копируем сервер» звучит убедительно, но мало что объясняет. На одном сервере могут находиться база, загруженные документы, настройки приложения, ключи интеграции и журналы. Для восстановления нужны не всегда те же компоненты, что занимают больше места.
Составляется реестр:
- рабочие базы данных;
- файлы клиентов и сотрудников;
- конфигурация приложений и серверов;
- документы и шаблоны;
- ключевые справочники;
- журналы, если они нужны для расследования и сверки;
- инструкции и доступы для запуска восстановления.
Для каждого пункта указываются владелец, источник, объём, частота изменения и зависимые процессы. Так обнаруживаются данные, которые годами лежат на рабочем компьютере одного сотрудника и не входят ни в одну копию.
Допустимая потеря данных и время восстановления
Два показателя переводят техническую задачу на язык бизнеса: сколько последних данных организация может потерять и за какое время систему нужно вернуть в работу.
Если заявки поступают постоянно, суточная копия означает риск потерять весь рабочий день. Если архив открывают несколько раз в год, более редкая копия может быть разумной.
Эти параметры часто называют RPO и RTO. Самих сокращений недостаточно. В проекте они записываются обычной фразой: «после сбоя теряем не более часа новых записей; рабочий доступ возвращается не позднее четырёх часов». После этого можно выбрать способ копирования и ресурс на восстановление.
Почему одна копия рядом с сервером не спасает
Копия на соседнем диске помогает при отказе одного накопителя. Она не защищает от шифровальщика, ошибки администратора, пожара, кражи оборудования или блокировки общей учётной записи.
Нужен отдельный контур. Хотя бы одна актуальная копия должна быть недоступна для обычного изменения из основной системы. Хранилища и учётные записи разделяются, права ограничиваются, удаление и изменение копий журналируются.
Для чувствительных сведений применяется шифрование. Ключ восстановления хранят отдельно от сервера, который может оказаться недоступным во время аварии.
Копия базы должна быть согласованной
Простое копирование файлов работающей базы может дать набор, который невозможно запустить. База меняется во время операции, а связанные файлы попадают в копию в разные моменты.
Используется штатный механизм резервирования конкретной системы или согласованный снимок. После создания проверяются завершение задания, размер, контрольная сумма и возможность прочитать архив.
Для связанного контура важно понимать порядок. Восстановленная CRM без документов или справочника 1С может открыться, но не вернуть процесс в рабочее состояние.
Проверка задания и проверка восстановления — разные вещи
Мониторинг подтверждает, что программа создала файл. Только восстановление подтверждает, что файл полезен.
Тест проводится в изолированном месте. Специалист разворачивает систему, запускает контрольный сценарий и сверяет несколько записей. Результат фиксируется: какая копия использована, сколько заняло восстановление, что не получилось и кто принял работу.
Частота теста зависит от риска. Критичные системы проверяются чаще. После крупных обновлений, смены хранилища или учётных записей внеплановая проверка особенно важна.
Кто узнает о неуспешной копии
Письмо на ящик одного администратора — слабая защита. У события должен быть ответственный, срок реакции и запасной маршрут.
Система различает неуспешное задание, слишком старую копию, нехватку места и отсутствие контрольного восстановления. Руководителю не нужны технические логи, но он должен видеть, что критичный процесс остался без подтверждённой защиты.
Уведомление закрывается только после понятного действия: копия восстановлена, выполнено новое задание или риск принят на ограниченный срок.
Облачные сервисы тоже требуют плана
Поставщик облака поддерживает свою инфраструктуру, но это не всегда означает восстановление удалённой пользователем записи, ошибочной массовой операции или данных из внешней интеграции.
Нужно проверить условия сервиса: срок хранения версий, способ выгрузки, время возврата, доступ после прекращения подписки и границы ответственности поставщика. Для критичных данных предусматривается независимая выгрузка в согласованном формате.
Что резервная копия решает, а что — нет
Резервное копирование не предотвращает все сбои и не заменяет защиту доступов, мониторинг и план непрерывности. Оно снижает последствия потери данных при условии, что копии изолированы и регулярно проверяются.
Мы не обещаем восстановление из копии, которую не удалось проверить. В отчёте ясно разделяются подтверждённые результаты, ограничения и действия заказчика.
Что получает заказчик
Резервное копирование можно заказать отдельно. В работу входят карта данных, требования к срокам, схема копий, роли, контроль заданий и проведённый тест восстановления. Инструкция объясняет, как действовать при типовых сбоях и кто имеет право запускать восстановление.
Результат не привязан к обязательной переделке сайта, CRM или всей инфраструктуры. Если требуется защитить одну критичную систему, граница проекта фиксируется вокруг неё.
Аудит ИТ-инфраструктуры: что получает руководитель
Какой участок можно защитить первым
На первом разборе мы выбираем один критичный процесс и идём от него к данным. Проверяем текущие задания, места хранения, права и последнюю попытку восстановления. Затем предлагаем минимальный контур и отдельно показываем дальнейшие улучшения.
Заказчик может приобрести только обследование, только настройку или только контрольное восстановление. Каждый блок имеет свой результат и принимается отдельно. Комплекс имеет смысл, когда одна система зависит от нескольких источников и их нужно возвращать в согласованном порядке.
Разобрать резервное копирование