Бэкап это отлично, еще лучше, если его иногда тестишь. Лучший тест — попытка раскатать. Вот и я решил потестить и получил глобальный ппц 🙂

Начнем по порядку, воспользовался я Dropbox backup. Вроде как все просто, привязал по инструкции к дропбоксу, сделал бэкап. Почему-то в нем куча файлов(видимо для того, чтобы решить возможные проблемы с отправкой больших файлов из php). Визуально бэкап выглядит так:

Разархивировал я это счастье и тут появились первые проблемы. Ну во-первых wordpress привязывается к доменному имени, а восстановить его мне нужно на другом. Можно конечно сделать в файле hosts запись из разряда:

Запилить на компе веб-сервер, php и mysql. Последние 2 крайне желательно той же версии. Почему желательно, ну с php проблем меньше, врядли сам wordpress значительно переписывает собственные исполняемые файлы(а значит они будут работать и под старым и под новым интерпретатором), а вот восстанавливать mysql на другой базе чревато. К счастью, для бэкапа нам нужна только база wordpressa. Я, в свою очередь, на работе перевел офисную атс с elastix 2.5 на elastix 4.0 (Для понимания это CentOS 5.9 vs CentOS 7, с конкретными такими отличиями. Соответственно там разные версии, а местами и структуры, базы данных. В общем кучу конфигов пришлось руками переносить и какими-то костылями сливать базу нового elastixa и старого в одну. Сейчас все работает, бэкапится и восстанавливается и это прямо чудо какое-то. Настроить же с нуля диалплан размером в мегабайт, штук 60 номеров, несколько шлюзов, ивр, факсы, связь с корпоративным порталом(web push, asterisk ami) не вызывало во мне никакого энтузиазма. Переезд был вынужденным, т.к. старая атс потихоньку клеила ласты, а CentOS 5.9 сняли с поддержки. Снятие с поддержки — это в т.ч. и то что программы для него будут инсталлится через пень колоду). В общем все это лишь к тому, что PHP и MySQL должны быть одинаковыми, тогда точно все будет ок.

Итак, разархивировав все файлы, дамп mysql нужно забрать из: \wp-content\Dropbox_Backup\mysqldump.sql. При заливке на хостинг(если поддерживается zip) лучше его сжать winrar-ом. Например 000webhost.com это поддерживает, при этом размер упакованной базы (начальным размером 14МБ) всего 700КБ. Учитывая, что поддерживается загрузка файлов весом до 2МБ через phpMyAdmin, то нам её даже резать не надо.

Здесь есть важная уязвимость, не храните локально бэкап и(или хотя бы) не кладите его в папки, доступные из интернета(ну или закройте к нему доступ с помощью htaccess, что попытается сделать и сам dropbox backup), т.к. украв и раскатав бэкап вашей базы сломать wordpress будет не очень сложно, уже не говоря о том что в исполняемых файлах содержится логин и пароль доступа к вашей БД на сервере. Учитывая, то что бэкап до заливки в дропбокс будет лежать на сервере, рекомендую сменить папку для бэкапа на какую-нибудь недоступную из интернета(php может работать с файловой системой на сервере и без этого всего), либо надеяться на лучшее, хотя бы проверив работу htaccess(попробовав вытащить что-нибудь из папки с бэкапом). Например, если веб-сервер индексирует все в папке /public_html, положите файлы в папку /backup и уже не будете зависеть от надежности веб-сервера и работы htaccess:

Залив дамп в базу данных, нам необходимо в таблице wp_options изменить содержимое двух ячеек siteurl и home на наш урл

Далее необходимо закинуть файлы в корень сайта(т.е. в корневую папку, которую индексирует веб-сервер). Если закинуть не в корень, будет все сложно, т.к. wordpress обращается к /index.php в ряде случаев и, естественно, ожидает что этот index.php будет не каким-то левым. Прописать в базе путь в другую(не корневую) папку у меня результата не дало. В wp-config.php необходимо заменить параметры на актуальные:

// ** Параметры MySQL: Эту информацию можно получить у вашего хостинг-провайдера ** //
/** Имя базы данных для WordPress */
define('DB_NAME', '***************');
 
/** Имя пользователя MySQL */
define('DB_USER', '*****************');
 
/** Пароль к базе данных MySQL */
define('DB_PASSWORD', '************************************');
 
/** Имя сервера MySQL */
define('DB_HOST', '*************************');

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

Собственно после этого оказалось, что все уже норм. Из админки бэкап не восстанавливается(предполагаю из-за большого размера дампа) на данном хостинге.