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