Как уберечься от проблем с хостингом

Что делать, если ваш хостер умер

К сожалению любой хостер — это не вечно живой дедушка Ленин и потенциально обладает нехорошей тенденцией умирать именно тогда, когда это меньше всего ждешь. Эта трагическая случайность и произошла в прошлый вторник с моим, теперь уже почти бывшим, хостером «Украина-Хост».

Понятно, что сразу же суетиться я не стал — потенциально, мог произойти лишь небольшой сбой в работе серверов и через максимум сутки сайт бы снова заработал (неприятно, но пережить можно). Но учитывая, что сервер «упал» во вторник утром и по состоянию на утро четверга все так же валялся пузом кверху и даже не пытался встать, я понял, что тут счастья мне точно не будет — и принял решение переезжать. (Кстати, сервер поднялся только вечером в воскресенье — через 6 дней с момента падения).

Зачастую, главной бедой становится не только сама неработоспособность сайта, но и отсутствие возможности быстро получить резервные копии файлов и сразу же перенести проекты к другой, более «живучей» хостинг-компании. Учитывая, что в моем случае поддержка упорно игнорировала все вопросы на тему — «когда все заработает» (что, в принципе, и понятно — нечего отвечать), связываться с ними еще и по вопросу получения резервных копий смысла явно не было ни малейшего.

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

Задолго до произошедшего, я создал аккаунт на Dropbox (зарегистрировавшись по этой ссылке, вы получите +250 Мбайт дополнительногго пространства) — меня давно интересовала идея организовать себе онлайн-хранилище резервных копий сайтов, но с обязательной синхронизацией с локальным компьютером. С одной стороны, удобство онлайна — все копии всегда под рукой и в случае аварии легко восстанавливаются в любой момент и с любого компьютера, а с другой — преимущества оффлайна, позволяющие не зависеть от работоспособности сервиса.

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

Готовимся к «клинической смерти»

Именно к этой категории плагинов и относится расширение под названием WP Time Machine, позволяющее автоматически создавать резервные копии жизненно важных частей сайта с загрузкой получившегося архива на Dropbox. Особо нужно отметить тот набор файлов, которые входят в состав резервного пакета:

  • полная копия базы MySQL;
  • полная копия содержимого папки wp-content;
  • основной файл .htaccess — лежащий в корне сайта.

Одним из больших преимуществ формирования именно такого пакета, является наличие в архиве всей папки «wp-content». К сожалению, основная часть плагинов для бекапирования чаще всего формирует только копию базы данных, а вот файлы нужно сохранять вручную.

При этом, директория «wp-content», как вы помните, содержит не только папку «uploads» со всеми загруженными файлами, но также и папку с плагинами, темами и языковыми файлами WordPress. То есть, по-сути, это именно те файлы, которые и являются вашей личной частью блога — все остальное относится уже к платформе и разворачивается на сервере по-умолчанию — при установке CMS. Единственное чего не хватает, но, думаю, автор плагина через некоторое время добавит — это копии файла wp-config.php.

Наличие папок «plugins», «themes» и «languages» позволяет развернуть сайт на новом месте жительства в несколько раз быстрее, по сравнению с обычной установкой WordPress. С одной стороны — не нужно вручную устанавливать все расширения, а с другой — любые правки, внесенные в файлы плагинов — PHP, CSS, переводы плагинов, языковые переменные и т.д. — не нужно производить заново.

Давайте подробно рассмотрим настройки плагина WP Time Machine, которые я использую. Сразу обратите внимание, что у плагина несколько нетрадиционный интерфейс — выбор производится в одном и том же пункте опции.

Интерфейс и опции WP Time Machine

Current offsite service: Dropbox — выбор сервиса для сохранения резервных копий. Плагин предоставляет 3 варианта сохранения ваших резервных копий: Dropbox, Amazon S3, FTP. Первый — хранение резервных копий на серверах Dropbox, второй — Amazon Simple Storage Service (Amazon S3) и третий — ваш внешний ftp-сервер.

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

File format: .tar.gz — выбор формата для создания архива. Альтернативой является формирование архивов в zip, но на моем сервере этот режим не заработал, а кроме того — архив в .tar.gz меньше по размеру, чем в .zip.

