Проверяю копию сайта: база, файлы и запуск

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

Почему успешное копирование не равно успешному восстановлению

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

У сайта обычно есть как минимум две части: файлы и база данных. В WordPress, например, в базе лежит содержимое, а в каталоге — код, темы, плагины, загрузки и конфигурация. Копии этих частей должны относиться к одному понятному состоянию; иначе после восстановления можно увидеть старые записи с новыми файлами или наоборот. Не всякая такая рассинхронизация приводит к аварии, но проверить её дешевле до сбоя. Проверку наличия одного архива можно оставить для отчёта о наличии файла — на работоспособность сайта она ничего не доказывает.

Проверка архива и восстановление — разные испытания. Утилита может прочитать структуру ZIP или перечислить содержимое TAR, но это не доказывает, что дамп импортируется, конфигурация подходит, а сайт запускается. И обратное: успешный импорт не подтверждает, что на месте все пользовательские файлы. Поэтому я прохожу цепочку целиком: проверка архива, извлечение, импорт базы, настройка тестовой копии и проверка нужных функций. Архивная команда — полезный фильтр, а не сертификат здоровья.

Методика проверки: изоляция и контроль среды

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

Для теста необходимо подготовить чистую площадку: установить веб-сервер, базу данных и нужные расширения. Затем мы имитируем сценарий катастрофы: «продакшен» уничтожен, и нам нужно поднять его из архива. Здесь важно соблюдать дисциплину: не подглядывать в старые конфиги, не копировать файлы «на всякий случай» из рабочей среды. Мы должны действовать строго по инструкции восстановления, используя только те инструменты, которые доступны в аварийной ситуации. Это позволяет выявить проблемы в самих процедурах: забытые пароли, отсутствующие права доступа, неправильно настроенные пути.

Записывайте состав среды и ход восстановления: версии компонентов, установленные расширения, команды и ошибки. Это превращает следующий запуск из археологии в повторяемую процедуру. Ansible или Docker Compose полезны, если ими действительно можно развернуть тестовый контур, но само наличие файла конфигурации ничего не гарантирует. Отдельно проверьте владельца и права на каталог загрузок, параметры PHP, которые нужны именно этому сайту, и доступность базы. Если в инструкции написано «дальше само», значит, этот шаг ещё не описан.

• Создание чистой ВМ или контейнера
• Установка версий ПО, соответствующих моменту бэкапа
• Настройка прав доступа и переменных окружения
• Проверка доступности портов и сетевых правил

Проверка целостности базы данных и файлов

После импорта проверьте, что ожидаемые таблицы присутствуют и приложение может читать нужные данные. Сверка количества записей полезна только там, где есть контрольное значение: число строк само по себе не говорит, что содержимое верное. Для MySQL можно использовать mysqlcheck или CHECK TABLE, учитывая ограничения выбранного движка; результат этой проверки не заменяет тест импорта и работы приложения. DBCC CHECKDB относится к Microsoft SQL Server — переносить эту команду в инструкцию для MySQL или MariaDB нельзя. Для PostgreSQL отдельный инструмент pg_checksums проверяет контрольные суммы кластера, если они включены; для запуска сервер должен быть корректно остановлен. VACUUM ANALYZE обслуживает таблицы и обновляет статистику планировщика, но не является проверкой контрольных сумм.

После извлечения сравните состав и размеры файлов с манифестом, если он создавался при резервном копировании. Без манифеста такое сравнение выявит лишь очевидные пропуски, но не докажет идентичность содержимого. Проверьте конфигурацию и пользовательские загрузки, а права оценивайте относительно пользователя и схемы запуска конкретного сайта: владелец root не автоматически означает неисправность, но приложению должны быть доступны нужные операции. Для WordPress проверьте, среди прочего, wp-config.php, .htaccess и каталог загрузок; у Bitrix состав конфигурации другой. Не делайте вид, что один список файлов подходит любой CMS.

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

Архив сначала можно проверить штатной командой: unzip -t для ZIP, tar -tzf для сжатого gzip-архива TAR. Первая проверяет записи ZIP, вторая читает список содержимого TAR; tar --test-label проверяет только метку тома и для проверки архива не подходит. Если при создании копии сохранена контрольная сумма, сравните её с полученным файлом, например через sha256sum. Успешная проверка архива и совпадение контрольной суммы подтверждают лишь то, что файл читается и не изменился относительно известного эталона. Дамп всё равно надо импортировать, а восстановление — завершить.

• Импорт дампа базы данных в тестовую среду
• Проверка количества записей в ключевых таблицах
• Запуск утилит диагностики целостности БД
• Сверка количества файлов и их размеров
• Проверка прав доступа к файлам и папкам
• Автоматическая проверка путей к медиа-файлам

Функциональная проверка и сценарии использования

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

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

Отдельно проверьте плагины и внешние зависимости, которые нужны обязательным функциям. Если сайт использует Redis или Memcached, убедитесь, что тестовая среда настроена на ожидаемое поведение, либо временно отключите кэш по инструкции платформы. Содержимое кэша обычно можно построить заново; считать его незаменимой частью копии без проверки не нужно. Важно отличить отсутствующую зависимость от проблемы в самом архиве.

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

• Проверка регистрации и входа пользователей
• Тестирование корзины и оформления заказа
• Проверка работы форм обратной связи
• Тестирование функций административной панели
• Проверка работы плагинов и модулей
• Тестирование кэширования и внешних сервисов

Замер времени восстановления и документирование

Замеряйте время по этапам: подготовка среды, распаковка, импорт базы, настройка и проверка сценариев. Так вы получите фактическое время восстановления для этих условий и увидите, где задержка. Сравните результат с целевым временем, которое согласовано для конкретного сайта (RTO). Универсального норматива нет: медленный тестовый стенд и большая копия дадут другое время, чем подготовленная площадка и небольшой сайт. Не подменяйте измерение обещанием «поднимем быстро».

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

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

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

• Фиксация времени начала и конца каждого этапа
• Расчёт общего времени восстановления
• Сравнение с целевыми показателями RTO
• Документирование возникших проблем и решений
• Анализ метрик качества восстановления
• Обновление инструкций по восстановлению

Частые ошибки и как их избежать

Первая ошибка — принимать зелёный статус задания за доказательство пригодности копии. Смотрите журнал, проверяйте контрольную сумму, если она создаётся, и читайте архив тестовой командой. Для ZIP это может быть unzip -t, для gzip-TAR — tar -tzf. Затем проверьте извлечение и импорт. Ни один из этих шагов в одиночку не доказывает, что CMS заработает.

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

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

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

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

• Игнорирование проверки целостности архива
• Отсутствие изоляции тестовой среды
• Рассинхронизация базы данных и файлов
• Неполная функциональная проверка
• Отсутствие документирования результатов

Частые вопросы