l

Резервная копия сайта на WordPress

18.02.2015 2260 Пишу 8 комментариев wordpress, компьютерный практикум

Давно я собирался написать статейку о том, как делать резервные копии сайта на wordpress и как их потом разворачивать, скажем, на домашнем компьютере. Тема как актуальная, так, в общем, и не новая — об этом существует масса статей. Так зачем же ещё одна? Лично мне потребовалось почти год плотно работать с сайтами на вордпрессе (как создавать с нуля, так и поддерживать существующие) прежде, чем я натолкнулся на действительно интересную статью по данному вопросу. Но, сначала о том, как до недавнего времени я делал резервные копии сам.

В ручном режиме

Само собой, самый доступный из всех способов сделать резервную копию сайта — вручную. При этом мало что зависит от выбранного вами движка. Так создаются резервные копии при наличии любой CMS или даже без неё. От чего на самом деле зависит данный метод, так это от предоставленных вашей хостинговой компанией инструментов. Резервная копия сайта состоит из двух компонентов: файловая структура «движка» и дамп базы данных (дамп БД), если таковая имеется. Файлы копируются чаще всего с использованием ftp-протокола, а базу данных можно стащить инструментом PhpMyAdmin, или каким-то иным, предоставленным хостером способом. Позвольте не расписывать этот метод подробно — о нём, в самом деле, тьма материала в сети. Я остановлюсь на важном.

При этом методе копирования все данные в БД остаются как есть. Это и хорошо, и плохо. Раз уж мы говорим здесь о вордпрессе, то я хочу обратить ваше внимание на одну его особенность. Если, публикуя в своих статьях какие-то фото, вы используете стандартный инструмент «Медиафайлы», то картинка ваша попадет в папку /wp-content/uploads. Дальнейший путь к иллюстрации зависит от настроек самого вордпресса. В моём случае путь к картинкам, которыми иллюстрирована эта статья, например, выглядит так: /wp-content/uploads/2015/02 — к адресу добавляются папки текущего года и месяца. Так WP сортирует медиафайлы. Вот только в статью, а значит и в базу данных, вордпресс сохранит не этот путь, а полный, абсолютный путь, включающий в себя и название сайта. То есть путь к иллюстрациям будет таким: http://www.vsmirnov.ru/wp-content/uploads/2015/02. Если же вы используете сторонние плагины, они могут с путями загрузки файлов обходиться ещё вольнее. То есть заранее и не скажешь, какие пути — абсолютные (те, что включают адрес сайта) или относительные (без доменного имени) у вас сохранены. Улавливаете, о чём я?

При переносе сайта на локальный компьютер вручную, если пути были абсолютными, после распаковки дампа БД, в ней все пути к картинкам будут вести на ваш сайт в интернете. То есть, стоит вам отключиться от интернета, всё — ваш сайт остался без иллюстраций! Как быть? — Править базу данных, заменяя адрес сайта, в моём случае «http://www.vsmirnov.ru» на то доменное имя, которое я планирую использовать на домашнем компьютере. Само собой, править везде, где оно встречается. Для этого дамп БД открывают в толковом текстовом редакторе, вроде notepad++ и пользуются автозаменой.

В этом месте стоит оговориться, что специалисты ругают подобный метод. Дескать, нельзя вот так бездумно заменять одно доменное имя в БД на другое. Вдруг, мол, данные используются для сериализованных массивов (в них у данных есть оговоренное количество символов)? В защиту метода скажу, что за почти год активной работы с WP я ни разу с таким не сталкивался и сайты при переносе на хостинг или с него распрекрасно работали и тут, и там. Однако если с этим ни разу не сталкивался я, ещё не означает, что такого просто не может быть. И хотя, при должной сноровке, при ручном переносе сайта не должно у вас возникать трудностей, хотелось бы пользоваться каким-то иным методом для создания и разворачивания сайтов из резервной копии. В самом деле, «движок» у нас используется или где? :)

Плагин «Duplicator»

Верно, что нет ничего нового в подлунном мире. Инструмент для автоматизированного копирования сайтов на вордпрессе есть и давно. Более того, вероятно и не один, но речь я поведу о плагине «Duplicator». Давайте его установим. В консоли идём в «Плагины», выбираем там «Добавить новый» и в строке поиска набираем «Duplicator», как показано на картинке ниже.

Плагин найден, жмём «Установить».

Затем — «Активировать плагин». После этого он появляется в списке установленных плагинов, но ценнее всего то, что в консоли ниже, появляется меню Дупликатора.

Перейдём в него. Видим то же, что и на картинке ниже. (Вообще-то плагин давно переведён на русский язык, но на момент написания этой статьи — февраль 2015 года — имелась только англоязычная версия и все иллюстрации из той старой версии. Русским плагином пользоваться ещё проще.)

Видим перед собой пустую пока вкладку «Packages» — пакеты, не обращаем на это внимания и переходим во вкладку «Create New» — создать новый. Обратите внимание на Подчёркнутые места.

