Какие резервные копии нужны бизнесу

Качественный бэкап — это стандарт любой онлайн-работы. Онлайн-бизнес нуждается в резервных копиях файлов, базы данных, настроек сервера, а также почты и пользовательских документов. Частота снятия копий зависит от допустимой потери данных, а срок хранения должен позволять вернуться к состоянию до ошибки. Копии следует размещать вне основного сервера и проверять восстановлением. Для внешнего размещения можно рассмотреть облачный бэкап Maxiplace, предварительно согласовав состав данных и условия восстановления.

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

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

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

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

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

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

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

Зафиксируйте конфигурации веб-сервера, версии PHP и СУБД, расширения, задания планировщика, правила сетевого доступа и параметры подключения к внешним сервисам. Отдельно сохраните DNS-записи и инструкцию развёртывания.

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

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

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

Определите допустимый промежуток потери данных — RPO, Recovery Point Objective. Если бизнес может потерять максимум час работы с заказами, то ежедневного копирования базы недостаточно. Потребуются более частые копии или сохранение журналов транзакций с возможностью восстановления на выбранный момент.

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

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

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

Храните копии в отдельном хранилище, желательно на другой площадке. Защитите хотя бы одну копию от изменения и удаления: используйте неизменяемое хранение либо отключённый носитель. Разделите доступы к сайту и бэкапам. Обычная синхронизация опасна тем, что переносит удаления и повреждения.

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

Измеряйте время до возобновления работы и сравнивайте с допустимым простоем, то есть RTO. Контролируйте ошибки копирования, свободное место и возраст последнего успешного бэкапа.

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

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