Проверить резервную копию WordPress можно только одним способом: развернуть ее на отдельном адресе и убедиться, что сайт из копии открывается, в админку можно войти, картинки на месте, а формы отправляют заявки. Наличие архива в облаке и зеленая галочка в плагине говорят лишь о том, что файл создан. Такую проверку стоит делать хотя бы раз в квартал и после каждой смены хостинга или плагина бэкапов.
Типичная история, которую мы слышим от компаний: сайт упал после неудачного обновления, владелец спокоен, потому что «бэкапы делаются каждый день». Через час выясняется, что последний архив весит 40 мегабайт при сайте на 3 гигабайта, в нем нет папки с загрузками, а дамп базы обрывается на середине. Копия существовала, восстановиться из нее было нельзя. Ниже порядок проверки, который занимает от часа до половины рабочего дня и снимает этот риск.
Чем рабочий бэкап отличается от архива, который просто существует
Рабочий бэкап WordPress — это копия, из которой за предсказуемое время поднимается полностью работающий сайт без участия человека, который ее когда-то настроил. Если восстановить сайт может только подрядчик, ушедший два года назад, или только поддержка хостинга по заявке, это слабая копия, даже если технически она полная.
Сайт на WordPress состоит из двух частей, и копия должна содержать обе. По разделу о резервных копиях в документации WordPress, нужно сохранять и базу данных, где лежат записи, страницы, настройки и пользователи, и файлы сайта: ядро, темы, плагины, загрузки. Документация также советует делать копию регулярно и обязательно перед обновлением. О том, как выстроить само копирование, где хранить архивы и сколько их держать, мы подробно писали в статье о резервном копировании WordPress. Здесь речь о следующем шаге: как убедиться, что из этих архивов сайт вернется.
Для владельца бизнеса полезно держать в голове два понятия из мира ИТ. RPO (Recovery Point Objective) — это сколько данных вы готовы потерять, то есть насколько старой может быть копия: сутки, час, неделя. RTO (Recovery Time Objective) — это за сколько времени сайт должен снова заработать. Проверка восстановления как раз отвечает на вопрос, укладываетесь ли вы в оба числа на практике, а не на бумаге.
Почему бэкапы не восстанавливаются: частые причины
Чаще всего копия оказывается нерабочей из-за того, что ее никто ни разу не пробовал развернуть. Ошибки накапливаются тихо, и плагин продолжает рапортовать об успехе. На проектах B2BPRO.KZ при аудите сайтов мы чаще всего встречаем такие ситуации:
- Обрезанный архив. На недорогом хостинге задача резервного копирования упирается в лимит времени выполнения или памяти и прерывается, а файл остается. Внешне это обычный zip, внутри половина сайта.
- Копия только базы или только файлов. Плагин настроили на базу «чтобы быстрее», а про загрузки забыли. Тексты вернутся, картинки и документы нет.
- Исключенные папки. Кто-то добавил в исключения папку uploads или каталог кэша вместе с нужными данными, чтобы архив стал меньше.
- Архивы лежат на том же сервере. При отказе диска или блокировке аккаунта копии пропадают вместе с сайтом.
- Нет доступа к хранилищу. Облачный диск привязан к почте бывшего сотрудника или подрядчика, пароль никто не знает.
- Плагин бэкапов нужен для восстановления. Некоторые архивы удобно разворачивать только тем же плагином, а он не ставится на чистый WordPress новой версии или конфликтует с PHP на новом хостинге.
- Устаревшая копия. Задача по расписанию перестала запускаться несколько месяцев назад, и этого никто не заметил.
Каждая из этих проблем находится за один пробный прогон восстановления. Поэтому проверять стоит сам результат, а настройки плагина смотреть уже потом.
Как проверить резервную копию сайта без восстановления: быстрый осмотр
Первые признаки нерабочей копии видны еще до развертывания, за 10-15 минут. Этот осмотр не заменяет пробного восстановления, но отсекает самые грубые проблемы, и его можно делать хоть каждую неделю.
- Посмотрите дату последнего архива. Она должна совпадать с расписанием. Если копии делаются ежедневно, а последняя неделю назад, задача сломалась.
- Сравните размер архива с размером сайта. Размер папки сайта и базы показывает панель хостинга. Архив обычно меньше за счет сжатия, но если сайт занимает гигабайты, а копия десятки мегабайт, в ней чего-то не хватает.
- Откройте архив и проверьте состав. Внутри должны быть папка wp-content с подпапками themes, plugins и uploads, файл wp-config.php и файл дампа базы с расширением .sql или его архив.
- Проверьте, что uploads заполнена. Загляните в папки по годам и месяцам: в них должны быть картинки за последние месяцы, а не только за год запуска сайта.
- Посмотрите конец дампа базы. Откройте .sql в текстовом редакторе, который справляется с большими файлами, и прокрутите в конец. Дамп, выгруженный утилитой mysqldump с настройками по умолчанию, обычно заканчивается служебной строкой о завершении выгрузки. Если файл обрывается на середине команды INSERT, дамп неполный.
- Найдите в дампе ключевые таблицы. В нем должны быть таблицы с вашим префиксом: posts, postmeta, options, users и таблицы плагинов, например магазина или форм.
Если что-то из списка не сходится, переходить к восстановлению рано: сначала чините создание копии. Если все в порядке, переходите к главному тесту.
Как восстановить сайт из резервной копии на тестовом адресе
Пробное восстановление делают на отдельном поддомене или на локальном компьютере, никогда поверх рабочего сайта. Цель: пройти весь путь так, как его пришлось бы пройти в день аварии, и засечь время. Если у вас уже есть тестовая копия для обновлений, порядок ее создания описан в статье о тестовой копии сайта на WordPress. Здесь важно другое: разворачивать нужно именно из архива бэкапа, а не клонировать живой сайт, иначе вы проверите не копию.
Порядок восстановления вручную:
- Создайте поддомен, например restore-test.вашдомен.kz, и пустую базу данных с отдельным пользователем. Базу рабочего сайта не трогайте.
- Скачайте архив из того места, где он реально хранится, например из облака, а не с сервера сайта. Это заодно проверяет доступ к хранилищу.
- Распакуйте файлы в папку поддомена.
- Импортируйте дамп в новую базу через phpMyAdmin или командой. В WP-CLI для этого есть
wp db import: по описанию команды wp db import, она берет параметры подключения из wp-config.php и выполняет SQL из файла, но саму базу не создает, поэтому пустую базу нужно завести заранее. - Пропишите в wp-config.php тестовой копии имя новой базы, пользователя и пароль. Если на сайте задана константа WP_HOME или WP_SITEURL, поменяйте и ее.
- Замените адрес сайта в базе на тестовый. Простая замена текста в дампе ломает сериализованные данные плагинов и конструкторов страниц. Команда
wp search-replaceпо документации WP-CLI о search-replace корректно обрабатывает сериализованные данные PHP, поэтому ее используют для смены домена. - Закройте тестовый адрес паролем на уровне сервера и запретите индексацию, чтобы копия не попала в поиск.
Если бэкап делался плагином, проверьте восстановление тем способом, которым будете пользоваться в аварии: поставьте на чистый WordPress тот же плагин и разверните архив через него. Заодно станет понятно, работает ли плагин на текущей версии PHP вашего хостинга.
Что проверить на восстановленном сайте
Восстановленный сайт считается рабочим, когда он выполняет те же задачи для бизнеса, что и основной, а не просто открывает главную страницу. Проверку удобно вести по списку и отмечать результат.
| Что проверить | Как проверить | Признак проблемы |
|---|---|---|
| Главная и ключевые страницы | Открыть главную, страницы услуг, контакты, 3-5 свежих статей | Белый экран, ошибка 500, сломанная верстка |
| Вход в админку | Войти под своим пользователем | Пользователя нет, пароль не подходит, бесконечный редирект |
| Свежесть данных | Найти последнюю статью, заказ или заявку перед датой копии | Данные старше, чем обещает расписание |
| Картинки и файлы | Открыть страницы с фото, скачать прайс или PDF | Битые изображения, 404 на файлах |
| Формы | Отправить тестовую заявку | Форма не отправляется или письмо не приходит |
| Ссылки и адреса | Пройтись по меню и внутренним ссылкам | Ссылки ведут на рабочий домен или на 404 |
| Ядро WordPress | Команда wp core verify-checksums |
Измененные или лишние файлы ядра |
| База данных | Команда wp db check или проверка таблиц в phpMyAdmin |
Поврежденные таблицы |
Две последние строки особенно полезны, если копию делали после подозрения на взлом. Команда проверки контрольных сумм, по описанию wp core verify-checksums, сравнивает файлы ядра с контрольными суммами WordPress.org для текущей версии. Если в копии ядро уже изменено, восстанавливаться из нее нельзя: вы вернете на сайт тот же вредоносный код. В таком случае нужна более ранняя копия, а ядро разумнее поставить заново.
Отдельно отметьте формы. Тестовая копия может отправлять настоящие письма менеджерам и даже создавать сделки в CRM, если форма связана с ней. Перед проверкой предупредите отдел продаж или временно поменяйте адрес получателя на свой, иначе тестовая заявка уйдет в работу.
Какие сценарии аварии стоит отрепетировать
Разные аварии требуют разного восстановления, и одна проверка не покрывает все случаи. Полный разворот сайта из архива нужен при отказе хостинга, а для удаленной по ошибке страницы достаточно вернуть часть данных. Удобно заранее решить, какой сценарий вы проверяете в этом квартале.
| Сценарий | Что восстанавливать | На что обратить внимание при проверке |
|---|---|---|
| Хостинг недоступен или аккаунт заблокирован | Весь сайт на новом сервере | Есть ли копия вне старого хостинга и доступы к домену, чтобы сменить DNS |
| Неудачное обновление плагина или темы | Файлы и база на момент до обновления | Сделана ли копия прямо перед обновлением, а не накануне |
| Взлом сайта | Чистая копия до заражения, ядро заново | Как далеко в прошлое хранятся копии и проходит ли ядро проверку контрольных сумм |
| Сотрудник удалил страницу или товары | Отдельные записи из старой базы | Можно ли достать нужные данные из дампа, не откатывая весь сайт |
Последний сценарий часто упускают. Если откатить весь сайт ради одной удаленной страницы, пропадут заявки, заказы и комментарии, пришедшие после создания копии. Аккуратнее развернуть копию на тестовом адресе, найти там нужную страницу или товары и перенести их на рабочий сайт вручную или экспортом. Пробный прогон этого сценария показывает, сколько времени займет такая точечная операция и кто в команде умеет ее делать.
Для сценария с взломом важна глубина хранения. Заражение часто обнаруживают через несколько недель, и если копии хранятся всего неделю, чистой среди них может не оказаться. Поэтому при проверке посмотрите не только на последнюю копию, но и на самую старую доступную: сколько ей дней и разворачивается ли она так же, как свежая.
Сколько времени занимает восстановление и как его засечь
Время восстановления меряют секундомером с момента, когда вы решили «восстанавливаемся», до момента, когда сайт снова принимает заявки. Именно это число и есть ваш реальный RTO. На сайте-визитке с небольшой базой ручное восстановление обычно укладывается в час, на интернет-магазине с тысячами товаров и гигабайтами фото может занять половину дня, в основном из-за скачивания и распаковки архива.
Во время пробного прогона запишите:
- сколько времени ушло на поиск доступов к хранилищу, хостингу и базе;
- сколько скачивался и распаковывался архив;
- сколько занял импорт базы;
- какие шаги потребовали знаний, которых нет у вашего сотрудника;
- какие ошибки встретились и как их обошли.
Обычно больше всего времени съедают поиск паролей и выяснение, где лежит свежая копия, сама техника идет быстрее. Поэтому главный результат первого прогона часто организационный: доступы собраны в одном месте, архив переложен в хранилище, которым владеет компания, а не подрядчик.
Как часто проверять восстановление и кто за это отвечает
Пробное восстановление разумно проводить раз в квартал, а также после смены хостинга, плагина резервного копирования, крупного обновления WordPress или переделки сайта. Быстрый осмотр архивов можно делать еженедельно или раз в месяц, он занимает минуты.
Чтобы проверка не превратилась в разовую акцию, закрепите ее за конкретным человеком и оформите короткий журнал. В нем достаточно пяти полей: дата, какая копия проверялась, сколько заняло восстановление, что нашли, что исправили. Через год журнал покажет, укладываетесь ли вы в нужные RPO и RTO, и станет аргументом при выборе хостинга или подрядчика.
Если сайт ведет внешняя команда, запросите у нее отчет о последнем пробном восстановлении. Нормальный подрядчик ответит датой и временем, которое заняла проверка. Ответ в духе «бэкапы делаются, не переживайте» означает, что восстановление никто не проверял. Если нужна помощь с настройкой копирования, проверкой восстановления или доработкой сайта, посмотрите наши услуги по разработке и поддержке сайтов: мы берем сайты на WordPress на сопровождение и включаем пробное восстановление в регламент.
Что делать, если проверка провалилась
Провал пробного восстановления — это хорошая новость, потому что вы узнали о проблеме до аварии. Действуйте по порядку: сначала обеспечьте себе хотя бы одну заведомо рабочую копию, потом чините автоматику.
- Сделайте полную копию вручную прямо сейчас: файлы через панель хостинга или FTP и дамп базы через phpMyAdmin или
wp db export. Сразу проверьте ее быстрым осмотром. - Положите эту копию в хранилище вне сервера сайта, доступ к которому есть у компании.
- Найдите причину сбоя автоматической копии: лимиты хостинга, исключенные папки, сломанное расписание, нехватка места.
- Если хостинг не тянет создание архива, перенесите копирование на уровень сервера или смените тариф. О выборе хостинга под WordPress мы писали в статье о хостинге для WordPress в Казахстане.
- Через неделю повторите пробное восстановление уже из автоматической копии.
Для сайтов, которые приносят заявки каждый день, стоит держать две независимые копии: от хостинга и от собственного плагина или скрипта. Тогда сбой одной из них не оставит вас без сайта.
Проверка восстановления выглядит лишней работой ровно до первой аварии. Один пробный прогон в квартал стоит несколько часов, а сайт, который не удалось поднять, обходится в дни без заявок и в разработку заново.
Частые вопросы
Как понять, что бэкап WordPress рабочий?
Надежно понять это можно только пробным восстановлением: развернуть копию на отдельном поддомене и проверить, что открываются страницы, работает вход в админку, на месте картинки и отправляются формы. Перед этим полезно осмотреть архив: дату, размер, наличие папки uploads, файла wp-config.php и полного дампа базы.
Можно ли восстановить сайт WordPress из копии без программиста?
Можно, если копию делает плагин, который умеет восстанавливать архив в пару кликов, и у вас есть доступ к хранилищу и хостингу. Ручное восстановление с импортом базы и заменой адресов требует опыта. Поэтому лучше один раз пройти процедуру на тестовом адресе и записать шаги, пока сайт работает.
Как часто нужно проверять восстановление из резервной копии?
Пробное восстановление стоит проводить раз в квартал, а также после смены хостинга, плагина копирования или крупного обновления сайта. Быстрый осмотр архивов, то есть проверку даты, размера и состава копии, можно делать раз в неделю или месяц: он занимает 10-15 минут.
Почему нельзя проверять бэкап, восстанавливая его поверх рабочего сайта?
Если копия окажется битой, вы потеряете и рабочий сайт, и надежду на быстрый откат. Кроме того, восстановление поверх живого сайта затрет заявки и заказы, пришедшие после создания копии. Проверку всегда делают на отдельном поддомене или локально, закрыв тестовую копию паролем и запретом индексации.
Что делать, если резервная копия не восстанавливается?
Сначала сделайте полную копию вручную: файлы через панель хостинга и дамп базы через phpMyAdmin, и сохраните ее вне сервера сайта. Затем выясните, почему сломалась автоматическая копия: лимиты хостинга, исключенные папки или остановленное расписание. После исправления повторите пробное восстановление уже из автоматической копии.