Фраза «Requirements: Pass» означает, что для работы плагина все установки верны. На хостинге, скорее всего так оно и будет. Хостинговые компании придирчиво следят за своим ПО, и на их серверах зачастую установлены последние версии программ и подключены всевозможные модули. Если где-то и могут возникнуть проблемы, так это на собственном компьютере, но мы к этому вернёмся чуть позже.

Второе подчёркнутое место — название будущего пакета. Я оставил у себя год, месяц и число, а затем указал своё название резервной копии сайта. Во избежание, так сказать, я не использовал русских букв и пробелов. В моём случае имя получилось таким «20150214_backup_site». Чуть ниже идут два выпадающих списка: Archive и Installer. В первом из них можно указать какие папки и таблицы БД необходимо архивировать. По-умолчанию, делается полная копия сайта, и так как мне этого только и нужно, то здесь я ничего не меняю. Во втором выпадающем списке можно указать параметры доступа в базе данных на новом месте (там, где вы будете разворачивать свой сайт из резервной копии), а также указать новое доменное имя. Я и здесь не вношу никаких изменений, ибо это можно сделать позднее. Поэтому просто жму кнопку «Next» — далее.

Происходит сравнительно короткое сканирование сайта с учётом возможных изменений, если вы их внесли. К примеру, можно было бы отключить от добавления в архив той самой папки uploads. Не знаю, кому может понадобиться сайт без иллюстраций в статьях, но возможность такая есть. Впрочем, если статей вы пишете на своём сайте много, а фотографии размещаете редко и неохотно, то может быть в этом и есть смысл. Для создания резервной копии сайта остаётся только нажать кнопку «Build» — создать. После того, как скрипт отработает, во вкладке «Packages» появится строчка с резервной копией.

И хотя вся информация интересна, красной рамкой выделено главное — кнопки, нажав которые, вы скачаете собственно архив сайта и скрипт installer.php. Дальнейшие ваши действия разнятся лишь тем, собираетесь ли вы развернуть сайт из резервной копии на локальном компьютере, или закачать на какой-то хостинг. В обоих случаях вам придётся оба файла положить в корневую папку сайта. На локальном компьютере, вы можете это сделать проводником, на хостинг можно файлы закачать по ftp-протоколу любой из программ, к которым вы привыкли. Важно лишь то, чтобы файлы попали в корневую папку сайта.

Я копирую эти файлы в папку на компьютере, запускаю «Денвер», в нём мой сайт располагается по адресу http://moysite/ и доступен он только локально. Само собой, сайт я уже переносил с хостинга на свой компьютер. Это значит, что на локальном веб-сервере уже создана папка с сайтом и база данных. Именно в корневую папку с WP я и загрузил файлы архива сайта и инсталлер. Само собой, для разворачивания обновлённого сайта я стану использовать созданную ранее БД. Итак, файлы скопированы куда нужно, «Денвер» запущен и в браузере я пишу адрес: http://moysite/installer.php, чем запускаю скрипт для распаковки сайта из резервной копии.

Всё важное снова выделено красным цветом. Прежде всего, фраза «Requirements: Pass» означает, что всё необходимо для работы скрипта уже включено. При первом запуске это было не так. Для его работы, к примеру, требуется PHP 5.3, а у меня была версия 5.2. Пришлось скачать обновлённый пакет «Денвер» с нужной версией интерпретатора PHP и переустановить пакет. Дальше рамочкой обведены настройки доступа к БД. Прежде всего, я выбрал пункт «Connect and Remove All Data» — соединиться с уже имеющейся БД и стереть в ней все данные. Если вы разворачиваете сайт впервые, то надо будет выбрать «Create New Database» — создать новую базу данных. Остальные настройки зависят от хостинга. Host — сервер баз данных, в моём случае установлен как localhost. Name — имя БД, которая создана для моего сайта, установлена как «mysite». User — пользователь БД, в «Денвере» это «root» и, наконец, пароль пустой. Таковы, повторюсь, настройки доступа к БД сайта на моём компьютере, где в качестве веб-сервера установлен пакет «Денвер». В случае, если у вас установлен не он, или вы разворачиваете сайт на хостинге, там будут свои настройки. Их необходимо аккуратно внести. Никакие другие настройки я не меняю и не включаю — не требуется. Лишь ставлю галочку против пункта «I have read all warnings & notices» — я прочитал все предупреждения и уведомления и нажимаю кнопку «Run Deployment» — запустить развёртывание. Упс!

Ошибка! Скрипт сломался. )) На самом деле сообщение «A wp-config.php already exists in this location.» значит, что в папке, куда загружен скирпт, уже имеется файл wp-config.php — конфигурационный файл вордпресса, что логично, ведь я уже разворачивал в этой папке свой сайт ранее. Не паникуем. Заходим в папку с сайтом и банально удаляем этот файл. Затем в браузере нажимаем кнопку «Try Again» — попробовать снова. Если вы озаботитесь и удалите этот файл до запуска инсталлятора, то у вас не будет этого сообщения об ошибке. Итак, файл удалён, кнопка «Try Again» нажата, снова нажимает «Run Deployment». Ждём какое-то время, пока скрипт разворачивает сайт из резервной копии. Когда он закончит, мы увидим следующее:

