Резервная копия WordPress: как делать, где хранить и как восстановиться, когда всё упало

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

Что считается полной копией, а что — только половиной

WordPress живёт в двух местах одновременно, и потеря любого из них означает потерю сайта. Первое — файлы на диске: ядро, папка wp-content с темой, плагинами и загрузками, конфигурационный файл wp-config.php, файл .htaccess в корне. Второе — база данных MySQL или MariaDB: там лежат все записи, страницы, категории, метки, настройки плагинов, пользователи, комментарии, товары магазина и заказы.

Типичная ошибка — копировать что-то одно. Архив папки сайта без базы даёт вам набор файлов, из которого нельзя восстановить ни одной статьи. Дамп базы без папки wp-content/uploads даёт сайт со всеми текстами и битыми картинками во всех записях. Ещё хуже промежуточный вариант: скопировали wp-content, но забыли wp-config.php, где хранятся имя базы, пользователь, пароль и соляные ключи. Восстановление превращается в расследование.

Что должно попадать в копию по минимуму:

• вся папка сайта целиком, включая скрытые файлы — .htaccess легко теряется, потому что архиваторы по умолчанию не берут файлы с точкой в начале имени;
• дамп базы данных в формате SQL, снятый с указанием кодировки — для современного WordPress это utf8mb4, иначе кириллица превратится в вопросительные знаки;
• перечень версий: какая версия PHP, какая версия MySQL, какая версия WordPress. Это одна текстовая строка, но без неё восстановление на другом сервере превращается в перебор.

Отдельно про ядро WordPress. Формально его можно не копировать: файлы ядра одинаковы у всех и скачиваются с официального сайта за минуту. Практически — копируйте: в ядре у многих лежат чужие правки от предыдущего подрядчика, и после чистой установки они исчезнут вместе с частью функциональности.

Почему копия на том же сервере не спасает

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

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

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

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

Как часто копировать и что делать перед обновлением

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

Тип сайта	Что меняется	Частота копий	Сколько хранить
Сайт-визитка, лендинг	Почти ничего, правки раз в квартал	Раз в месяц + перед каждой правкой	3 последние копии
Корпоративный сайт с блогом	Статьи, страницы услуг, формы	Раз в неделю, база — раз в сутки	4 недели, плюс одна месячная
Интернет-магазин	Заказы, остатки, цены, клиенты	База — раз в сутки или чаще, файлы — раз в неделю	30 суток по базе, 8 недель по файлам
Сайт с пользователями и подписками	Регистрации, платежи, личные данные	База — несколько раз в сутки	30 суток, с шифрованием архива
Проект в стадии разработки	Код и структура меняются ежедневно	Перед каждым этапом работ	Пока не закончится этап

Обратите внимание на разделение файлов и базы. Файлы весят много и меняются редко, база весит мало и меняется постоянно. Разумная схема: полная копия файлов раз в неделю, дамп базы — по расписанию, которое соответствует скорости изменений.

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

Где хранить копии и в каком виде

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

Формат хранения тоже имеет значение. Дамп базы всегда сжимайте: текстовый SQL уменьшается в восемь-десять раз обычным gzip. Если база больше 100 мегабайт в сжатом виде, забудьте про импорт через phpMyAdmin — там работают ограничения upload_max_filesize и max_execution_time, и импорт оборвётся посередине, оставив половину таблиц. Такой дамп грузится только через консоль или через WP-CLI командой wp db import.

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

Восстановление по шагам: порядок, в котором ничего не ломается

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

Шаг первый — зафиксировать текущее состояние. Даже если сайт лежит, сделайте копию того, что есть сейчас. Звучит странно, но именно из «сломанного» состояния потом достаются данные, добавленные после последнего бэкапа: свежие заказы, комментарии, заявки.

Шаг второй — понять, что именно сломалось. Смотреть нужно на код ответа сервера и на лог ошибок. Белый экран без кода — обычно фатальная ошибка PHP, и её текст есть в файле error_log рядом с сайтом. Ответ 500 — ошибка сервера, часто из-за .htaccess или нехватки памяти. Ответ 502 или 504 — проблема на стороне сервера, а не в сайте, и восстановление из копии тут вообще не поможет. Что означает каждый код, я расписывал в материале Коды ответа сервера: руководство с примерами использования. Половина «катастроф» лечится без бэкапа: отключением одного плагина через переименование его папки.

Шаг третий — восстановить файлы. Распакуйте архив в корень сайта, перезаписав существующее. Проверьте, что на месте .htaccess и wp-config.php. Проверьте права: каталоги обычно 755, файлы 644, wp-config.php имеет смысл сделать 600 или 640.

Шаг четвёртый — восстановить базу. Сначала удалите существующие таблицы или создайте пустую базу, потом загрузите дамп. Импорт поверх существующих таблиц без удаления даёт конфликты по первичным ключам и наполовину загруженные данные. После импорта проверьте в таблице wp_options значения siteurl и home — они должны совпадать с реальным адресом сайта, включая протокол.

