Облачные сервисы Amazon AWS, Amazon EC2, хостинг, облачные вычисления

14Июн/118

Как забэкапить WordPress в Dropbox

Вы когда-нибудь теряли свои данные? Вам приходилось дико материться и рвать на себе волосы из-за того, что самые важные файлы пропали в самый ответственный момент?

Если да, то у вас, наверняка, уже настроена система резервного копирования для всех важных файлов, в том числе, для вашего блога на WordPress. (Если нет, то срочно установить, настроить, протестировать!).

Ну а я хотел бы поделиться еще одним способом для бэкапа. Это плагин WordPress Backup to DropBox. Установил я его недавно, но уже достаточно, чтобы проверить, что он работает :) Этот плагин выполянет резервное копирование всего блога нарямую в DropBox. Причем аутентификация происходит один раз через OAuth, так что никаких паролей сохранять не надо.

Особенности:

  • Данный плагин создает резервную копию не только для базы, но для всего контента блога. Включая собственно сам движок WordPress, все темы, плагины, загруженный контент - в общем абсолютно все, что находится в корневой папке блога.
  • При этом, в самом начале создается резервная копия базы в папке wp-content/backups/имя_базы-backup.sql. Ну и собственно поэтому копия базы и попадает бэкап.
  • В папке wp-content/backups создается файл .htaccess, который запрещает доступ к файлам в этой папке, если блог работает под Apache. Но если у вас другой http server, то стит позаботиться об этом дополнительно. Например, для lighttpd поможет следующая настройка:
$HTTP["url"] =~ "^/wp-content/backups/" {
    url.access-deny = ( "" )
}

Минусы:

  • Выбранное время копирования только приблизительно. На самом деле копирование начинается при первом запросу к блогу после указанного времени. (да, это не cron-задания, здесь используются внутренние механизмы WordPress для планировки)
  • Если блог на Linux/Unix, то при копировании в DropBox потеряются все права доступа к файлам. (Хотя, возможно, это только я такой параноидальный - изначально выставил минималные права доступа и открывал потом по мере необходимости...)
  • Нет возможности указать фильтр на то, что не надо закидывать в DropBox. У меня, например, содержимое блога хранится еще и в Git, и при этом мне нет необходимости копировать папку .gitсо всем ее содержимым в Dropbox.

Плюсы

  • Устанаваливается и настраивается очень легко.
  • Автоматически добавляется версионирование файлов (функция дропбокса).
  • Если уж и придется восстанавливать блог, то для этго из дропбокса надо будет
    • Скачать один zip-архив (дропбокс позволяет скачивать папки в виде заархивированного файла)
    • Распаковать его в нужное место
    • Восстановить базу (файл для восстановления будет в том же архиве)
    • ...ну и все - можно снова запускаться!

Короче, тем, у кого не настроена более навороченная система резервного копирования - очень рекомендую!

PS Тем, у кого еще нет аккаунта в DropBox - срочно создавать!

Связано с категорией: Без рубрики Оставить комментарий
Комментарии (8) Пинги (0)
  1. спасибо, действительно полезный плагин

  2. Ты бы хоть рассказал тетенькам, что такое дропбокс, сразу виден технарь :) )

    • Да уж, не до конца еще пропали технарские наклонности… Надо будет сделать отдельный обзор дропбокса… хотя вот хоть что-то, что когда-то писал: http://sviridoff.livejournal.com/3157.html, может кому пригодится – там еще альтернатива есть :)

  3. Доброго времени суток!
    А как вы настроили сохранение файлов wp в git?

    • да собсно как обычно при работе с git’ом: git init в каталоге wp, далее коммиты вручную :) (автоматические коммиты не делаю принципиально, коммичу только при наличии изменений типа обновления движка или плагинов). И, соответственно, локальный репозиторий можно залить на любой git-хостинг либо слить к себе.
      Правда, имея несколько блогов с WP, делал еще такой финт: движок WP и всех плагинов сливал а один репозиторий: WP и каждый плагин в отдельном бранче, а под конкретный блог – мержил все необходимое вместе.

  4. А можно подробнее о восстановлении, а то для меня, чайника, не очень понятно. Как сбросить бэкап, например, на субдомен?

  5. Уже разобрался. Я думал, что восстановление можно сделать по какой-то одной кнопке, которую не заметил. Но поскольку таковой нет, сделал восстановление на субдомене test своими ручками. Сначала папку субдомена test очистил, потом сжал содержимое Dropbox zip-ом. Файловым менеджером хостера загрузил в папку test и там разархивировал. И всё заработало: на субдомене появилось то же, что есть на домене.

    • Прошу прощения, не получилось сразу ответить.
      Все верно, архив надо зугрузить на хостинг самостоятельно и там настроить. (Правда, у меня папка, куда заливаются архивы, на компы не скачиваются, но прямо из дропбокса можно скачать все содержимое сразу в zip-архиве).

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

      А именно:
      Скрипт для создания базы и заполнения ее данными лежит в wp-content/backups.

      В случае восстановления базы для того же самого домена надо только удалить старые таблицы и запустить этот скрипт – он все пересоздаст заново.

      В случае поднятия отдельного домена, но с использованием того же сервера баз данных, надо будет использовать другое имя базы. Для этого создать базу с нужным именем. Затем изменить имя базы в скрипте content/backups/domainname-backup.sql. В районе 17й строчки:

      CREATE DATABASE mydb;
      USE mydb;

      (подставить правильное имя вместо mydb)

      После этого в файле wp-config.php установить правильнве значения для переменных DB_NAME, DB_USER, DB_PASSWORD (а при необходимости и DB_HOST).

      Опять же, если поднимается субдомен, то стоит также обновить AUTH_KEY, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT, AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY. Проще всего взять автосгенерированные здесь: https://api.wordpress.org/secret-key/1.1/salt/

      Ну и вот после этого можно запускать (конечно же, настройка вебсервера также подразумевается).

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


Leave a comment

(required)

Protected with IP Blacklist CloudIP Blacklist Cloud
 

Нет обратных ссылок на эту запись.

close