«Old settings» — старые настройки включают в себя домен, откуда скопирован сайт и путь к сайту на сервере (я позволил себе скрыть его). «New settings» — доменное имя и путь к сайту на сервере, где вы и разворачиваете сайт. В моём случае это путь на локальном компьютере. В строчке «Title» — название сайта, вы можете видеть что-то невразумительное. Так плагин увидел название моего сайта, которое было введено кириллицей. Ну что ж, должны же быть у него какие-то недостатки, верно? Я стираю эту строчку, вписываю вместо той тарабарщины своё название «Домашняя страница Смирнова Владимира» и жму кнопку «Run Update» — запустить обновление и снова какое-то время жду. Результатом работы скрипта будет следующее:

Фраза «Errors: Deploy (0) Update (1) Warnings: (0)» сообщает нам: «Ошибок при разворачивании — 0, при обновлении — 1, предупреждений — 0». Это значит, сайт развёрнут, но при обновлении проскочила таки ошибка. Связана она была с русскими названиями картинок, загруженными в качестве аватарок пользователей. Это не столь важно, идём дальше. Обратите внимание на ссылку «File Cleanup» — очистка файлов. Нажмите её всенепременно. Скрипт сотрёт файлы, которые создавались в корневой папке сайта во время его работы. По завершении работы инсталлера вас выбросит на страницу входа в админку сайта.

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

Очень надеюсь, что моя статейка окажется для вас не бесполезной. Если что-то осталось неясным, пишите комментарии под ней, я постараюсь ответить. Хотя мне кажется, что работа плагина «Duplicator» вполне понятна, не смотря на то, что он не переведён на русский язык.

А тем, кто дочитал до этого места, бонус — кино на эту же тему.

8 комментариев на «Резервная копия сайта на WordPress»

  1. Спасибо. Классная статья…очень мне помогла!)

    • Володька Смирнов Володька Смирнов:

      Дим, спасибо за отзыв. Так понятно, что написана она не зря. )

  2. Василий:

    После восстановления сайта не открываются ссылки, которые содержат кириллицу.
    В папке Upload их не оказалось.
    Как это лечится?

    • Володька Смирнов Володька Смирнов:

      Василий, я столкнулся с подобным лишь раз и довольно давно. Загружая картинки к статьям, иллюстрации (сами файлы перед загрузкой) я называю латиницей. То есть кириллица и пробелы попросту исключены. И столкнулся с русскими буквами в именах файлов я только в аватарах. У меня на сайте разрешена регистрация пользователей. Логины у них обычно латиницей введены, а вот самоназвания пользователей могут быть русскими. И если человек загрузит аватар, то файл автоматически называется с использованием русских букв. Так и вышло, что появились в папке Upload русские названия. Duplicator при переносе искаверкал названия этих файлов — вместо кириллицы появилась какая-то тарабарщина. Стало быть, в папке Upload данные файлы присутствовали, но с испорченными именами. Лечилось это ручным переименованием каждого из файлов (благо, их как и пользователей на сайте, было немного).

      В итоге, могу посоветовать вам действовать также — переименовывать файлы вручную. Впрочем, повторю, у меня подобная проблема была очень давно, с какой-то старой версией данного плагина. С тех пор он многократно обновлялся. Очень вероятно, что этот баг был исправлен. Во всяком случае, сайт я переносил ещё много раз, но с проблемой этой больше не сталкивался. А стало быть, у меня к вам вопрос: вы точно используете на своём сайте последнюю версию плагина Duplicator? Если нет, очень советую вам обновить его до самой последней доступной версии и затем сделать резервную копию снова.

      Ну и общее замечание, никогда не загружайте на ваши сайты иллюстраций с именами, содержащими кириллицу и пробелы. Движок такие файлы пропустит, а вот при создании резервных копий или переносах сайта как выйдет — Бог весть.

  3. Здравствуйте,уважаемый. При создании архива вылазит ошибка:504 Gateway Time-out. Что можно посоветовать? С уважением

    • Володька Смирнов Володька Смирнов:

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

  4. Tony:

    Вот, нормальная и подробная статья, афтр, плюсую Вас!

  5. Володька Смирнов Володька Смирнов:

    Что ж, спасибо за высокую оценку моего скромного творчества.

Оставьте ваш отзыв:

 

Свежие отзывы

  • Володька Смирнов: Возможно вы правы, Иван, но от этого не менее приятно получа...
  • Иван: Спасибо большое вам очень помогло. ваша статья ещё не один г...
  • Володька Смирнов: Что ж, приятно, что спустя годы эта статейка ещё актуальна и...
  • Dkfl: проще и доступнее не бывает. только понадобилось - сразу же ...
  • Vera: Большое спасибо за статью! Очень понятно все объяснили! )...
Real Time Web Analytics