Шаг пятый — сверить связку. В wp-config.php имя базы, пользователь и пароль должны соответствовать той базе, куда вы залили дамп. Ошибка «Error establishing a database connection» после восстановления — почти всегда именно это несовпадение, а не поломка сервера.

Шаг шестой — проверить сайт по контрольному списку. Открывается ли главная, открывается ли внутренняя страница (это проверка постоянных ссылок), работает ли админка, отправляется ли форма, видны ли картинки в старых записях, отдаёт ли robots.txt и карта сайта нормальный ответ. Если внутренние страницы дают 404, а главная работает — пересохраните настройки постоянных ссылок, это перезапишет правила в .htaccess.

Шаг седьмой — сбросить кэш. Плагин кэширования, серверный кэш, кэш CDN. Иначе вы будете смотреть на сломанную версию, которая уже починена.

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

Учебное восстановление: главная проверка, которую никто не делает

Копия — это не файл, это процедура. Проверяется процедура целиком, а не наличие архива. Раз в квартал разверните копию где-нибудь, кроме боевого сервера, и посмотрите, что получилось.

Где разворачивать: на локальном компьютере, на тестовом поддомене, на отдельном дешёвом хостинге. Тестовый поддомен — самый удобный вариант, но он обязан быть закрыт от индексации: и заголовком X-Robots-Tag: noindex на уровне сервера, и паролем через базовую HTTP-авторизацию. Открытая копия сайта на поддомене — это полный дубль всех страниц, который поисковик с удовольствием проиндексирует, после чего вы получите склейку и падение позиций основного сайта.

Что проверяется при учебном развёртывании:

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

Про замену адресов. Когда копия разворачивается на другом домене или на локальном сервере, старый адрес остаётся прописанным внутри записей — в ссылках, в путях к картинкам, а также внутри сериализованных строк в настройках плагинов. Обычный поиск с заменой по SQL ломает сериализованные данные: в них хранится длина строки, и после замены длина перестаёт совпадать. Для этого есть wp search-replace в WP-CLI. Полный порядок такого переезда со всеми проверками я описывал в статье Перенос сайта на CMS: инструкция по переезду.

Когда резервная копия не спасёт

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

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

Санкции поисковой системы. Откат файлов не снимает фильтр. Если позиции упали из-за качества текстов или ссылочного профиля, никакая копия этого не отменит: нужно менять причину.

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

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

Чеклист: проверьте своё копирование прямо сейчас

Пройдите по списку и честно отметьте, что у вас есть. Каждый пункт занимает от минуты до получаса, а вместе они закрывают почти все сценарии потери сайта.

Что проверить	Как проверить	Признак проблемы
Копия включает и файлы, и базу	Посмотреть содержимое последнего архива	В архиве нет файла с расширением .sql
Копия лежит не только на сервере сайта	Найти вторую копию за пределами хостинга	Второй копии нет ни одной
Копия свежая	Посмотреть дату последнего архива	Дата старше вашей допустимой потери данных
Архив не битый	Скачать и распаковать на компьютере	Ошибка распаковки, нулевой размер файла
Дамп базы полный	Открыть .sql и найти в конце строку завершения	Файл обрывается на середине таблицы
Известны версии PHP и MySQL	Панель хостинга или сайт-здоровье в админке	Никто не знает, на чём работает сайт
Процедура восстановления опробована	Развернуть копию на тестовой площадке	Ни разу не разворачивали
Известно время восстановления	Засечь при учебном развёртывании	Ответ «часа за два, наверное»
Есть доступы к панели и к базе	Зайти в панель хостинга и в phpMyAdmin	Пароли только у бывшего подрядчика
Архивы с персональными данными закрыты	Открыть ссылку на архив в браузере инкогнито	Файл скачивается без пароля

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

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

Хостинг делает бэкапы автоматически — этого достаточно? Как единственной копии — нет. Проверьте три вещи: за какой период хранятся снимки, сколько времени занимает восстановление по заявке и восстанавливается ли отдельный файл или только весь аккаунт целиком. У многих тарифов снимок один, суточной давности, и он перезаписывается — то есть если поломку заметили через двое суток, восстанавливать уже нечего.

Плагин копирования или ручное копирование? Плагин удобнее, но он работает внутри WordPress: если сайт не открывается, плагин недоступен. Ручная схема — архив по FTP или SSH плюс дамп базы — работает всегда, но требует дисциплины. Разумно совмещать оба способа.

Что делать, если копии нет вообще, а сайт упал? По порядку: сохранить то, что осталось на диске; посмотреть код ответа и лог ошибок; проверить, есть ли снимок у хостинга и за какую дату; посмотреть сохранённые копии страниц в поисковых системах и в веб-архиве — тексты оттуда достать реально, хотя и вручную. И только после того, как сайт поднят, настроить копирование, чтобы второй раз этот разговор не повторялся.

Коротко

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

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