Как восстановить сайт WordPress из резервной копии базы данных. Wordpress резервная копия
Как восстановить сайт на wordpress из резервной копии
Всем привет. В прошлой статье писал как сделать резервную копию сайта, сегодня продолжение темы — как восстановить сайт на wordpress. Думаю, вы уже поняли о необходимости периодически делать резервные копии сайта. В жизни всякое случается: на хостинг надейся , а сам не плошай.
Считаем, что ваш сайт «упал», но имеется резервная копия. Копий должно быть две: копия файлов сайта и копия базы данных. Это и будет точка отсчёта. При отсутствии копии файлов нельзя восстановить тему, плагины, настройки. На это потребуется дополнительное время: установить тему, плагины и выполнять настройку заново.
Как восстановить сайт на wordpress
Порядок восстановления сайта из бэкапа роли не играет. Восстановим сначала файлы сайта.
Вам пригодится: «Как вручную обновить WordPress»
Восстановление файлов сайта из резервной копии
Удаляете в ней все существующие файлы. Жмёте кнопку Закачать.
Выбираете на компьютере скачанный ранее архив с бэкапом файлов. Закачиваете. Архив разархивируете и удаляете. Он больше не нужен.
Таким простым способом восстановили файлы вордпресс, тему, плагины. Далее нужно восстановить базу данных.
Восстановление базы данных MySQL из бэкапа
В консоли хостинга входите в раздел PhpMyAdmin. Нужно ввести данные для входа (логин, пароль), указанные при создании базы данных. Если не помните, то их легко найти. В корневом каталоге сайта ищите файл wp-config.php. В нём указанны название базы, пользователь и пароль.
В PhpMyAdmin вошли.
Кликаете на базу данных которая нужна.
После открытия выбираете все таблицы и удаляете.
Вам пригодится: «Удалить базу данных MySql»
Теперь закачаем имеющеюся резервную копию базы данных. Нажимаете Импорт.
На компьютере выбираете архив с бэкапом. Ок.
Через несколько секунд база данных загрузится, получите уведомление об успешной операции.
Как видите восстановить сайт на wordpress из резервной копии совсем несложно.
В случае если хотите перенести сайт на другой домен нужно сделать некоторые правки в файле резервной копии .sql, так как в нём стоят ссылки на старый домен. Откройте файл блокнотом Notepad++. Нажимаете сочетание клавиш Cntr+F. Вписываете в графы старый домен заменить на новый.
Сохраняете, архивируете в архив .zip.
На новом домене в панели PhpMyAdmin создаёте новую базу данных. При создании базы обратите на кодировку. Должна быть такая же как и на хостинге где создавалась резервная копия. В инете много информации и все пишут про кодировку utf8_general_ci. Но у меня база с кодировкой utf8mb4_general_ci и вылетали кракозябры, пока не разобрался.
В файле wp-config.php указываете параметры для подключения базы.
Итак, вы получили подробную инструкцию, как восстановить сайт на wordpress. Лучше же, конечно, чтобы она не пригодилась, но знать как восстановить сайт из бэкапа надо.
Отпишитесь в комментариях, полезна ли статья?
Удачи Вам и Вашим проектам!
С уважением, Павел Коновалов
konovalovpavel.ru
Как восстановить сайт WordPress из резервной копии базы данных
Здравствуйте, друзья! В прошлом уроке мы говорили с Вами о создании резервной копии сайта. В этом мы поговорим о том, как с помощью резервной копии восстановить сайт WordPress.
Давайте смоделируем ситуацию, в которой злостные злоумышленники заполучили доступ к Вашему сайту. Теперь давайте представим, что они удалили все записи и страницы на сайте, сбросили все настройки темы и виджетов, и в добавок изменили пароль доступа на сайт.
Что мы можем сделать в таком случае? Только одно — восстановить сайт из резервной копии базы данных. В нашей ситуации мы будем считать, что резервная копия у нас есть, и с ее помощью бы будем восстанавливать сайт.
И так, приступим!
Восстановление сайта WordPress из резервной копии
1. Перед тем как загрузить резервную копию, нужно удалить все то, что осталось в базе данных после злоумышленников. Для этого выбираем на хостинге базу данных с которой работает Ваш сайт и заходим в phpMyAdmin.
2. Нажимаем левой кнопкой мышки по названию (не по плюсику) базы данных.
3. Ставим галочку в «Отметить все» и в выпадающем списке рядом выбираем «Удалить».
4. Нажимаем «Да», подтверждая тем самым удаление базы данных.
5. Теперь переходим к финальному этапу — импорту резервной копии базы данных.
Для этого переходим на вкладку «Импорт» и нажимаем кнопку «Выберите файл». После нажатия на кнопку Вам нужно будет указать путь на компьютере к резервной копии базы данных, и нажать «Открыть».
После этого в самом низу нажимаем кнопку «ОК».
Если восстановление прошло успешно, вы увидите сообщение после которого можно с легкостью вздохнуть и считать восстановление сайта завершенным:
Ничего сложного в восстановлении сайта нету, но это не значит что его не нужно беречь и надеяться на резервные копии.
Я надеюсь что Ваши сайты будут всегда работать бесперебойно, и Вам никогда не придется восстанавливать утерянные данные 😉
Если же Вы один из тех счастливчиков, которые еще не нуждались в восстановлении сайта — не расстраивайтесь! Знания из этого урока лишними не будут, их как минимум можно использовать при переносе сайта на хостинг или на локальный сервер. Но это уже другая история…
И как всегда напоминаю, если у вас возникли сложности или какие-то вопросы — смело пишите в комментариях.
Здравствуйте, друзья! В прошлом уроке мы говорили с Вами о создании резервной копии сайта. В этом мы поговорим о том, как с помощью резервной копии восстановить сайт WordPress. Давайте смоделируем ситуацию, в которой злостные злоумышленники заполучили доступ к Вашему сайту. Теперь давайте представим, что они удалили все записи и страницы на сайте, сбросили все настройки темы и виджетов, и в добавок изменили пароль доступа на сайт. Что мы можем сделать в таком случае? Только одно - восстановить сайт из резервной копии базы данных. В нашей ситуации мы будем считать, что резервная копия у нас есть, и с ее помощью бы будем восстанавливать сайт. И…
Проголосуйте за урок
Рейтинг: 4.22 ( 6 голосов ) 100wp-lessons.com
Как создаётся резервная копия в WordPress
Необходимо постоянно делать резервную копию сайта. Бэкап является страховкой от потери ресурса. Он пригодится, если сайт взломали или он заразился вирусом, если вы что-то испортили в настройках и не можете сами восстановить, а также в других случаях, когда требуется откатить сайт на более раннюю дату.
Резервная копия WordPress делается с помощью плагинов, и один них мы рассмотрим в этой статье.
Как правильно настроить плагин
Для WordPress разработаны платные и бесплатные плагины, позволяющие делать резервное копирование. Плагин UpdraftPlus производит копирование ресурса вручную, если надо сделать бэкап один раз, а также автоматически по заданному расписанию. Бэкап можно скачать на компьютер или хранить на облачном сервисе.
После установки и активирования плагина можно приступать к работе. Интерфейс плагина содержит три основных функции.
- Создать РК сейчас. Если необходимо создать копию сайта немедленно. Функция подойдёт для создания бэкапа один раз.
- Восстановить. Можно восстановить сайт из резервной копии, созданной ранее.
- Скопировать/Перенести. Функция предназначена для создания бэкапа и переноса на заданное хранилище.
Спускаясь ниже по меню, производятся настройки расписания копирования. Бекап файлов достаточно делать один раз в неделю. Базу данных лучше сохранять каждый день. Когда создаётся резервная копия WordPress, старый бекап удаляется, на его место записывается новый. Рекомендуется хранить несколько копий: одна новая, другая предыдущей редакции.
У плагина UpdraftPlus есть хорошая функция «Отчёт». При установке галочки, владелец ресурса будет получать отчёт по электронной почте о созданной копии или об ошибках.
Для того, чтобы подключить удалённое хранилище резервной копии в облако, требуется указать имя для удалённого хранилища бэкапа. Необходимо пройти регистрацию на выбранном удалённом хранилище, если у вас ещё нет там аккаунта.
После всех установленных настроек стоит проверить создание копии ресурса. Для этого необходимо нажать на «Создать РК сейчас». После нажатия кнопки запускается процесс бекапа. Затем необходимо проверить удалённое хранилище. Если резервная копия сайта записана туда, куда и планировалась, настройки произведены правильно.
Недостатком плагина UpdraftPlus является запутанный и сложный интерфейс пользователя. Но если по изучать его, то можно будет разобраться.
Узнайте о том, как правильно сделать резервную копию. Об этом рассказывалось здесь.
Если вы нашли ошибку, то выделите её и нажмите клавиши Shift + Enter или нажмите сюда, чтобы проинформировать нас.
Также по этой теме:
wpuroki.ru
Авто-бэкап сайта WordPress бесплатным плагином BackWPup
Статьи про резервное копирование принято начинать страшными рассказами о том, почему надо делать резервные копии (бэкапы). Поскольку Вы сюда зашли, то наверное, такие рассказы уже ни к чему. Ценность иметь возможность в считанные минуты восстановить сайт у Вас уже сформирована. Если планируете создавать разовые резервные копии, переходите сразу к подзаголовку Бэкап WordPress на cPanel. Если Вам необходимо регулярное, автоматическое создание бэкапов, то читайте Бэкап WordPress плагином.
Зачем нужна резервная копия сайта WordPress
Сайт, как и любой другой программный продукт, это сложный механизм который с одной стороны хорошо работает когда он грамотно настроен, а с другой стороны регулярно нуждается в этих самых профилактических настройках. Это и обновления самого движка WordPress, темы, плагинов, и работа с контекстом и функционалом. Каждое вмешательство в этот механизм может привести к его поломке. Кроме того , есть масса внешних факторов, которые несут потенциальную угрозу сайту. Вирусы, вредоносное ПО, хакерские атаки, ненадежный хостинг и так далее, и Ваши неосторожные действия в том числе.
Резервное копирование, или иначе бэкап, как раз то самое единственное эффективное средство, которое поможет Вам в считанные минуты устранить любую «поломку» сайта. Не мучительно и долго ремонтировать то, что сломалось, а просто достать из архива Ваш сайт в том виде, в каком он был до поломки, и продолжать им радостно пользоваться.
Какие бывают резервные копии WordPress
Разовые и регулярные
Можно разделить резервные копии на разовые (вручную) и по расписанию (автоматически).
Периодичность резервного копирования напрямую зависит от того, как часто Вы делаете публикации или другие изменения на сайте. Под другими изменениями предполагаются такие как настройка темы сайта, изменение,обновление темы сайта, обновление WordPress, установка, обновление, настройка плагинов, изменение различных настроек WordPress. Тут все понятно. Если не хотите, чтобы Ваша работа пропала даром, то перед каждым трудоемким действием создавайте бэкап. «Трудоемким» зачеркнул потому, что обновления тем, плагинов, самого WordPress на самом деле совершенно не трудоемки, а вот последствия ошибки, которую никто не исключает, придется исправлять мучительно долго.
Если время, которое потрачено на создание резервной копии меньше, чем время, которое потребуется на восстановление потерянной работы или устранение ошибок, то бэкап уже себя оправдал.
Резервные копии сайта WordPress
Они состоят из двух основных элементов. В зависимости от специфики работы может потребоваться как один из этих видов резервной копии сайта, так и оба варианта.
Резервная копия базы данных
Содержит все таблицы данных WordPress. В них содержатся такие данные: записи, страницы, метаданные страниц и записей, вложения, редакции, пользовательские записи, комментарии, метаданные комментариев, таксономии (категории, метки), связи между таксономиями, связи между таксономиями и записями, страницами, пользователи, метаданные пользователей (данные о пользователях).
Отсюда видно, что такой архив важно иметь для восстановления контента сайта. Периодичность резервного копирования базы данных стоит настроить таким образом, чтобы она соответствовала периодичности публикуемых записей, статей, комментариев, изменениям в таксономиях и т.д. Если периодичность публикаций ежедневная, то вполне обоснованно делать ночью бэкап БД.
Резервная копия файлов
Содержит все файлы корневого каталога сайта. Это таблицы стилей, шрифты, языки, темы, плагины, все файлы самого WordPress, такие файлы как .htaccess, robots.txt, sitemaps.xml.
Следовательно такой архив важно иметь для восстановления структуры сайта. Периодичность создания бэкапов файлов скорее всего будет не такой интенсивной, как у базы данных. Хотя, если сайт пострадает от каких либо действий, в том числе, не исключая и Ваши случайные неосторожные действия, то восстанавливать будете именно из этого архива.
В любом случае, какую бы периодичность вы не настраивали применительно к сайту неплохо привыкнуть к простому правилу. Собрался что-то менять на сайте, удалять, обновлять, устанавливать — не важно, прежде всего сделать резервную копию.
Как сделать резервную копию сайта WordPress
-
- В панели администратора. Экспорт, встроенная функция. Находится в «Инструментах» административной панели WordPress. Он вообще-то не про резервное копирование, а про перенос материалов с одного сайта WordPress на другой. Но между тем, сохранить с помощью этой функции свои Записи, Страницы, Медиафайлы и прочее вполне удобно. Удобен, когда надо срочно сделать резервную копию опубликованных или отредактированных материалов. Правда, выбирать тип контента и период, за который надо сделать выгрузку придется исключительно вручную. Таким образом, разово делать копии контента Вы вполне сможете. От потери записей, постов и прочих материалов это поможет. Но это копия только контента. Другие файлы сайта сохранить не получится.
- С помощью плагинов для резервного копирования, в том числе бесплатных. Описаний этих плагинов в интернете тоже достаточное количество. Я делюсь практическим опытом, надеюсь, что сохраняю тем самым Ваши силы и время. Оказался очень удобным плагин BackWPup. Им пользуюсь. Настроить очень просто. Бесплатной версии достаточно для того, чтобы делать копии всего сайта по расписанию и хранить их в DropBox.
- В панели управления хостингом. cPanel — наиболее распространенная панель управления хостингом. При выборе хостинга, если У Вас еще не принято решение, советую обратить внимание на наличие этой панели. О ней можно рассказать отдельно. А вот в контексте данной темы скажу, что бэкап делается «в один клик» , собственно, также легко и приятно восстанавливать сайт из резервной копии. В cPanel можно сделать полную копию всего web-сайта, копию базы данных, копию корневого каталога. Не все идеально.
- Копии из cPanel сохраняются локально на Ваш компьютер. Это может быть минусом, если Вам нужен доступ к бэкапам из разных мест и копии надо хранить в облаке.
- Кроме этого, создание резервных копий из cPanel ручное. Нет возможности настроить автосохранение по расписанию.
Места хранения:
Сервер, на котором храниться сам сайт, другой сервер или компьютер, облачное хранилище. Все зависит от задачи, и кое-что от надежности хостера и его сервера. Если все в порядке с хостингом, компания надежная, отношение к клиенту радостное и места на диске с избытком, то почему бы и не хранить бэкапы на сервере.
Облачное хранилище. У меня настроено хранение бэкапов в DropBox. Хостинг, которым пользуюсь отличный, но бесплатного места на диске осталось мало, а доплачивать не хочется. А те 2 GB диска, которые DropBox дает бесплатно, вполне хватает для нескольких бэкапов сайта на WordPress. Все равно, под каждый сайт, как мне кажется, надо создавать отдельную структуру, начиная с аккаунта на Gmail, и далее. Так что, под другой сайт будет и на DropBox другой аккаунт и свои 2 GB диска. Логика тут проста и понятна. У сайта возможна как смена владельца, так и разделение полномочий работников сайта. Могут быть разные хостинги, способы продвижения и т.д. И очень удобно, когда каждая отдельная структура создана и доступна для работы независимо от других.
Бэкап WordPress из cPanel
Основные плюсы:
- Простой интерфейс панели. Бэкап всего web-сайта делается в один клик. В три, если быть более точным, но все равно, очень просто )
- Восстановить сайт из резервной копии также просто , как и создать ее. Серьезный плюс.
- Выборочный состав бэкапа для скачивания. По отдельности можно скачать корневой каталог, базу данных, серверы электронной почты и фильтры.
- Создается полная резервная копия всего web-сайта для перемещения учетной записи на другой сервер, правда в cPanel Вы не можете восстановить полную резервную копию, потому, что она предназначена именно для переноса.
Минусы:
- Полная резервная копия всего web-сайта сохраняется только на тот же сервер, на котором находится сайт и она очень тяжелая. (зато копии БД и корневого каталога по отдельности сохраняются сразу на Ваш локальный компьютер).
При выборе хостинга очень рекомендую обратить внимание на наличие у него панели управления cPanel. Удобнейшая вещь для работы с резервным копированием и не только.
Итак, в cPanel чтобы сделать бэкап надо открыть «Мастер резервного копирования»
Меню панели управления cPanel нажать кнопку «Back Up», в «Выборе частичного копирования» нажать кнопку с видом бэкапа, который Вы хотите сделать, например, «Корневой каталог».
Выбор типа резервной копии WordPress Во всплывающем окне указать путь для скачивания архива. Все. Резервная копия готова, создан архивный файл и скачан в указанное Вами место на компьютере.
Бэкап WordPress плагином
Плагин BackWPup. Основные плюсы:
- Резервное копирование автоматическое, по расписанию (заданию), с возможностью создания нескольких независимых заданий.
- Отдельные расписания создания архивов для различных типов резервных копий.
- Выборочный, довольно детально настраиваемый состав бэкапа.
- Выборочный формат архива резервной копии.
- Выборочные места хранения архивных файлов резервных копий (сервер, отправка почтой, FTP, загрузка в DropBox и другие хранилища)
Минусы:
- Загрузка в GoogleDrive только в платной версии
- Для восстановления сайта, в отличии от панели cPanel, где это делается в один клик, необходимо проделать несколько действий вручную и использовать дополнительные инструменты типа phpMyAdmin.
Как настроить бэкап WordPress плагином
Установите и активируйте плагин BackWPup. В нижней части панели управления WordPress появится строка BackWPup. Кликните по ней и в раскрывшемся списке-меню зайдите на закладку Jobs чтобы создать новое задание. Нажмите «Add new» и попадете в меню настроек задания. Первая закладка General. На ней напротив This job is a… проставьте галочки в чекбоксах напротив тех видов резервных копий, которые надо сделать.
Состав резервной копии На изображении показан вариант, когда в состав резервной копии включены: база данных(Database backup), файлы сайта(File backup) и список установленных плагинов(Installed plugins list). Список плагинов — это именно список, а не сами плагины. Список состоит из названий плагинов и их разработчиков, номера релиза, официального сайта разработчика.
Спускайтесь ниже и в разделе Jobs Destination ответьте на вопрос Where should your backup file be stored? — поставьте галочки в чекбоксах напротив тех мест назначения, куда должны быть отправлены резервные копии.
Тип архива и место хранения бэкапа Backup to Folder это сохранение архивов в папку на сервере, которую создаст плагин. Если Вы будете хранить архивы в Dropbox, то поставьте галочку в соответствующем чекбоксе. При поставленной галочке появляется закладка в меню To: Dropbox на которой надо связать аккаунты дропбокс и вордпресс.
Следующий этап настройки — расписание. Перейдите на закладку Job Schedule в разделе Start job
- Если будете настраивать резервное копирование по графику, то включите радиокнопку надписи with WordPress cron.
- Если будете делать бэкапы вручную, оставьте радиокнопку в положении manually only, она там стоит по умолчанию.
Выбор автоматического создания бэкапа На изображении показан вариант, в котором включено резервное копирование по расписанию. После установки кнопки в это положение открывается интерфейс для создания расписания.
Из основных настроек осталось только добавить сохранение архивов в Dropbox. Перейдите на закладку To: Dropbox. Здесь надо выбрать один из двух вариантов. Полный или ограниченный доступ к облачному хранилищу Вы разрешите плагину. При ограниченном доступе плагин создает папку в хранилище и использует исключительно ее. При полном доступе плагин получает весь объем хранилища Dropbox. В этом случае есть риск, что другие файлы, кроме создаваемых плагином архивных копий, могут быть «затерты» при загрузке бэкапов.
Настройка Dropbox В соответствии с принятым решением нажмите Get Dropbox App ayth code(частичный доступ) или Get full Dropbox ayth code(полный доступ). Вы будете перенаправлены на дропбокс и получите код, который надо будет вставить в соответствующее поле и нажать Enter.
Надпись Authenticated! будет Вам наградой.
Убедитесь, что все работает так, как Вы задумали. Результаты резервного копирования Вы всегда сможете проверить на в таблице Backups.
Чтобы моментально сделать бэкап и убедиться, что он создается без ошибок надо зайти на закладку заданий Jobs и навести курсор мыши на наименование задания. (на изображении ниже: Job with ID 1). Появится список действий с заданием, в том числе и Run now.
Создать резервную копию сайта Wordpresss вручную Надеюсь, что все получилось довольно понятно. Плагин имеет много настроек, изучайте, пользуйтесь.
Если возникнет какой-то вопрос, пишите, разберемся вместе!
Резервная копия WordPress
malinalime.com
Резервная копия сайта на WordPress
18.02.2015 2953 Пишу 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» вполне понятна, не смотря на то, что он не переведён на русский язык.
А тем, кто дочитал до этого места, бонус — кино на эту же тему.
Теги раздела
css (1), wordpress (4), изыски словообразования (4), компьютерная теория (9), компьютерный практикум (5), кулинария (1), мобильная связь (1), мои университеты (2), облако тегов (1), проза (33), рифмы (4), свои функции (1), теле2 (1), фельетон (1), шрифты (1), эссе (1), юмор (8)Оставьте ваш отзыв:
www.vsmirnov.ru
Резервная копия WordPress в DropBox
Резервная копия WordPress – это копия сайта, которая создаётся на случай непредвиденных ситуаций: технической неисправности хостинга, которая вывела сайт из строя, заражения вирусом или изменения настроек, которые никак не удаётся вернуть обратно. Резервное копирование необходимо, и каждый нормальный хостинг создаёт его автоматически с определённой периодичностью.
Резервная копия WordPress или backup – это копия сайта, из которой можно восстановиться в случае аварийной критической ситуации. Резервная копия должна обязательно состоять из двух частей – файлов сайта и базы данных. Обычно резервные копии делают хостинги автоматически, периодически. Их также можно сохранять на своём компьютере.
И тут есть одна ерундовина, которая не даёт покоя параноикам. А что если backup-сервер хостинга сломается, и все мои копии удалятся? А что если вездесущий Роспотребнадзор напишет на меня жалобу и мой аккаунт на хостинге полностью удалят, в том числе и резервные копии? А что если резервные копии, которые я сохранил на своём компьютере, куда-то исчезнут (нечаянно удалятся, испортятся вирусом, сломается жёсткий диск).
Причин для волнения в этой части у вебмастеров, как видите, множество. И от всех них можно избавиться с помощью одного простого способа – хранить резервную копию WordPress на облачном хранилище. Никто не говорит, что нужно отказываться от услуг по копированию от хостинга или перестать сохранять копии сайта локально на компьютере. Облачные хранилища следует использовать параллельно со всеми способами хранения резервного копирования.
И чтобы создание backup не занимало очень много сил, я вам сейчас расскажу о плагине, который будет делать автоматически резервную копию WordPress в облачное хранилище DropBox. Этот плагин можно отнести к разряду «настроил и забыл». Вы вспомните о нём только тогда, когда вам срочно понадобится восстановить сайт, и вздохнёте с облегчением, осознав, что у вас есть свеженькая копия.
Резервная копия WordPress плагином WordPress Backup to Dropbox
Резервная копия WordPress с помощью плагина WordPress Backup to Dropbox осуществляется, как понятно из названия, на облачное хранилище DropBox. То есть, backup не будет зависеть ни от вашего хостинга, ни от вашего компьютера.
DropBox – это независимое облачное хранилище. 2 Гб пространства даётся бесплатно каждому зарегистрированному пользователю. Этого места вполне хватит для средненького сайта. DropBox безопасен, не стоит опасаться внезапного закрытия проекта или взлома со стороны мошенников. Для того чтобы сделать резервную копию WordPress в DropBox, вам необходимо завести там аккаунт, сделать это можно здесь. Итак, скачайте, установите и активируйте плагин WordPress Backup to Dropbox. После этого в вашей консоли администратора появится новый пункт «WPB2D». Там вам нужно сначала подключить плагин к вашему аккаунту DropBox, и позволить ему сохранять файлы. После того, как дадите на это разрешение, нажмите кнопку «Продолжить».
Начнём с подпункта «Настройки», здесь можно управлять резервной копией WordPress:
- Состояние аккаунта DropBox. Здесь вы можете видеть, к какому аккаунту подключен плагин, и сколько места там ещё осталось. А также можно отключить и переподключить аккаунты.
- Следующая задача. Если вы задали периодичность, то здесь отображается, когда будет произведена следующая резервная копия WordPress. О периодичности ниже.
- История. Каждый раз, когда плагин делает backup сайта, он записывает дату и время этого события.
- Сохранить резервную копию на Dropbox в папку. Если хотите, чтобы плагин сохранял резервную копию WordPress в какую-то папку, то здесь нужно задать название этой папки. Я, например, пишу название сайта, чтобы потом не перепутать, какой backup от какого проекта.
- Дата и время. В выпадающем списке выбираем день и час, когда необходимо выполнять резервную копию сайта.
- Периодичность. Самая частая периодичность – ежедневно, самая редкая – 1 раз в 12 месяцев. Периодичность подбирайте, исходя из скорости обновления вашего сайта – чем чаще пишите новые статьи, чем чаще надо делать резервную копию WordPress. Например, я поставил еженедельно, а пишу 2-3 в неделю.
- Исключение файлов и каталогов. Если хотите сэкономить место на DropBox, то тут можно исключить какие-то папки или файлы, и они не будут участвовать в резервном копировании. На ненужные следует поставить галочки. Но я бы не рекомендовал так делать.
Окно настроек плагина
Не забудьте нажать на кнопку «Сохранить изменения», когда всё настроите.
Второй подпункт «Backup monitor» Здесь можно более детально видеть, как происходит резервное копирование сайта, и ознакомиться с подробным логом. Кроме того, если вам необходимо запустить создание backup сиюминутно, не дожидаясь установленной периодичности, то можно для этого тут нажать на кнопку «Начать резервное копирование».
Окно лога копирования плагина
В подпункте «Расширенные возможности» можно приобрести премиум функции. Разные пакеты стоят от 4 до 300 $. Но даже базовых бесплатных функций вполне хватает для полноценной работы.
Когда создастся хоть одна резервная копия WordPress, можно посмотреть в аккаунте DropBox, как она выглядит. Там в заданной папке вы увидите все файлы вашего сайта, и следует заметить, что база данных от сайта будет храниться в каталоге «wp-content/backups». Там же можно взять лог процесса копирования.
wp-system.ru
Создание резервной копии WordPress | Установка блога на WordPress
Опубликовано: 29/04/2011 | Автор: Владислав | Filed under: WordPress |
Здравствуйте, друзья!
Сегодня, как и обещал, расскажу вам как я делаю резервные копии блога на WordPress. Вы наверное уже видели в панели управления блогом в разделе «Инструменты» ссылочку «Экспорт»? Это самое первое, что может попасться под руку. Да действительно, таким образом можно сделать резервную копию, но…
Этим способом Вы получите лишь один файлик, в котором будет содержаться только текстовая часть Вашего дневника. То есть ни графики, ни шаблона дизайна этот файл не содержит. Особенной пользы от этой функции — не вижу. Поэтому идём дальше.
Первый способ
Самым правильным способом сделать резервную копию своего блога, это открыть панель управления Вашим хостингом и сделать полный бэкап. Идем к хостеру.
Обычно хостер предоставляет для управления Вашей учётной записью так называемую cPanel. У разных компаний по предоставлению хостинга эта панель может отличаться внешне, но попробуйте разыскать вкладку «Мастер резервного копирования».
Вот как эта вкладка выглядит у меня:
ustanovkablogana.wordpress.com
