Как проверить восстановление сайта из резервной копии

Перед началом

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

Сначала уточните, что нужно восстанавливать

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

У CMS обычно есть и файлы, и база данных. У серверного приложения дополнительно важны зависимости, конфигурация запуска, версии среды и внешние сервисы. Ящик на домене, DNS и обработчик заявки могут управляться отдельно от файлов сайта. Состав копии нужно сверить с устройством вашего проекта.

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

Проверьте обещание хостинга до покупки

Если резервные копии уже включены в тариф, выясните:

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

Последний пункт легко пропустить. В документации Timeweb прямо указано: восстановление изменённых и удалённых файлов не удаляет новые файлы, добавленные после создания копии. Поэтому возврат содержимого поверх текущей папки и получение точного старого состояния — разные операции. Это описание конкретной процедуры Timeweb, а не общее правило всех сервисов.
Источник: инструкция Timeweb в разделе «Источники» ниже.

Для REG.RU процедура создания и восстановления файлов и базы описана отдельно в справке:
Ссылка на документ REG.RU — в разделе «Источники» ниже.

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

Наш учебный пример: главная работает, сайт повреждён

В примере четыре файла: index.html, contacts.html, assets/style.css и assets/logo.svg. Формы, базы и настоящих контактов в нём нет.

Перед повреждением мы создали ZIP и записали SHA-256 каждого файла. Затем в отдельной учебной папке:

• удалили logo.svg; • заменили contacts.html неправильным текстом; • добавили unexpected.txt — обычный дополнительный текстовый файл, не вредоносный код.

После этого главная страница отвечала HTTP 200. Контакты тоже отвечали HTTP 200, хотя содержимое уже не совпадало с исходным. Запрос изображения возвращал 404.

Вывод из этого теста: проверка только главной страницы пропустила бы повреждение. Даже успешный ответ внутренней страницы ещё не доказывал правильность её содержимого.

Восстановите в отдельную пустую папку

В первом варианте мы скопировали исходные файлы поверх повреждённой папки. Четыре исходных файла вернулись, но unexpected.txt остался. Так мы воспроизвели проблему лишнего файла без использования вредоносного кода.

Во втором варианте распаковали проверенную копию в новую папку. Список файлов и их SHA-256 совпали с исходным: восстановлены именно четыре ожидаемых файла. Страницы, CSS и SVG загрузились по HTTP. Запрос unexpected.txt вернул 404.

Мы также изменили байты самого ZIP. Учебный скрипт сравнил его с сохранённой контрольной суммой и отклонил до записи файлов.

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

Повторите пример без доступа к вашему сайту

В архиве материала находится verify.py. Для запуска нужен Python 3 со стандартной библиотекой:

python3 verify.py

Скрипт сам создаёт четыре учебных файла во временной папке. Он не принимает путь к вашему сайту, не читает документы проекта, не подключается к хостингу и не устанавливает пакеты. Локальный HTTP-сервер слушает только 127.0.0.1 на свободном порту и останавливается после проверки. Временные данные очищаются; рядом со скриптом сохраняется results.json.

В нашем запуске прошли пять проверок: отсутствующая картинка; неправильное содержимое при HTTP 200; лишний файл после копирования поверх; восстановление в чистую папку; отказ от изменённого архива. Подробные HTTP-статусы и контрольные суммы находятся в results.json.

Скрипт рассчитан только на встроенный учебный набор. Это не универсальная программа распаковки и не инструкция автоматического восстановления production-сайта.

Что проверить на своём проекте

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

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

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

Когда стоит платить за дополнительный сервис

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

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

Следующий шаг

Если выбираете размещение готового проекта, сначала определите его тип и состав данных, затем сравните подходящие способы публикации:
Руководство «Где разместить готовый сайт» доступно в блоке других руководств ниже.

Для проверки страниц и ресурсов после загрузки:
Руководство «Как опубликовать HTML-сайт» доступно в блоке других руководств ниже.

Что мы проверили и где границы

Собственный тест: четыре статических файла, локальный HTTP, известные контрольные суммы, два способа восстановления. Не проверяли: реальные кабинеты бэкапов, CMS/БД, DNS, HTTPS, доставку заявок, вредоносный код, независимое хранение копий и восстановление VPS. Дата выполнения указана в приложенном results.json. Материал подготовлен с использованием ИИ; технический пример выполнен локально. Партнёрские рекомендации в этом материале отсутствуют.

Исходники и результаты

Архив содержит verify.py, README.txt и results.json. Он рассчитан только на встроенные учебные файлы и не восстанавливает реальный сайт автоматически.