Разговор про бэкапы у нас с клиентами почти всегда начинается одинаково: сайт уже лежит. Хостинг отвечает, что копия была неделю назад, но восстановить её можно только на другой тариф. Или копия есть, только в ней база без файлов, и половина картинок в статьях превратилась в битые ссылки. Или бэкап делал плагин, но он складывал архивы в ту же папку на том же сервере, который и умер.
Резервное копирование WordPress выглядит скучной технической задачей ровно до момента, когда бэкап понадобился. Дальше выясняется, что копия и восстановление из копии — это две разные вещи, и вторую почти никто не проверяет. Рабочая схема резервного копирования WordPress держится на четырёх ответах: что именно копировать, куда складывать, как часто и как убедиться, что архив вообще откроется.
Из чего состоит сайт на WordPress
Официальная документация WordPress делит сайт на две части, и обе нужны для восстановления.
Первая часть — файлы в директории WordPress на веб-сервере: ядро, темы, плагины, загруженные картинки и документы, а также служебные файлы вроде wp-config.php и .htaccess. Вторая — база данных MySQL или MariaDB, которая лежит отдельно и просто скачиванием папки не забирается. В базе хранятся записи, страницы, комментарии, настройки, пользователи, значения плагинов.
Потерять любую из половин означает потерять сайт. База без файлов даст вам текст статей и пустые места вместо иллюстраций, а также сайт без темы и плагинов. Файлы без базы дадут работающий движок с нулём контента. Именно на этом ломается большинство самодельных схем: человек копирует папку по FTP и считает, что бэкап сайта готов.
Отдельно стоит сказать про wp-config.php. В нём хранятся доступы к базе и ключи безопасности. Файл нужен в копии, но его нельзя класть в общедоступное место: архив с ним фактически содержит пароль от вашей базы данных.
Почему встроенный экспорт не заменяет бэкап
В админке WordPress есть раздел «Инструменты», а в нём «Экспорт». Он создаёт XML-файл формата WXR, и многие принимают его за резервную копию. На этом уже теряли сайты, поэтому стоит проговорить подробно.
WXR-файл содержит записи, страницы, произвольные типы записей, комментарии, произвольные поля, рубрики, метки, произвольные таксономии и пользователей. Чего в нём нет: файлов из папки uploads, тем, плагинов, настроек плагинов, виджетов и меню в полном объёме, а также самого ядра WordPress. Восстановить сайт из одного WXR не получится, вы получите текст без оформления и без картинок.
У инструмента экспорта своя ниша: перенос контента между сайтами, выгрузка части материалов по фильтру, передача статей подрядчику. В схеме резервного копирования он может быть только дополнением к полноценной копии.
Три уровня, на которых делают копии
На практике мы видим три источника резервных копий, и надёжная схема опирается минимум на два из них.
Копии на стороне хостинга
Почти каждый хостер делает свои бэкапы. Это самый дешёвый уровень, потому что он уже включён в тариф, и самый ненадёжный, потому что вы им не управляете.
Что нужно выяснить у своего провайдера до того, как копия понадобится. Как часто она снимается и сколько хранится. Забирает ли она базу вместе с файлами или только что-то одно. Можно ли скачать архив себе или восстановление доступно исключительно силами поддержки. Сколько времени занимает восстановление по заявке. Считается ли восстановление платной услугой.
Ответы на эти вопросы иногда неприятно удивляют. Мы встречали тарифы, где копия хранится сутки, и тарифы, где восстановление возможно только целиком, вместе с остальными сайтами на аккаунте. Знать это лучше заранее.
Плагины резервного копирования
Каталог WordPress предлагает много решений, которые по расписанию собирают файлы и базу в архив и отправляют его во внешнее хранилище. Это рабочий уровень для большинства сайтов малого и среднего бизнеса.
Ключевое требование к настройке одно: архив не должен оставаться на том же сервере. Плагин, который складывает копии в папку внутри сайта, защищает вас только от собственной ошибки в контенте. При отказе диска, блокировке аккаунта или взломе сервера копии умрут вместе с сайтом. Внешнее хранилище обязательно: облачный диск, отдельный сервер, объектное хранилище.
Второе требование касается ресурсов. Сборка архива на большом сайте съедает процессорное время и место на диске. На дешёвом shared-хостинге плагин может не успевать закончить задачу до срабатывания лимита времени выполнения, и вы получите обрубленный архив, который выглядит как бэкап, но не восстанавливается. Проверять размер и целостность архивов надо руками, хотя бы раз в квартал.
Копии на уровне сервера
Если сайт живёт на VPS или выделенном сервере, копии удобнее делать инструментами системы, не завися от PHP и лимитов веб-сервера.
Базу данных официальная документация WordPress предлагает выгружать через phpMyAdmin, через mysqldump или через панель управления хостингом. Команда вида mysqldump --add-drop-table -h хост -u пользователь -p имя_базы отдаёт дамп, который можно сразу сжать в архив. Отдельно документация подчёркивает: такой дамп забирает только базу, файлы темы, плагинов, загрузок и wp-config.php надо копировать отдельно.
Если на сервере установлен WP-CLI, база выгружается командой wp db export. По умолчанию она создаёт SQL-файл с автоматическим именем, забирает все таблицы и берёт доступы из wp-config.php, так что вводить пароль отдельно не нужно. Под капотом команда работает через mysqldump и понимает его флаги, а через параметры можно выгрузить или исключить конкретные таблицы. Это удобно, когда база распухла от логов или кеша какого-нибудь плагина.
Сколько копий и где их хранить
Документация WordPress советует держать от трёх до пяти резервных копий в разных местах: на хостинге, в облаке, на локальном диске. Совет разумный, но абстрактный, поэтому переведём его в рабочую схему.
Разные места означают разные точки отказа. Копия на том же сервере и копия в облаке защищают от разных сценариев: первая спасает от вашей ошибки, вторая от отказа хостинга. Если обе копии лежат на одном аккаунте одного провайдера, у вас не две копии, а одна с дублем.
Глубина хранения важнее частоты. Сайт, который бэкапится ежедневно с хранением одной копии, беззащитен перед медленными проблемами. Вирус или сбой плагина могут проявиться через неделю, и к этому моменту единственная копия уже содержит ту же поломку. Схема, где рядом с последними ежедневными копиями лежат несколько еженедельных и одна ежемесячная, закрывает эту дыру недорого.
Частоту копирования привязывайте к тому, сколько данных вы готовы потерять. Для сайта-визитки, который меняется раз в месяц, ежедневный бэкап избыточен. Для интернет-магазина с заказами в базе даже сутки потерь означают потерянные заказы, и там нужны либо частые копии, либо репликация базы.
Восстановление: часть, которую пропускают
Пока из копии ни разу не восстанавливались, вы не знаете, работает она или нет. Мы просим клиентов проводить учебное восстановление хотя бы раз в полгода, и почти каждый раз оно вскрывает что-то полезное.
Типичные находки. Архив оказывается неполным, потому что плагин пропускал большую папку uploads. Дамп базы делался без параметра, добавляющего удаление таблиц, и импорт падает на существующих таблицах. В копии нет .htaccess, и после разворачивания на новом сервере ломаются постоянные ссылки. Пароль от облачного хранилища, куда уходили архивы, знал только уволившийся администратор.
Учебное восстановление устроено просто: берёте свежий архив, разворачиваете его на тестовом домене или на локальной машине, меняете адрес сайта в базе и смотрите, что получилось. Полчаса работы дают ответ на главный вопрос: сколько времени займёт реальное восстановление и что для него понадобится. У наших клиентов на сопровождении этот ответ записан в документации по сайту вместе с доступами, чтобы в момент аварии никто не искал их по переписке.
Заодно зафиксируйте порядок действий: где лежит последняя копия, кто имеет к ней доступ, в каком порядке разворачиваются файлы и база, что менять в wp-config.php при переносе на другой сервер. Инструкция на одну страницу экономит часы в стрессовой ситуации. Если собирать такую схему самостоятельно некогда, мы настраиваем резервное копирование и регламент восстановления в рамках сопровождения, это часть услуги разработка и поддержка сайтов.
Почему копия разворачивается не с первого раза
Даже полная и свежая копия редко поднимается на новом месте одним движением. Есть несколько мест, где процесс спотыкается предсказуемо, и знание о них экономит вечер.
Первое — адрес сайта внутри базы. WordPress хранит полные URL во множестве таблиц, и после переноса на другой домен или на тестовый поддомен половина ссылок продолжает вести на старый адрес. Прямая замена через SQL-запрос здесь опасна: часть данных лежит в базе в сериализованном виде PHP, где записана длина каждой строки. Грубая замена ломает такие записи, и настройки темы или виджетов слетают.
Правильный инструмент для этой задачи есть у WP-CLI: команда wp search-replace ищет и заменяет строки во всех строках выбранных таблиц и, как сказано в документации, корректно обрабатывает PHP-сериализованные данные. У неё есть флаг --dry-run, который прогоняет всю операцию и показывает отчёт, ничего не записывая в базу. С него и стоит начинать: увидите, сколько замен произойдёт и в каких таблицах, до того как что-то менять всерьёз. На мультисайте команде нужен отдельный флаг для работы со всей сетью, по умолчанию она работает с таблицами текущего сайта.
Второе место — права на файлы. Архив, распакованный от имени root или залитый по FTP другим пользователем, часто получает права, при которых веб-сервер не может писать в папку загрузок. Сайт открывается, но картинки не загружаются, а обновления падают с ошибкой доступа.
Третье — постоянные ссылки. За них отвечает .htaccess на Apache или конфигурация сервера на nginx. Если файл не попал в архив, главная страница откроется, а любая внутренняя запись отдаст ошибку. Лечится это пересохранением настроек постоянных ссылок в админке, но только если сервер разрешает запись в .htaccess.
Отдельный случай: сайт с интернет-магазином
Магазин на WordPress живёт по другим правилам, и стандартная схема «копия раз в сутки» для него плохо подходит. Причина в том, что база меняется постоянно и меняется важным: заказы, оплаты, остатки, регистрации покупателей.
Представьте обычную аварию. Сервер отказал в четыре часа дня, последняя копия снята ночью. Восстановление вернёт сайт в рабочее состояние, но все заказы, оформленные за день, исчезнут. Покупатели их оплатили, деньги пришли, а в системе заказов нет. Дальше начинается ручное сведение выписки из платёжной системы с базой, и техническая авария превращается в разбирательство с клиентами.
Что делают, чтобы не попасть в такую ситуацию. Базу копируют чаще файлов, потому что она меняется каждый час, а картинки товаров лежат неизменными месяцами. Раздельное расписание экономит ресурсы: файлы забираются раз в неделю целиком, база выгружается несколько раз в день. Часть таблиц с заказами можно выгружать отдельно, точечно, командой с указанием конкретных таблиц.
Второй приём касается не бэкапов, а дублирования данных на другом уровне. Заказы, которые уходят в CRM или в учётную систему сразу при оформлении, переживут падение сайта, потому что живут уже в двух местах. Для магазина это часто дешевле и надёжнее, чем гнаться за минутной частотой копий.
И отдельно про тестирование на магазине. Разворачивать копию боевого магазина на тестовом домене надо аккуратно: если в базе остались настройки платёжного шлюза и почтовых уведомлений, тестовая копия может начать отправлять письма реальным покупателям. Перед запуском копии отключите почту и переведите платёжные модули в тестовый режим.
Частые ошибки, которые дорого стоят
Собрали список того, что регулярно всплывает при аудите чужих сайтов.
- Копии лежат внутри сайта. Папка с архивами в корне WordPress не только бесполезна при отказе сервера, но и опасна: если она доступна по прямой ссылке, скачать вашу базу может кто угодно.
- Бэкапится только база. Самая частая ошибка ручных схем. Дамп базы делается легко, поэтому им и ограничиваются, забывая про uploads и плагины.
- Никто не проверяет, что задание выполняется. Плагин отключился после обновления, задача по расписанию перестала запускаться, место в облаке кончилось. Без уведомлений об успешном завершении вы узнаете об этом в худший момент.
- Копия снимается прямо перед обновлением и сразу перезаписывается. Если проблема после обновления проявится через три дня, откатываться будет некуда.
- Доступы к хранилищу есть у одного человека. Обычная ситуация в компаниях, где сайтом занимался фрилансер. Доступы должны лежать в корпоративном хранилище паролей, а не в голове подрядчика.
- Архив не шифруется и лежит в общем облачном диске. Внутри wp-config.php с паролем от базы и таблица пользователей с хешами. Такой архив стоит держать в закрытом хранилище с ограниченным доступом.
Что делать прямо сейчас
Если вы читаете это и не уверены в своих бэкапах, вот порядок действий на ближайший час.
Начните с проверки того, что уже есть. Зайдите в панель хостинга и посмотрите, есть ли автоматические копии, за какие даты и что в них входит. Затем откройте админку WordPress и проверьте, установлен ли плагин резервного копирования, работает ли расписание и куда уходят архивы. Довольно часто оказывается, что плагин стоит, но последняя удачная копия датирована прошлым годом.
Дальше закройте самую очевидную дыру. Если копии никуда не выгружаются, настройте выгрузку во внешнее хранилище. Если бэкапится только база, добавьте файлы. Если копия одна, увеличьте глубину хранения хотя бы до недели.
И поставьте учебное восстановление в календарь на конкретную дату. Формулировка «сделаем, когда будет время» на практике означает, что этого не случится никогда, а без проверки вы так и не узнаете, работает ваша схема или только выглядит рабочей.
Частые вопросы
Достаточно ли бэкапов, которые делает хостинг?
Как единственный уровень защиты обычно нет. Вы не управляете частотой и глубиной хранения, не всегда можете скачать архив себе, а при блокировке или закрытии аккаунта теряете и сайт, и копии одновременно. Копии хостинга хороши как быстрый способ откатиться, но рядом должна быть независимая копия во внешнем хранилище.
Можно ли обойтись экспортом из раздела «Инструменты»?
Нет. WXR-файл содержит записи, страницы, комментарии, произвольные поля, таксономии и пользователей, но не включает загруженные файлы, темы, плагины и их настройки. Из него нельзя восстановить сайт целиком, это инструмент переноса контента.
Как часто нужно делать резервное копирование WordPress?
Отталкивайтесь от объёма данных, который допустимо потерять. Сайт-визитка с редкими правками спокойно живёт на еженедельной копии. Магазин или сайт с формами заявок требует ежедневных копий, а иногда и более частой выгрузки базы. Важнее частоты то, сколько разных точек восстановления вы храните.
Где хранить архивы, чтобы это было безопасно?
В месте, не связанном с хостингом сайта, с ограниченным доступом и без публичных ссылок. Архив содержит wp-config.php с доступами к базе и таблицу пользователей, поэтому общий облачный диск с открытой ссылкой для него не подходит.
Что делать, если сайт уже упал, а копии нет?
Сначала не трогайте сервер: любые попытки чинить вслепую могут затереть то, что ещё можно вытащить. Запросите у хостинга все доступные копии, включая технические. Если файлы на диске целы, снимите их до начала любых работ. Часть данных иногда восстанавливается из кеша поисковых систем и веб-архива, но это спасает только текст, не структуру сайта.
Настроенная схема резервного копирования стоит недорого и почти не требует внимания: пара часов на старте и одна проверка раз в полгода. Её отсутствие обходится в дни простоя, в потерянные заявки и в контент, который приходится собирать заново из кеша поисковиков. Разница между этими двумя сценариями становится очевидной ровно в тот день, когда что-то ломается, и в этот момент менять что-либо уже поздно.