Вернуться к статьям Задача резервной копии — вернуть согласованный набор данных и функций в приемлемый срок. Для личного кабинета и B2B-портала проверяют учётные записи, документы, заявки, права и настройки интеграций: один архив редко закрывает всё.
Сначала определить, что именно требуется вернуть
Инвентаризация начинается не с настройки панели хостинга, а с перечня компонентов. Для каждого из них фиксируют источник, способ резервирования и проверку после восстановления.
| Компонент | Что уточнить | Как проверить после восстановления |
|---|---|---|
| Файлы сайта | Код, шаблоны, загруженные документы, изображения | Открываются ключевые страницы и файлы |
| База данных | Контент, настройки, заявки, учётные записи | Сайт подключается к базе, администратор входит в панель |
| Конфигурация | Переменные окружения, настройки почты, очередей, кеша | Приложение запускается без ручного поиска параметров |
| Внешние сервисы | CRM, почта, платёжный сервис, карты, DNS, файловое хранилище | Проверяется отдельный сценарий или документированный порядок подключения |
| Доступы | Учётные записи, права, домен, хостинг, хранилище | Ответственные могут получить доступ по регламенту |
Файлы и база данных часто создаются и сохраняются разными механизмами. Если время их создания не согласовано, после восстановления можно получить сайт с одной версией файлов и другой схемой базы. Для конкретной платформы и инфраструктуры порядок сборки и восстановления должен подтвердить технический специалист.
Отдельно отмечают данные вне копии сайта. Запись в облачной CRM, настройка доменного регистратора или история у платёжного провайдера не появятся в архиве веб-сервера. Для таких систем нужен самостоятельный порядок экспорта, хранения и восстановления.
Частота копирования зависит от допустимой потери данных
Нет универсального расписания, подходящего всем. Сайт с несколькими статичными страницами меняется редко, а на портале с заявками и документами новые данные появляются весь день. Руководитель должен определить две границы: насколько свежими должны быть восстановленные данные и сколько времени допустим простой. Техническая команда подбирает схему под эти требования, объём проекта и возможности хостинга.
Полезно сформулировать это без терминов: насколько свежими должны быть данные после сбоя и когда должен заработать ключевой сценарий. Затем проверяют, соответствует ли этому расписание копий и фактическое время развёртывания.
Перед обновлением ядра, модулей, шаблона или интеграции делают контрольную копию. Она не заменяет тестовую среду и не доказывает совместимость доработок с новой версией.
Где хранить архивы и как управлять доступом
Копия рядом удобна при удалении файла. При недоступности сервера или атаке она может оказаться недоступной одновременно с сайтом. Поэтому для значимых систем предусматривают независимое хранилище. Схема зависит от модели угроз, договоров с поставщиками и требований к данным.
Доступ к резервам не должен держаться на одном человеке. Нужны владелец процесса, резервный ответственный и маршрут для экстренного получения прав. Широкая раздача прав на удаление архивов создаёт другую проблему: можно потерять и рабочую версию, и резервную.
Пароли, ключи и полные выгрузки с персональными данными не включают в журнал проверок и не пересылают в рабочих чатах. В регламенте достаточно указать место хранения секретов, круг лиц с доступом и способ подтверждения доступа. Требования к защите и срокам хранения персональных данных нужно сверять с юристом и ответственным за обработку данных: они зависят от состава информации и процессов компании.
Архив нужно восстановить до аварии
Успешная строка в журнале резервного копирования подтверждает только создание файла. Она не отвечает, читается ли архив, подходит ли пароль, хватает ли прав, запускается ли база и работают ли критичные сценарии. Проверку проводят на изолированном контуре, чтобы не изменить боевую базу, не отправить письма клиентам и не создать реальные заявки.
Минимальный сценарий тестового восстановления обычно выглядит так:
- выбрать конкретную копию и зафиксировать её идентификатор и дату;
- развернуть файлы и базу на отдельной среде;
- подключить необходимые параметры без публикации тестового сайта в поиске;
- открыть ключевые страницы, административную часть и личный кабинет, если он есть;
- проверить форму или иной основной сценарий с безопасными тестовыми реквизитами;
- проверить интеграции в тестовом режиме либо зафиксировать, какие из них требуют ручного включения;
- записать фактическое время, ручные действия и найденные ошибки.
Полный список зависит от сайта. Интернет-магазину важны каталог, корзина, заказ и обмен остатками. Сервисной компании — форма заявки, письма и передача обращения в CRM. Для корпоративного сайта достаточно других проверок, но «главная страница открылась» всё равно не заменяет тест формы и прав редактора.
Типовые причины, по которым бэкап не спасает
В архив попали только файлы
Страницы могут открыться, но контент, пользователи, настройки и обращения обычно зависят от базы данных. Состав копии проверяют на развернутом тестовом контуре, а не по названию пункта в панели хостинга.
Копия существует только на рабочем сервере
Такой вариант может ускорить простое восстановление, но не защищает от проблем с этим сервером или его учётной записью. Нужна хотя бы одна независимая версия, порядок доступа к ней и проверка, что доступ действительно работает.
Никто не проверял восстановление
Даже корректно созданный архив может оказаться неполным, зашифрованным неизвестным паролем или рассчитанным на другое окружение. Тест развёртывания показывает проблему заранее, когда её можно устранить без простоя.
Внешние зависимости остаются за скобками
После возврата сайта могут не заработать DNS, почта, CRM, платёжный модуль или файловое хранилище. Для каждой критичной зависимости нужно определить владельца, контакты и действия при возвращении в работу. Резервная копия сайта не подменяет планы поставщиков.
Восстановление сразу запускают в боевой среде
Так можно перезаписать актуальные данные или отправить повторные уведомления. Сначала проверяют изолированное развёртывание, сопоставляют время копии с данными, которые нельзя потерять, и только потом принимают решение о работах в продакшене.
Минимальный регламент для руководителя
Передать подрядчику вопрос «делаются ли бэкапы?» недостаточно. Гораздо полезнее запросить документ с пятью ответами:
- какие компоненты сайта входят в копию, а какие живут во внешних системах;
- где лежат независимые копии и кто управляет доступом;
- как выбирается частота резервирования и сколько данных допускается потерять;
- когда последний раз выполняли тестовое восстановление и какие сценарии прошли;
- кто действует при инциденте и где находится инструкция.
Они нужны, чтобы границы ответственности и последовательность действий были известны до инцидента.
FAQ
Достаточно ли резервных копий, которые делает хостинг?
Это можно оценить только по составу, срокам хранения, способу доступа и реальному тесту восстановления. Запросите у хостинга описание услуги и проверьте отдельную копию на безопасном контуре.
Нужно ли хранить архивы на самом сервере сайта?
Локальная копия может быть удобной, но не должна оставаться единственной. При проблеме с сервером или доступом к нему она может стать недоступной вместе с сайтом.
Как часто нужно проверять восстановление?
Периодичность определяют по риску и частоте изменений. Вне графика тест повторяют после смены хостинга, изменения архитектуры, схемы резервирования или важной интеграции.
Попадают ли данные из CRM в бэкап сайта?
Не обязательно. Если CRM работает как внешняя система, для неё нужен отдельный порядок экспорта и восстановления, согласованный с возможностями сервиса.
Защищает ли бэкап от взлома?
Копия может помочь вернуть систему после части инцидентов, но она не заменяет обновления, ограничение прав и разбор причины нарушения. Перед восстановлением оценивают состояние архива и безопасный порядок дальнейших действий.
Итог
Надёжность резервной копии подтверждает не факт создания архива, а проверенное восстановление. Для сайта нужен перечень компонентов, независимое хранение, контролируемый доступ, тестовый сценарий и журнал результата. После этого бэкап становится частью регламента восстановления, а не неизвестным файлом на сервере.