В одном из проектов работа над восстановлением началась с аудита резервной базы. Наличие файла еще не отвечало на вопросы о комплектности копии, адресах сайта и готовности к запуску. Разберем, что проверить до импорта и как учесть данные, появившиеся после создания копии.
Резервная база — часть комплекта восстановления
SQL-дамп — сохраненная выгрузка базы, а не обязательно весь сайт. Для сайта с базой данных отдельно нужны файлы приложения, шаблоны, расширения, загруженные изображения и настройки подключения. Например, документация WordPress прямо разделяет резервирование базы и файлов: для полного восстановления типового сайта нужны обе части.
Сначала составляют опись: что сохранилось, откуда получено, к какому сайту относится и когда создано. Проверяют, открывается ли архив и содержит ли дамп данные, а не только описание таблиц. Исходные копии сохраняют без изменений, для проверки используют их дубликаты.
Полезно сразу записать пробелы: нет изображений, неизвестна версия расширения, отсутствует часть таблиц. Если состав или совместимость не подтверждены, копию пока считают кандидатом на восстановление.
Дата базы, файлы и версия приложения
Дата в имени архива сама по себе ничего не доказывает. Ее сопоставляют с журналом резервирования, содержимым базы и известными изменениями на сайте: последней публикацией, обновлением каталога, установкой расширения. Уточняют время и часовой пояс копии.
Файлы и база должны относиться к совместимому состоянию приложения. Если после резервирования обновили CMS или модуль, возвращенная база может не соответствовать ожидаемой структуре таблиц. Поэтому в опись включают версии CMS, значимых расширений и требования к серверному окружению, а совместимость подтверждают пробным развертыванием.
Восстановление и обновление компонентов лучше разделить: сначала получить проверяемое исходное состояние, затем планировать изменения. Если исходный сбой связан с заражением, пригодность архива дополнительно оценивают по плану восстановления после взлома: возраст копии сам по себе не подтверждает ее чистоту.
Новые записи нельзя считать частью старой копии
Восстановить базу сайта из вчерашнего дампа — не значит автоматически сохранить сегодняшние изменения. Типовой пример для магазина: после резервирования поступили заказы, изменились их статусы и появились новые покупатели. Это общий пример, не описание исходного проекта. У другого сайта значимыми данными будут заявки или публикации.
До замены сохраняют текущее доступное состояние базы и файлов. Затем определяют промежуток между созданием копии и моментом, когда сайт перестанет принимать изменения. За этот период нужно учесть не только новые строки, но и исправления старых: у прежнего заказа могла измениться оплата, а у статьи — текст.
Для каждого типа данных фиксируют три вещи:
- где доступна актуальная версия и кто может подтвердить ее правильность;
- какие связанные записи и файлы нужно перенести вместе с ней;
- как проверить результат переноса и исключить повторное создание записей.
Перенос одной таблицы не равен переносу всех связанных данных. Решение о совмещении старой копии с новыми записями принимают после сравнения структуры и связей, затем проверяют на отдельной базе. Если часть данных утрачена и другого источника нет, этот пробел фиксируют до переключения, а не прячут за фразой «резервная копия восстановлена».
Как развернуть копию, не затронув действующий сайт
Первый импорт выполняют в отдельную базу в изолированном окружении, без доступа к рабочей базе. Перед этим проверяют содержимое дампа и назначение импорта: SQL-файл может содержать команды удаления и пересоздания таблиц, что предусмотрено параметрами mysqldump в документации MySQL. Поэтому импорт поверх действующих данных нельзя использовать как пробу пригодности архива.
К тестовой базе подключают подготовленные файлы и проверяют журнал импорта. Ошибки загрузки разбирают до оценки сайта: открывшаяся главная страница не доказывает, что все таблицы восстановлены. Отдельно смотрят русские тексты, изображения и документы.
До запуска тестовой версии отключают реальные отправки писем, платежи, обмен с учетной системой и фоновые задания, которые меняют внешние данные. Копию закрывают от посторонних средствами контроля доступа. Один robots.txt для этого не подходит: Google поясняет, что он управляет обходом и не защищает закрытые данные от доступа.
Доменные ссылки и поисковые файлы
В подготовленной версии проверяют основной адрес сайта, ссылки в содержимом, перенаправления, адреса изображений и canonical — указание предпочтительного адреса страницы. Ссылки не должны уводить посетителя на тестовую копию. Проверку выполняют на нескольких типах страниц.
В sitemap должны быть адреса нужного рабочего сайта. Рекомендации Google по sitemap требуют полных абсолютных URL: домен и протокол здесь имеют значение. В robots.txt проверяют ссылку на карту сайта и правила обхода, а перед публичным запуском отдельно сверяют ограничения индексации, оставшиеся от тестирования.
При подготовке восстановления в том проекте исправили доменные ссылки в robots и sitemap. Однако исправленные поисковые файлы сами по себе не подтверждают сохранность данных и готовность к переключению. Если вместе с восстановлением меняется адрес либо сервер, пригодится отдельная проверка переезда без потери SEO.
Приемка: данные и действия вместо одной главной
Владелец и исполнитель заранее выбирают контрольные примеры для приемки. Для информационного сайта это могут быть свежая и старая публикации, поиск, вложение и форма заявки. Для магазина — товар с изображениями, состав и статус выбранных заказов; проверку оформления проводят в тестовом режиме без реального списания денег.
Сверяют число значимых записей, их даты и содержимое выбранных примеров. Одних количеств мало: две базы могут содержать одинаковое число заказов, но разные статусы. Отдельно проверяют согласованный перенос данных, появившихся после резервирования, и отмечают, какие расхождения устранены, а какие еще мешают запуску.
Результат приемки — короткий перечень проверок с фактами: что загрузилось, что работает, каких данных не хватает. Поэтому работа не сводится к минуте импорта: проверка комплекта, пробное восстановление и сверка записей — отдельные операции.
Переключение и возможность вернуться назад
Переключение готовят после приемки и отдельно согласуют с владельцем. До него определяют время остановки записи, порядок учета последних изменений и условия отката. Остановить нужно все источники изменений, включая фоновые обмены, иначе между финальной сверкой и запуском появятся данные, которых нет в подготовленной версии.
Перед переключением сохраняют согласованный комплект текущих файлов, базы и настроек. План отката должен объяснять, кто возвращает этот комплект и по какому признаку: например, если не работает ключевая форма или обнаружено расхождение в значимых данных. Возврат только базы без подходящих файлов не гарантирует прежнего состояния сайта.
После открытия рабочей версии повторяют контрольные действия и следят за ошибками и поступлением новых записей. Если откат понадобился уже после их появления, сначала учитывают эти записи: простое возвращение прежней копии может потерять их снова. Архивы и материалы проверки сохраняют до конца согласованного периода наблюдения.
Опишите, какие копии сохранились и что случилось с сайтом — оценим комплект и порядок восстановления.