Using Post Publish event to trigger backups — если включить эту опцию, то резервная копия будет создаваться автоматически при публикации новой записи в блоге.

Use time-stamped subdirectories to store multiple backups — формировать название папки резервной копии с указанием даты и времени создания. Например, «backup-2010-10-01».

Include cache related directories — включить в архив папку cache, расположенную в папке wp-content. В принципе, включать эту опцию нет особой необходимости, разве что вам по какой-либо причине необходимо обязательно перенести кеш страниц.

Stop logging | View log | Clear log — опции, управляющие лог-файлами плагина. Какие-либо отдельные настройки — не требуются.

Email — если вы выбрали  в качестве сервиса для хранения резервных копий Dropbox, в это поле необходимо ввести тот email, с которым вы зарегистрированы в сервисе.

Password — ваш пароль для доступа к сервису Dropbox.

После ввода пароля, обязательно нажмите на строчку «Save my Password» (она изменится на Don't save my Password"). В противном случае, пароль не сохранится и автоматическое создание резервных копий будет невозможно, т.к. плагин не сможет войти на сервер Dropbox.

Directory — папка в аккаунте Dropbox, в которую будут складываться сформированные резервные копии. Я использую вот такой вариант «backups/proofsite/proofsite», в котором backups — основная папка для резервных копий, «proofsite» — папка для хранения резервных копий этого блога и «proofsite» — заготовка, к которой будут приставлены время и дата создания архива.

После завершения настройки, нажимаем кнопку «Generate wp Time Machine Archive», ждем появления надписи о том, что архив создан и обязательно проверяем его физическое наличие на Dropbox.

Возрождаемся из пепла

Итак, до падения сервера на «Украина-Хост», я установил плагин WP Time Machine и, не смотря на то, что сервер был полностью недоступен — легко развернул копию блога на новом сервере. Ниже описана последовательность моих действий:

  1. Заказать и оплатить новый хостинг. Кстати, многие хостинг-компании предоставляют 3-5 дней тестового периода, которым можно воспользоваться как временным пристанищем — без оплаты.
  2. Скачать свежую версию WordPress — раньше я пользовался отличной сборкой от Lecactus, но в последнее время Иван переквалифицировался в «ФотоКактус» и начиная с 2.8.6, сборки перестали выходить. Соответственно, я взял русскую версию с официального сайта WordPress.
  3. Установить свежую версию на новый хостинг. Обычная классическая установка WordPress — ничего экстраординарного.
  4. Открыть панель управления доменами регистратора сайта и изменить DNS записи, перенаправив адресацию домена на новый хостинг — сделаем это заранее, чтобы не терять время.
  5. Распаковать архив «wpTimeMachine-content-files.tar.gz», ранее созданный WP Time Machine.
  6. Закачать полученное содержимое папки «wp-content» — на новый сервер с помощью FTP или менеджера файлов, с заменой существующих файлов.
  7. Переименовать файл «wpTimeMachine-htaccess.txt» в «.htaccess» и закачать его в корень новой копии WordPress.
  8. Создать с помощью панели управления хостингом новую базу данных, нового пользователя и дать ему соответствующие права.
  9. Отредактировать файл «wp-config-sample.php», добавив в него информацию о новой базе и новом пользователе и переименовав его в «wp-config.php».
  10. Импортировать содержимое файла «wpTimeMachine-data-files.sql» с помощью phpMyAdmin в новую базу (функция «импорт»). Созданные WordPress на этапе установки демонстрационные данные будут удалены.
  11. Дождаться обновления DNS (до 72 часов, но обычно гораздо быстрее) и открыть сайт по старому домену, но на новом хостинге.

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

А как вы решали проблемы с упавшими серверами и переносом сайта?

Обратите внимание! wp Time Machine версии 1.9.21 вызывает проблемы с загрузчиком изображений в WordPress 3.3! Либо откатитесь на версию 1.9.16 (у меня она работает) либо до появления новой версии, рекомендуется не использовать этот плагин.

77 комментариев к “Как уберечься от проблем с хостингом”

  1. Супер! Как раз недавно назрела необходимость. Жаль только бесплатного дропбокса уже начинает не хватать :) И ещё вопрос — а насколько сам процесс бэкапа нагружает сервер? Вы не тестировали?

    ОтветитьОтветить
  2. Дааа, 6 дней это, конечно, жесть.

    По теме: сам пока по старинке делаю бэкапы в ручную с помощью бэкап-плагина от David Schneider'а и архивирую локально. Плагин может делать бэкапы (и бд и файлы) по расписанию автоматом и слать письмо типа все ок или что-то не сработало. Но все равно бэкапит в локальную папку на том-же хосте. Что есть минус.

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

    ОтветитьОтветить
  3. А я все как-то больше по старинке... самописные скрипты на шелле запускаемые кроном. А дальше — варианты... либо на почту либо с домашнего сервера по scp (по крону же).

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

    ОтветитьОтветить
  4. @Vlad Ossipov: спасибо за комментарий.

    Дропбокс можно расширять, если я не ошибаюсь, до 8GB за счет привлечения рефералов — они тоже получают свои бонусы.

    В процессе формирования архива — да, довольно сильно, но это пиковая нагрузка.

    ОтветитьОтветить
  5. @Хитрый Админ: спасибо за комментарий.

    Но все равно бэкапит в локальную папку на том-же хосте. Что есть минус.

    Полностью согласен, вот именно этот момент мне и не нравится — в принципе, можно, конечно, дописать выгрузку на отдельный FTP или разбираться с API того же Dropbox, но в таком случае получится просто копия, например, WP Time Machine.

    Кстати, видел бэкап-плагины для WP которые архивируют сайт и шлют архив на определенный email-адрес.

    Да, есть такой — в частности, WP-DBManager. Он пакует базу данных и отправляет ее на почту, например, раз в день. Но он подходит не под каждый хостинг — на некоторых закрыты нужные функции PHP, на некоторых — нет доступа к mysqldump. Кроме того, он пакует только базу, а файлы надо бекапировать руками.

    С другой стороны, вес моего архива в tar.gz составляет порядка 50-60 Mb (и, понятное дело, растет) — такой объем во-первых не каждая почта примет, а во-вторых, оперировать таким весом в почте — не слишком удобно.

    ОтветитьОтветить
  6. @SibNext: спасибо за комментарий.

    Ну ты же известный ретроград :) Кстати, этот плагин тоже можно запускать по крону, я пока только не разобрался — как именно. В процессе.

    Это ж какого размера у тебя получаются архивы, чтобы они по почте пролазили?

    ОтветитьОтветить
  7. @Yaroslav.CH:

    Махонькие. Я же говорю, инкрементный бэкап рулит ;)

    А вообще есть куча готовых решений даже с веб-мордой (что считаю неприемлемым т.к. а) не консоль б) жрет ресурсы апача).

    Погугли на предмет готовых решений основанных на rsync.

    ОтветитьОтветить
  8. @SibNext: не, о готовых решениях я знаю, но таких, чтобы работали с тем же Дропбоксом — не видел. Впрочем, не могу сказать, что очень внимательно искал :)

    Погуглю для общего развития — спасибо! :)

    ОтветитьОтветить
  9. Кстати, в основном, готовые решения работают с Amazon S3.

    Ну а я как ты подметил использую дедовские методы, и домашний нетбук, который к тому-же является локальным веб-сервером просто забирает по SCP все нужное по крону.

    ОтветитьОтветить
  10. @SibNext: я этот сервис, честно говоря, первый раз увидел только в связке с этим плагином. Оно вообще стоит того, чтобы с ним разбираться?

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

    Итого я имею 3 точки хранения бекапа — что все же больше, чем только ноут :)

    ОтветитьОтветить
  11. Если честно, то не связывался. Ну противится душа доверять стороннему дяде, пусть даже за абонплату хранение данных.

    Я уж лучше буку с домашним стационарным компом синхронизирую. Или (давно собираюсь прикупить) NAS буду использовать. На работе использую, другим «на попробовать» даю... ну вот потихоньку созреваю, чтобы домой купить.

    ОтветитьОтветить
  12. @SibNext: ну хостеру ты же доверяешь данных хранить, и провайдеру — передавать ;)

    Ну у меня вот такой «почти-NAS» стоит — «WD My Book World Edition». Умеет практически все из жизненно необходимого, вплоть до самостоятельной функции закачки файлов с любого ресурса (http, torrent) на самого себя, без участия компьютеров.

    ОтветитьОтветить
  13. Что мне всегда нравится в авторе этого блога, так это отношение к проблемам. Ведь большинство людей в такой ситуации дальше криков — «хотстеры Гондурасы!» не идут. Yaroslav же повозмущавшись вволю в твитере мало того что решил вопрос, так и нашел алгоритм решения при котором он со своими проектами будет застрахован от подобных недоразумений на будущее :) И поделился на страницах своего блога. Это дорогого стоит. Респект как говорится и уважуха!

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

    За идею связки с дропбоксом отдельное спасибо!

    ОтветитьОтветить
  14. @zmei: большое спасибо за столь высокую оценку — всегда искренне приятно читать такие отзывы :)

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

    ОтветитьОтветить
  15. И не только разнесение проектов по разным хостингам, но и доменов по разным регистраторам. Наблюдаю сейчас прекращение работы десятка ресурсов одного за другим. Где саппорт «regru.aaao.ru»? Больше с такой левизной не свяжусь, но и на одного регистратора все не положу.

    Для бекапа нужна автоматика. Если нет, то не очень то удобно.

    А что, у хостера нет функции бекапа сайта в админ панели?

    ОтветитьОтветить
  16. @hawot: в принципе — да, к сожалению, 100% гарантированного регистратора не существует. У меня часть проектов у одного регистратора — часть у другого. Раскидывать на еще большее число не очень хочется — я их в свое время поштучно собирал в одну кучу :)

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

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

    ОтветитьОтветить
  17. Это даже в избранное не грех запихнуть)) Очень хорошо всё расписано, спасибо.

    ОтветитьОтветить
  18. Вот молодец ты :)

    Я перебрала несколько бекапщиков и не остановилась ни на одном. Потому что критически мало понимаю в технических деталях — не могла уразуметь, что они делают, что они не делают, что за ними надо подбирать, что нужно бекапить, а что нет.

    И твой подробный мануал — именно то что нужно, ибо есть ответы на все вопросы :)

    Уточню только один момент →

    Единственное чего не хватает, но, думаю, автор плагина через некоторое время добавит — это копии файла wp-config.php

    То есть файл wp-config.php мне нужно будет бекапить самостоятельно каждый раз?

    ОтветитьОтветить
  19. @Allpa: спасибо за приятный отзыв — поднимает настроение :)

    То есть файл wp-config.php мне нужно будет бекапить самостоятельно каждый раз?

    В принципе — нет, каждый раз не нужно, он так часто не меняется. wp-config.php — это основной файл конфигурации WordPress, в нем хранятся логин и пароли к базе данных и общие настройки блога.

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

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

    А в остальных случаях — сделай один раз копию (чисто на всякий случай) и обновляй ее только если что-то делала с файлом.

    ОтветитьОтветить
  20. Проблема, где взять рефов для Dropbox, чтобы увеличить пространство хранилища?

    ОтветитьОтветить
  21. Я вот как-то по старинке бэкапы делаю. А вот с падением серверов смириться просто не могу. Как-то сервер почти на сутки упал и я каждые 10-15 минут пытался на сайт попасть — вдруг заработало ))

    ОтветитьОтветить
  22. @Allpa:

    В 99% случаев Ты это файл не меняешь никогда.

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

    Все равно на новом хостинге придется новую БД создавать и еще не факт что она будет с таким именем.

    Ну это уже детали работы разных панелей управления хостингом.

    ОтветитьОтветить
  23. Вордпресс еще раз доказал свою универсальность.

    Жаль средство лишь для него, хотя можно что-то придумать и для других.

    Главное чтобы канал интернета был большим. Выкачивать ежедневные бекапы в несколько гигабайт как-то не особо.

    хотя самописные скрипты и рутовый доступ к серверу — рулят.

    ОтветитьОтветить
  24. мда... жаль, что я не видел этой статьи перед тем, как QQHost загнулся.

    ОтветитьОтветить
  25. 6 дней лежать — это жжесть! Я сам думаю переезжать после недавнего 2х часового простоя. Заметил тенденцию что многие популярные блоггеры попереходили на fastvps. Демаю последовать за ними...

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

    ОтветитьОтветить
  27. неплохой плагин надо проверит на моём блоге у меня такие же проблемы с хостингом

    ОтветитьОтветить
  28. Давно искала нечто подобное, так как уже около месяца собираюсь сделать ручную копию сайта, но руки (как обычно) занимаются чем-то другим. А тут такое замечательное решение! Спасибо за информацию и желаю, чтобы ваш новый хостер (независимо от наличия бекапов) не расстраивал вас больше своей нестабильной работой.

    ОтветитьОтветить
  29. @lightg: спасибо! :) тоже очень надеюсь, что на новом месте мне будет спокойнее, чем на предыдущем — к тому же, тут несколько вольготнее и по PHP памяти и по месту на сервере. Но, во избежание повторения давешних «развлечений», я пока оплатил только месяц хостинга — посмотрим как будет себя вести, продлить-то всегда можно :)

    ОтветитьОтветить
  30. Не так уж и сложно ручное бекапирование. Просто сохраняете всё содержиое папки public_html, и делаете экспорт каждой используемой базы данных. Перенос на другой хостинг такой же простой. Проблемма действительно лишь в том, что тяжело не забыть зделать это вовремя.

    ОтветитьОтветить
  31. Спасибо! Cейчас юзаю WP-DBmanager, в благодарность зарегился по рефке Dropbox, будем пробовать WP Time Machine...

    ОтветитьОтветить
  32. Вот это инструктаж! Однозначно в закладки :) Сижу на джино, хостинг трастовый, но бывает тоже в глубоком дауне...подумываю перебираться на другой, вовремя ваш блог нашёл, спасибо за статью, доступно написана. Пользуюсь плагином WordPress Database Backup — бекапит только базу данных. Теперь перейду на WP Time Machine...

    ОтветитьОтветить
  33. @Всеволод: спасибо регистрацию :)

    @Всеволод, @Михалыч: я бы рекомендовал продолжать использовать плагины для архивации БД параллельно с WP Time Machine. Я создаю ежедневный архив БД и полный архив сайта после написания новой записи. Дело в том, что комментарии хранятся именно в БД и те отзывы, которые добавились после публикации нового материала, в случае проблем с сайтом, могут быть утеряны.

    Альтернативно — настроить WP Time Machine на работу по крону.

    ОтветитьОтветить
  34. Кстати при регистрации по рефссылке на dropbox и мне дали дополнительные 250Mb — так что это оказалось взаимовыгодно — можно отразить эту дополнительную информацию в статье, 250 Mb -то не лишние ))

    ОтветитьОтветить
  35. Спасибо за сведения! Я делал бэкап только баз данных, теперь ещё и wp-content буду. Жаль на почту плагин не отправляет архивы-бэкапы.

    ОтветитьОтветить
  36. Я вот еще все по старинке вручную делаю бекапы и считаю что это надежнее чем пользоваться всякими сервисами

    ОтветитьОтветить
  37. Интересно, я делаю бэкап через админку на хостере и потом скачиваю с их же сервера...хм

    ОтветитьОтветить
  38. @ xs_steel: это не самое лучшее решение. Если сервер упадет — бекапы точно так же будут недоступны. Тогда какой смысл в подобном бекапировании? :)

    ОтветитьОтветить
  39. Установила плагин, все по инструкции. Нажимаю «создать архив» он думает, потом пишет, что все создано, но в dropbox ничего не появляется. Не могу понять что не так. Может подскажите?

    ОтветитьОтветить
  40. @ Ольга: проверьте правильность ввода пароля к Dropbox, наличие папок в сервисе и правильность адреса в поле «Directory». Должно быть, например: «папка-для бекапов/название-сайта/название-сайта»

    ОтветитьОтветить
  41. Да не, на некоторых хостингах не работает плагин (возможно есть лимиты на использование оперативной памяти для исполнения php скриптов или еще что) На jino.ru мне не удалось заставить его отсылать архивы, хотя по логам всё ок. Пробовал несколько предыдущих версий плагина. С другой стороны на komtet.ru к примеру (64mb на исполнения скриптов) всё работает как по маслу, никаких проблем с теми же настройками. Также много жалоб на то что не отсылает архивы на официальном форуме плагина. Хотя плагин архивы делает и складывает в папку /wp-content/ — это видно в ftp клиенте если обновлять содержимое папки в момент работы плагина.

    ОтветитьОтветить
  42. @ Всеволод: спасибо за комментарий.

    У меня плагин работает на хостинге с 48 мегабайтами памяти, возможно проблемы есть там, где ограничение стоит в 32. На хостинге для этого блога — 192 мбайта, так что тут не проверишь.

    Те проблемы, которые возникли у Ольги, были и у меня в первый раз — именно из-за невнимательности. Так что, не факт, что проблема именно в памяти :)

    ОтветитьОтветить
  43. Электронка, пароль, папка все написано правильно. Папка соответствующая в dropbox есть, путь у меня Бэкапы/КМ/КМ. А плагин хороший, жалко, что не работает.

    ОтветитьОтветить
  44. @ Ольга: а памяти (php_memory_limit) на хостинге сколько? Возможно, Всеволод прав и проблема именно в этом.

    ОтветитьОтветить
  45. Посмотрела сейчас в php.ini стоит 20М. До скольки память увеличить нужно?

    ОтветитьОтветить
  46. @ Ольга: поскольку неизвестно сколько памяти используется в данный момент, попробуйте до 48 мбайт, думаю, этого должно хватить.

    ОтветитьОтветить
  47. Ольга, если вы решили проблему, поделитесь. У меня тоже самое что и у вас. Все написано верно, но бекап не передается =((((

    ОтветитьОтветить
  48. Александр, увеличение памяти не помогло, пришлось другой плагин использовать для бэкапов.

    ОтветитьОтветить
  49. @ Ольга: честно говоря, даже не знаю в чем может быть причина — у меня этот плагин установлен на 9 блогах, причем на разных хостингах, причем с разными плагинами — и все ок. Единственный плагин, с которым я точно знаю, что он не дружит — это WPML, но сам плагин работает, проблема возникает при создании записей.

    ОтветитьОтветить
  50. У самого недавно сервак накрылся. Оказалось сгорела материнская плата, но техподдрежка достаточно быстро среагировала и за пару часов собрала что-то на коленке. Не скажу что все быстро работало, но все же работало. Потом попросил перевести меня на новый сервер, чтобы не торчать на рухляти и не ждать новую мамку. Хорошо что служба поддержки работает там круглосуточно, ато было бы дней 6 как у автора:)

    ОтветитьОтветить
  51. У меня плагин тоже не завелся. Вроде пароль и логин раз 5 перепроверил, но все равно «They should now be available via your offsite provider: Dropbox».

    ОтветитьОтветить
  52. @ Maksim Shaihalov: возможно, стоит перепроверить настройки. Судя по ошибке, пароль именно Dropbox не принимает, а не с плагином проблемы.

    ОтветитьОтветить
  53. @ Yaroslav.CH:

    С плагином то как раз таки вроде бы проблем нет. На фтп бэкап создается. Я на офф форуме почитал. У некоторых хостеров проблемы бывают.

    ОтветитьОтветить
  54. Спасибо огромное за статью! пользовался WP database backup. но он мне не нравился абсолютно. Этот плагин очень понравился. Тем более работает с дропбокс!

    ОтветитьОтветить
  55. Я, когда перелазил на ВДС, просто указал в записях ДНС наряду с записями бывшего хостера и ДНС ВДСника. Переход произошёл вообще безболезненно. Правда при этом хостинг не валялся =) Ну а на дедике простор для действий больше — это и шелл-скрипты, и крон, и ещё много чего интересного.

    ОтветитьОтветить
  56. WordPress Backup to Dropbox, этот плагин тоже сохраняет бекап блога на Drobox, но в отличие от WP Time Machine он архивирует все файлы блога без исключения и отправляет их на Drobox. И что я заметил, архив с файлами блога заархивированный этим плагином получился на порядок меньше размером, чем архив с одной папкой wp-content, заархивированный плагином WP Time Machine.

    Зарегился на Drobox по реферальной ссылке, большой рахмат :)

    ОтветитьОтветить
  57. @Михалыч: спасибо за комментарий.

    но в отличие от WP Time Machine он архивирует все файлы блога без исключения и отправляет их на Drobox.

    Да, так и есть — но именно это не всегда и хорошо. У меня помимо блога иногда на сервере хранятся и другие файлы, которые бекапировать нет смысла.

    Плюс, на некоторых хостингах WordPress Backup to Dropbox у меня не заработал, вываливаясь с ошибкой на недостаток времени для упаковки. А вот WP Time Machine работает безотказно. Поэтому, использую оба плагина — в зависимости от необходимости.

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

    Ну, «порядка» там, конечно, нет — это слишком уж круто :) Но Вы правы, разница мегабайт в 5-7 присутствует.

    Зарегился на Drobox по реферальной ссылке

    Спасибо :) Все-таки мне нравится правильная реферальная программа Dropbox — и я получаю дополнительное место, и Вы :)

    ОтветитьОтветить
  58. Я сейчас провожу эксперимент: создала поддомен и пытаюсь на него восстановить блог.

    Слушай, а вот это →

    Закачать полученное содержимое папки «wp-content» — на новый сервер с помощью FTP или менеджера файлов, с заменой существующих файлов

    обязатель закачивать уже распакованную папку? Нельзя сжать в архив и залить с помощью сПанели, а потом разархивировать на месте?

    Понимаешь, архив заливается на порядок быстрее, чем распакованная папка...

    Я уже замаялась ждать :)

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

    В то же время незаархивированный и так залитый через ФТП — поставился без писку...

    И ещё вопрос: а вот если (мой случай) стоит англоязычный Вордпрес + мой блог (тот, который я сейчас пробую восстановить на поддомене): мона накатать потом русскоязычный ВП? Если да, то как? Ну, шоб не послетало фсё...

    ОтветитьОтветить
  59. @Allpa:

    обязатель закачивать уже распакованную папку? Нельзя сжать в архив и залить с помощью сПанели, а потом разархивировать на месте?

    Нет, не обязательно — можешь залить и архивом. Главное потом проверить, чтобы все права на папки были правильными.

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

    Честно говоря, я не совсем понимаю — что ты имеешь ввиду. В каком смысле «демо шаблона не хочет ставить WordPress»? Шаблон — это просто набор файлов, лежащих в определенной папке и размещаемых в themes. Как они могут что-то ставить или не ставить? Сначала движок, а к нему — шаблоны. Или у тебя какая-то сборка?

    мона накатать потом русскоязычный ВП? Если да, то как? Ну, шоб не послетало фсё...

    AFAIR, за языковую часть WordPress отвечает строка define ('WPLANG', 'ru_RU'); в wp-config.php, а также файлы перевода, лежащие в wp-content/languages. Как укажешь и зальешь, так и должен работать. Но иногда возникают некоторые проблемы с изменением языка.

    ОтветитьОтветить
  60. @Yaroslav.CH:

    Честно говоря, я не совсем понимаю — что ты имеешь ввиду

    Абисняю :)

    Я сейчас мучаюсь с новым шаблоном. Они выпускают 2 варианта: а). Просто шаблон, как обычно; б).

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

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

    Я поставила демо-шаблон на поддомен: всё работает прекрасно.

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

    Пока я застряла на этапе залогинивания.

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

    И да, я тупая :) Где-то наверняка допустила ошибку. Сейчас попробую всё по-новой проделать.

    Да! Этот wpTimeMachine-htaccess.txt будучи переименованным исчезает и я его не вижу — это нормуль?

    Короче, всё получилось: восстановилось на поддомене во всей своей красе. А залогиниться я не могла, потому что напрочь забыла, что надо править урл блога в PHP MyAdmin → wp-option → site url :)

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

    ОтветитьОтветить
  62. @rafterss: если мне не изменяет мой склероз, то ни бекапируют только базу. Это удобно только в том случае, если не заливать картинки, не менять файлі шаблона и т.д.

    ОтветитьОтветить
  63. Вы правы это так. Но если картинки были залиты на хостинги картинок то все будет отлично работать и на другом хостинге. Да и размеры сайта это уменьшит.

    ОтветитьОтветить
  64. @rafterss: для меня размер сайта не играет никакой роли, но сохранность изображений — намного важнее :)

    ОтветитьОтветить
  65. @Yaroslav.CH:

    Но ведь вряд ли кто-то будет спорить что на хостингах картинок изображения будут менее сохранны)))

    ОтветитьОтветить
  66. @rafterss: а я как раз поспорю — во-первых, на хостингах картинок, изображения со временем «протухают» и удаляются. Во-вторых, периодически у них бывают сбои и картинки не подгружаются. В третьих, у более-менее качественных хостингов место — ограничено.

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

    ОтветитьОтветить
  67. Спасибо, весьма своевременно. Меня тоже мой хостер замучил, то час нет доступа к сайту, то день, а последний раз три дня не было! Я все ногти сгрызла! Стала искать плагин для Бэкапа, а большинство только базу данных копируют, а тут — сказочка. Хоть с Дропбоксом, наконец, разберусь, а то всё откладываю.

    Посоветуйте хорошего хостера, и ещё, где лучше размещать блог — на российских серверах или европейских?

    ОтветитьОтветить
  68. Недавно как раз менял хостинг :)

    Мне кажется, что основная фича этого плагина имено в дропбоксе: т.е. автоматом не только в облако попадает бэкап, но и на локальный комп\компы его сам дропбокс качает. Для критически важных данных лишний бэкап не лишний :)

    Вопрос на счет автобэкапа после написания поста (а там есть такая фича): ты не в курсе отправляет он бэкап после публикации поста или каждую ревизию и черновики тоже шлет?

    ОтветитьОтветить
  69. да не очень хорошая ситуация, часто после таких падений зачастую теряются все посетители ( Но я вот своему хостеру доверяю, но сбои не редкость:)

    ОтветитьОтветить
  70. Хм, я думал на всех хостингах в ПУ есть кнопочка «Создать бекап», а тут какие-то сторонние скрипты рассматриваются... Как по мне большей проблемой является выбор абузоустойчиого хостинга, сам уже штук 5 сменил. А бекап лучше делать и качать раз в месяц на свой компьютер.

    ОтветитьОтветить
  71. @biosport: ручное создание бекапа — это путь к проблемам. Бекап оптимальнее всего создавать автоматически и ежедневно.

    А что касается абузоустойчивых хостингов — не подскажу, т.к. мне они без надобности.

    ОтветитьОтветить
  72. @Yaroslav.CH:

    Конечно лучше автоматически и ежедневно, но где столько места на хостинге напастись? :) Мои сайты где-то гектар весят, если каждый день будет по гектару бекапиться, то уже через неделю лимит превыситься. А покупать лишнее место лишь ради бекапов не целесообразно.

    З.Ы.: и обманывать с nofollow нехорошо.

    ОтветитьОтветить
  73. @biosport: именно поэтому нужно:

    1. бекапить в облако;

    2. бекапить картинки и тяжелые файлы отдельно.

    З.Ы. В каком смысле?

    ОтветитьОтветить
  74. Классная статья , тут была такая необходимость , по своей глупости случайно удалил в корне файл tmp-mod и файлы перестали загружаться и сохраняться через в вордпресс . Почти 4 дня ушло на переписку с хостером , в итоге когда я вспомнил что удалял какой то файл , даже погуглив примерно понял какой файл отстутсвует , хостер восстановил и все заработало . Но ощущение не из приятных когда не можешь загрузить файлы. Вот тут то меня и начали посещать мрачные мысли , точнее самый пессимистичный прогноз по поводу смены хостинга в случае , если все будет по прежнему! Благо все хорошо закончилось ! Но статью эту сохраню , мало ли...

    ОтветитьОтветить
  75. Столкнулся с данной проблемой (хостинг nic.ua) вторую неделю лежит — сервера забрала СБУ (резервные копии делал хостер, но сервера с резервными копиями тоже забрали!) Подробнее можно почитать в новостях кому интересно но суть не в этом!

    Свои бекапи не делал уже примерно пол года — в надежде что хостер и так делает бекапи которые в отдельном ДатаЦентре — что с ними случиться, но когда чего-то меньше всего ожидаешь оно обязательно случается!

    Решил задаться вопросом, а как же все таки создавать бекапи автоматически (хотя я сам не использую wordpress) — статье уже 5 лет! Последнему комету тоже 2 года! Вот интересно поменялось ли что-то за это время? Может появились какие-то новые решения — не кто не сталкивался — может подскажите?

    ОтветитьОтветить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *