3 способа резервного копирования и восстановления базы данных в WordPress


Оглавление (нажмите, чтобы открыть):

Как восстановить сайт WordPress одной лишь копией баз данных

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

Приступаем

В рамках этой статьи мы предполагаем, что у вас есть бэкап вашей базы данных в виде .zip-файла. Для начала вам понадобится создать новую базу данных. Просто зайдите в свой профиль cPanel и щелкните по MySQL Databases под разделом Database.

Затем укажите название своей базы данных и щелкните по кнопке create database.

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

Укажите имя пользователя и крепкий пароль. Потом вам надо добавить созданного пользователя к базе данных. Прокрутите вниз до Add user to database и выберите пользователя вместе с базой данных из выпадающих меню и нажмите кнопку Add.

Импорт резервной копии базы данных ВП

Зайдите в cPanel и под разделом баз данных щелкните по phpMyAdmin.

Затем выберите базу данных, созданную ранее на странице phpMyAdmin и щелкните по кнопке импорта. Теперь вам надо щелкнуть по кнопке выбора файлов для загрузки резервной копии базы данных.

После успешного импорта базы данных следующим шагом будет установка ВП, используя вашу новую БД.

Восстановление сайта Вордпресс

Для ручного восстановления ВП вам понадобится вручную установить Вордпресс на свой сервер. Во время установки, когда вы дойдете до шага create a configuration file, введите название базы данных и пользователя, которого создали ранее.

Вы увидите сообщение, что ВП может подключиться к вашей базе данных и вы сможете запустить установку. Щелчок по кнопке установки покажет вам сообщение Already Installed.

На этом все, можете зайти на свой сайт.

Устранение проблем

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

1. Шаблон

Просто установите свежую копию вашего старого шаблона WordPress. Если вы вносили изменения в старый шаблон, то они все исчезнут.

2. Виджеты

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

3. Постоянные ссылки

Структура постоянных ссылок вашего сайта также хранится в базе данных и будет автоматически восстановлена. Однако если вы видите ошибки 404, то вам надо обновить настройки постоянных ссылок. Просто зайдите в Settings > Permalinks и нажмите по кнопке сохранения настроек без изменения чего-либо. Это обновит вашу структуру адресов WordPress.

4. Плагины

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

Скопируйте названия плагинов и начните устанавливать и активировать их один за другим.

Восстановление утерянных изображений

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

1) Загляните в кэш своего браузера

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

Вы можете просто щелкнуть правой кнопкой по изображению и выбрать сохранить его из меню. Пользователи Google Chrome на Windows могут использовать Chrome Cache Viewer. Пользователи же Мака остаются за бортом, так как мы не смогли найти эффективный инструмент для предпросмотра и сохранения изображений в кэше браузера на Маке.

2) Поиск ваших изображений в кэшах веб-страниц

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

Можете щелкнуть по изображению, чтобы увидеть более крупную версию картинки и сохранить ее. Если же речь идет о восстановлении более старого сайта и вы не можете найти изображения в Google или Bing, то вы можете поробовать сайт Archive.org Это бесприбыльная организация, которая хранит снимки сайтов в исторических целях.

Поиск и замена изображений на вашем сайте

Если на вашем сайте было много контента, то поиск и замена изображений вручную может оказаться нелегкой задачей. Вот простой способ как можно быстро обнаружить и заменить неисправные картинки. Установите и активируйте плагин Broken Link Checker. После активации зайдите на страницу Tools > Broken Links Checker. Плагин покажет вам список всех неисправных ссылок на вашем сайте.

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

Бонусный совет

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

Наша специальность — разработка и поддержка сайтов на WordPress. Контакты для бесплатной консультации — [email protected] , +371 29394520

WordPress — восстановление базы данных из резервной копии sql

April 11, 2013

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

Казалось бы, все, сайт пропал бесследно, как в воду канул. Но, в те далекие времена у меня хватило благоразумия делать регулярные резервные копии сайта, благо, под WordPress имеются несколько плагинов для этой цели. Удобных и относящихся к разряду “must have”.

Одним из них я и воспользовался. Названия этого плагина уже не помню. Но результатом его работы была заархивированная резервная копия базы данных сайта, которую плагин отправлял на мой почтовый ящик в качестве вложения в письмо. Файл-вложение имел примерный вид . Из расширения этого файла видно, что это архивированная (о чем говорит расширение ) база данных (расширение ). Цифры — это дата, когда было выполнено резервное архивирование — 25 февраля 2010 года, а — это домен, на котором когда-то располагался данный сайт.

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

Первыми моими шагами были следующие. Резервную копию предполагалось развернуть на локальном сервере. Наиболее известным в этом плане является пакет Denwer. Поэтому он был скачан и установлен на локальную систему. Сам процесс установки Denwer в данной статье я описывать не буду, так как в Интернет имеется достаточное количество хороших материалов на эту тему.

В мою задачу входит восстановление статей, которые были когда-то размещены на этом сайте. С точки зрения полноценного восстановления сайта способ, описанный здесь, является незаконченным, так как сам сайт (его , в частности) восстановлен не был, что привело к так называемому “белому экрану смерти”. Стоит также оговориться, что, возможно, существуют команды и правки резервной копии базы данных, с помощью которых можно “напрямую” восстановить статьи, не заморачиваясь с phpMyAdmin и WordPress. Но для автора такие команды неизвестны, а способ, приведенный ниже, является более наглядным и простым.

Мною был скачана свежая версия CMS WordPress — 3.5. Но только скачана — не установлена. Данный шаг будет в дальнейшей последовательности действий самым последним.

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

  1. Запускаю локальный сервер Denwer. Это можно сделать разными способами, но если установка происходила в точности по инструкциям самого пакета, то на Рабочем столе должны быть три ярлычка — “Start Denwer”, “Restart Denwer”, “Stop Denwer” — которые запускают, перезапускают или останавливают Denwer. Я такими ярлычками и воспользовался, щелкнув мышью на ярлыке “Start Denwer”. На несколько секунд мелькнет и пропадет окно терминала, а в панели задач появится значок Denwer’а, говорящий о том, что локальный сервер запустился и готов к работе:
  1. Вторым шагом мне необходим доступ к базам данных локального сервера. В состав пакета Denwer входит графическое приложение phpMyAdmin, с помощью которого очень удобно работать с базами данных MySQL. Иногда в Интернет встречается сокращенное название этого приложения — . Так как сервер уже запущен, то я захожу в панель управления базами, набрав к адресной строке браузера (любого — это дело вкуса и дела совсем не меняет) — . Откроется окно phpMyAdmin, в левой половине которого будет список уже имеющихся баз данных, созданных во время инсталляции локального сервера:
  1. Теперь необходимо создать новую базу данных, в которой и будет развернуты резервные копии таблиц сайта . Стоит заранее оговориться, что база данных будет в нашем случае создана пустой, таблиц в ней не будет. Последние будут взяты из backup’а. Итак, перехожу на вкладку “Базы данных” и создаю новую, введя в поле нужное мне имя — . На самом деле имя может быть любым. Нажимаю кнопку “Создать”. База данных появляется в списке:
  1. Перед импортом резервной копии базы данных необходимо отметить один момент. Доменное имя, на котором находился когда-то сайт, нужно поменять. Ведь в таблицах резервной копии везде прописана ссылка на , а в нашем случае копия будет восстанавливаться на домене . Также в таблицах необходимо исправить имя базы данных — она также изменилась и теперь называется . Можно также изменить и пароль пользователя, но проще это сделать уже потом, после импорта в phpMyAdmin.

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

Итак, в первую очередь, распаковываю резервную копию . В результате получился файл довольно приличного размера — около 4Мб. По своей сути он представляет из себя обычный текстовый файл, который можно и нужно открыть в любом редакторе.

  1. Запускаю его в AkelPad и начинаю правку. Нахожу строчку Database: (она находится в самом начале файла, тут проблем не возникает) и меняю ее значение на Database: . Все — имя базы данных исправлено. Теперь необходимо найти все ссылки вида , и заменить их на . Для этого воспользуюсь автоматизированным инструментом поиска и замены в редакторе AkelPad, иначе вручную эта операция может занять неизвестно сколько времени:

Сохраняю измененный файл и закрываю его. Стоит также упомянуть еще один момент. При редактировании файла можно заметить многочисленные ссылки, указывающие на плагины, которые когда то были установлены в WordPress на сайте . Но в версии WordPress, которую я буду устанавливать на локальном хостинге Denwer, их не будет. Этот факт приведет к эффекту так называемого “белого экрана смерти” в WordPress. То есть, при вводе в адресной строке браузера страница откроется, но изображено на ней ничего не будет — она будет пуста, как чистый лист бумаги. Но для меня данный факт не является критичным. В мою задачу, как уже говорилось ранее, входит восстановление статей, но не самого сайта.

Теперь можно импортировать таблицы в созданную пустую базу данных .


  1. Захожу в эту базу данных (для этого достаточно кликнуть одинарным щелчком мыши на самом названии этой базы в списке) и вижу, что она действительно пустая, о чем говорит надпись “Таблиц в базе данных не обнаружено”. Но я их и не собираюсь создавать — они у меня уже есть, только в резервной копии. Мне нужно только их импортировать из ранее скачанного ‘а в базу данных . Для этого перехожу на вкладку “Импорт” и выбираю файлик :

Нажимаю кнопку ОК в самом низу окна. Начнется процесс импорта. И тут же возникает ошибка:

Это говорит о том, что в настройках Denwer имеется ограничение по размеру загружаемого файла, моем случае это . Основной файл настроек Denwer’а — , а параметр, отвечающий за размер загружаемого файла — .

Расположение файла я не знаю (а если и знал, то забыл), поэтому проще всего найти его с помощью инструмента поиска TotalCommander:

Перехожу к найденному с помощью кнопки “Перейти к файлу” и открываю его в текстового редакторе (может быть любым, но лучше специализированный — Notepad++ или AkelPad). Теперь необходимо найти параметр . Для этого опять воспользуюсь инструментом поиска, но уже текстового редактора (у меня это AkelPad):

Вижу, что значение по умолчанию для этого параметра равно 2Мб. Мой распакованный файл резервной копии имеет размер 3,88Мб. Поэтому меняю параметр на 8Мб (с запасом). Сохраняю изменения в файле и обязательно не забываю перезапустить Denwer, чтобы изменения вступили в силу.

Снова пробую импортировать таблицы в базу данных . На этот раз операция проходит успешно:

Осталась последняя операция с таблицами в базе данных. Так как ни имени пользователя, ни пароля к нему я не помню (давно уже это было), то необходимо изменить хотя бы пароль для входа в административную часть сайта. Открываю в phpMyAdmin базу данных (если она еще не открыта) и в левом списке нахожу таблицу . Открываю ее и вижу одну единственную строку, в которой прописана учетная запись в WordPress, под которой я размещал статьи.

Нажимаю на ссылку “Изменить” для входа в редактирование учетной записи. Появится небольшая табличка с десятью строками. Мне необходима строка . В столбце “Функция” из раскрывающегося списка выбираю алгоритм шифрования MD5. В поле столбца “Значение” прописан предыдущий пароль в зашифрованном виде. Очищаю это поле и ввожу туда новый пароль, пусть это будет :

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

  1. Половина дела сделана. Теперь осталось только установить саму систему управления контентом WordPress. При установке созданная мною база данных подключится к этой CMS.
Мастер Йода рекомендует:  5 причин, по которым ваши твиты не находят отзыва у фолловеров

Открываю файловый менеджер (для меня удобнее всего работать с Total Commander), перехожу на локальный диск Z, созданный и запущенный программой Denwer. В Total Commander последовательно создаю директории для будущей локальной копии сайта . Сперва создаю директорию , затем еще одну вложенную директорию .

Распаковываю скачанный WordPress версии 3.5 по пути . Проще всего это сделать таким образом. Открыть архив в WordPress в другой панели Total Commander, выделить все содержимое архива Ctrl+A и перетащить выделенные файлы мышью в противоположную панель Total Commander. Программа спросит, распаковывать ли такие-то файлы в указанное место. Соглашаюсь и через пару секунд разархивация и копирование будут выполнены:

Перезапускаю Denwer с помощью ярлыка “Restart Denwer” на “Рабочем столе”. Это необходимо для того, чтобы все изменения, внесенные мною — создание базы данных и импорт в нее таблиц — вступили в силу.

Остается только установить саму систему управления контентом WordPress. Процесс инсталляции стандартный и мало отличается от предыдущих версий WordPress, разве что немного изменился сам интерфейс пошагового мастера и стал удобнее. В адресной строке браузера ввожу и жму Enter . Установка WordPress начата:

Соглашаюсь с пошаговым мастером и нажимаю кнопку “Создать файл настроек”. После успешного создания файла настроек откроется окно, которое является вторым шагом при установке WordPress. Оно не требует ввода каких-либо данных. Просто жму кнопку Вперед .

Третье окно является, если так можно сказать, самым главным, так как здесь необходимо ввести такую важную информацию, как имя базы данных, которая будет подключена к устанавливаемой системе WordPress, имя пользователя (и его пароль) указанной базы данных. В моем случае я не стал усложнять задачу и создавать отдельного пользователя для базы данных . Воспользовался учетной записью , созданной пакетом Denwer по умолчанию. Так как для этой учетной записи не установлен пароль, то в поле ввода “Пароль” просто стер предыдущее значение и оставил его пустым:

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

Жму отправить. Мастер установки отрапортует, что все в порядке, указанные мною данные верны и существующая база данных успешно подключена. Можно запускать установку WordPress. Нажимаю кнопку “Запустить установку”.

В браузере появиться сообщение о том, что: “Вы уже установили WordPress. Для переустановки, пожалуйста, сначала очистите старые таблицы в базе данных”. Нажимаю на кнопку Войти . Откроется обычное окно для входа в административную панель WordPress. Ввожу логин пользователя — , и пароль (который я изменил) — .

Откроется еще одно окно с предупреждением о том, что необходимо обновить базы данных:

Соглашаюсь с предложением. После сообщения о том, что: “База данных WordPress успешно обновлена!” жму кнопочку Продолжить .

Откроется панель администратора WordPress. Красным будет ярко высвечена надпись о том, что: “ОШИБКА: Директория тем либо пуста, либо не существует. Убедитесь, что дистрибутив установлен полностью”. Что же, данный факт, помимо отсутствия плагинов, будет причиной белого экрана сайта.

Перехожу в пункт меню “Записи” и вижу то, ради чего все и затевалось — записи, записи, записи. Вверху шапка сайта с таким романтическим названием:

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

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

Резервное копирование базы данных и восстановление из резервной копии?

Я использую WordPress 3 и хочу сделать резервную копию базы данных на моем компьютере (Mac). Мой веб-хостинг использует безопасный режим PHP, поэтому иногда ограничивает, какие плагины я могу использовать. Каков хороший способ сделать резервную копию базы данных? Можно ли автоматизировать? Являются ли инкрементные резервные копии рекомендуемыми / легкими? Очевидно, мне тогда нужно протестировать восстановление резервной копии.

Solutions Collecting From Web of «Резервное копирование базы данных и восстановление из резервной копии?»

Я лично имел ограниченный успех с плагинами резервного копирования / восстановления, которые обычно доступны. Много раз лучшие резервные плагины не позволяют прямое восстановление из файла резервной копии. Поэтому я делаю это вручную. Это немного сложнее, но гораздо надежнее.

Резервное копирование с помощью phpMyAdmin

  1. Войдите в панель управления вашего хоста (это может быть cPanel, это может быть что-то еще).
  2. Найти phpMyAdmin и перейти в базу данных WordPress
  3. Нажмите «Экспорт»
    1. Убедитесь, что все таблицы выбраны
    2. Выберите вариант сохранения в виде текстового файла
    3. Экспортируйте базу данных и сохраните экспортированный файл в безопасном месте.

Восстановление с помощью phpMyAdmin

  1. Войдите в систему по-прежнему, зайдите в phpMyAdmin, выберите свою базу данных
  2. Если вы хотите полностью восстановить (т. Е. Удалить все и вернуться в файл резервной копии):
    1. Очистить все таблицы базы данных
    2. Нажмите «Импорт»
    3. Загрузите резервный текстовый файл, чтобы восстановить все предыдущие данные

Я сделал это с 10 различными сайтами. Единственный раз, когда у него проблемы, когда файл резервной копии огромен (> 2 МБ). В этих ситуациях вам нужно будет открыть файл резервной копии в текстовом редакторе (Блокнот или Wordpad) и скопировать-вставить каждый набор SQL-запросов (я разбиваю их по таблице) в окно оператора phpMyAdmin. Даже тогда, это довольно быстрый процесс и будет работать каждый раз.

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

Я бы начал с чтения разделов в Codex в WordPress Backups , Резервное копирование базы данных и Восстановление базы данных из резервной копии , чтобы получить хорошее представление о связанных с этим проблемах.

Для автоматизации процесса резервного копирования базы данных имеется несколько плагинов . Из-за вашей проблемы с веб-хостом вам, возможно, придется просто попробовать несколько, чтобы найти тот, который работает. Я не знаю плагина, который также можно восстановить из резервной копии – для этого вам, вероятно, придется использовать PHPMyAdmin или эквивалентный инструмент для восстановления вручную.

Одна вещь, которая мне нравится в параметрах автоматического резервного копирования, заключается в том, что некоторые (все?) Из них имеют возможность отправлять вам сжатый файл базы данных (т. Е. Db123.sql.gz). Я просто создаю фильтр в своем почтовом клиенте, чтобы обойти мой почтовый ящик и архивировать сообщение, поэтому я могу получить доступ к истории изменений моей базы данных. В качестве альтернативы, если вы хотите быть уверенным, что резервные копии все еще происходят, вы не можете отфильтровывать их, чтобы обойти свой почтовый ящик и вручную архивировать / сохранять каждый раз.

Существует несколько коммерческих вариантов резервного копирования. Резервное копирование , BackupBuddy и VaultPress весной легко вспомнить.

Если ваш веб-хостинг имеет cPanel, вы можете проверить там раздел резервного копирования / восстановления. У двух моих хостов очень простые в использовании инструменты, чтобы выполнить полную или частичную БУ или восстановить, доступную через cPanel. Конечно, они не являются автоматическими или инкрементальными, но, возможно, полезными для вас, тем не менее. Простите меня, если вы уже знаете это, но одной только DB недостаточно; вам понадобятся файлы и папки.

Это не резервная копия базы данных как таковая, но вы можете экспортировать содержимое своего сайта в WXR-файл (формат XML) и восстановить его на другой установке. Это немного проще и не требует доступа к вашему серверу MySQL или PhpMyAdmin. У вас есть варианты для экспорта и импорта.

Эту функциональность можно найти в разделе « Импорт и экспорт» в меню « Сервис» в администраторе WP.

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

Я бы рекомендовал вам попробовать плагин HotBackup , который мог бы создавать резервные копии базы данных, отправлять их по электронной почте или загружать на удаленный FTP или даже загружать их на свою учетную запись Dropbox или Amazon S3. Плагин создает резервные копии автоматически, в соответствии с настройками расписания. Кроме того, этот плагин может восстановить вашу резервную копию.

Автоматическое резервное копирование WordPress сайта с помощью WordPress Database Backup

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

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

Начнем с вопроса обсуждения важности резервного копирования сайта.

Сейчас ни для кого не секрет, что в любой момент может что-то пойти не так:

  • Могут взломать сайт;
  • От некорректных настроек сайт может лечь (перестать работать);
  • Хостинг перестанет существовать;
  • Случайно можете удалить какие-то страницы или файлы сайта.


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

Один раз я проводил технические эксперименты на сайте, который размещен на реальном хостинге (нужно делать это на локальном сервере). Из-за этого сайт просто перестал загружаться. Пришлось заново устанавливать WordPress, что доставило мне массу неудобств.

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

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

Дело в том, что файлы сайта не хранят никакой информации об опубликованных материалах, комментариях и так далее. Все данные содержаться в базе данных. Файлы сайта — это по сути просто набор плагинов и сам движок. Единственное, над чем может потребоваться поработать, так это над загрузкой изображений, так как в случае их исчезновения (удаления) придется заново их искать и загружать на сайт.

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

Этим мы и займемся сейчас. Рассмотрим процесс создания бэкапов базы данных и файлов движка сайта.

Автоматическое резервное копирование базы данных WordPress сайта

Как вы понимаете, раз резервное копирование будет проходить автоматически (без нашего участия), то будем использовать какое-то готовое решение. В нашем случае это плагин WordPress Database Backup. Отношу его к важным плагинам. Скачиваем с официального сайта по кнопке ниже.

Существуют и другие плагины, но мне понравился данный вариант своей простотой и надежностью.

После установки данного плагина в админ-панели блога появляется новый пункт «Инструменты — Резервное копирование».

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

За ручное резервное копирование отвечают первые 2 блока:

  1. Таблицы;
  2. Настройки резервного копирования;

База данных состоит из таблиц и, поэтому, в данной области мы выбираем содержимое базы, которое будет сохраняться при создании бэкапа.

Видно, что имеется 2 типа таблиц:

  1. Основные — таблицы, которые создаются самим движком WordPress и они по умолчанию всегда архивируются в резервную копию;
  2. Дополнительные — таблицы, создающиеся каким-либо плагинами. В моем случае можем увидеть, что имеются 2 таблицы, которые создались сторонним плагином (плагин опросов wp-polls).

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

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

После выбора всех таблиц можем создать архив, нажав на кнопку ниже «Создать архив» и выбрав место, куда он сохранится. Выберу вариант «Скачать на компьютер».

После нажатия на кнопку начнется процесс архивации БД, который будет сопровождаться полосой прогресса, появившейся вверху страницы.

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

После этого, в месте сохранения должен появиться файл резервной копии с расширением «sql» в сжатом архиве «gz».

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

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

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

Для этого внизу настроек плагина имеется блок «Расписание резервного копирования» и в нем все точно также. Только архив будет отправляться на указанный e-mail.

Выбираем все существующие таблицы (основные таблицы автоматически все включены), выбираем интервал создания архива БД ( минимум каждый день ) и жмем на кнопку «Запомнить расписание». Также не забываем указать правильный e-mail адрес.

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

Данный вариант очень удобный для ленивых владельцев сайта, которые не хотят делать это действие каждый день руками. Я сам из таких.

Вот видео-урок по плагину WordPress Database Backup.

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

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

Чтобы сделать архив базы данных, заходим в панель управления своего хостинга и ищем пункт «Базы данных».

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

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

В левой колонке будет список баз (если кнопка одна) или же одна база, напротив которой вы нажали на кнопку phphMyAdmin. Жмете на базу данных и попадаете на страницу со списком всех таблиц.

На данной странице также появляется верхнее меню. В нем нас интересует кнопка «Экспорт». Жмем на нее и попадаем на страницу экспорта таблиц базы данных в архив.

Выбираем обычный способ экспорта, после чего нам откроется множество настроек, из которых нужно выбрать только «Компрессия — gzip», кодировку utf-8 и нажать в самом низу страницы на кнопку «ОК». При этом все таблицы должны быть выделены.

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

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

Кроме такого ручного способа на хостинге может быть возможность создавать резервные копии без вмешательства в phpMyAdmin. Например, на Макхосте имеется такая возможность. Да и на других должна 100% быть.

Как видно на скриншоте, я поставил чек-бокс «Не создавать архив сайта». То есть можно вместе с архивом БД создать архив с файлами сайта. При таком способе все архивы помещаются в папку на вашем хостинге. У каждого хостинга папка может быть разная, но ее название и путь к ней будет вам предоставлен.

Мастер Йода рекомендует:  Как заменить текст на картинке с помощью Adobe Photoshop

Теперь рассмотри процесс, как можно создать резервную копию самого сайта, то есть всех файлов, лежащих на хостинге.

Резервное копирование файлов сайта

В данном процессе нет абсолютно ничего сложно.

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

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

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

Вот, как это выглядит у меня.

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

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

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

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

Курс называется «Резервное копирование по методу Евгения Попова» .

На этом я данную статью заканчиваю. Если имеются какие-то неясности, вопросы и идеи, то добро пожаловать в комментарии. Был рад вас видеть.

Восстановление WooCommerce из резервной копии

Вступление

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

Общий принцип восстановление WooCommerce из резервной копии

Причин, по которым перед вами может встать задача, восстановить магазин из резервной копии, столько же, сколько причин эти копии делать. Это взлом сайта, конфликт установленных плагинов, «белый экран» WordPress и т.д.

Варианты восстановления магазина, а по сути, это восстановление всей CMS WordPress, зависит от той резервной копии, которую вы используете. Именно метод резервного копирования, применяемый вами, определяет шаги восстановления WoCommerce.


Восстановление WooCommerce из ручной резервной копии

Ручная резервная копия сайта включает файл базы данных и корневой каталог сайта. Для восстановления сайта этим способом, не требуется вход в административную панель сайта. Потребуется FTP клиент и авторизация в phpmyadmin.

Восстановление сайта

Каталог сайта Woprdpress восстанавливается по FTP, с помощью программы FTP клиент, например, WinSCP или FileZilla. Для этого:

  • Зайдите на сервер сайта по FTP;
  • Удалите все папки и файлы сайта с сервера;
  • Залейте на сервер каталоги и файлы из резервной копии сайта.
  • Проверьте правильность закачки инструментом «Сравнение».

Восстановление таблиц БД

Для восстановления таблиц БД, вам нужно авторизоваться в phpmyadmin из административной панели вашего хостинга. На всех типах панелей управления это будет вкладка «phpmyadmin».

  • Откройте базу данных сайта-магазина;
  • Выделите все «чеки» всех таблиц;
  • Кнопкой «Удалить» внизу списка таблиц, всё удалите;
  • Вверху страницы используйте кнопку «Импорт», она позволит закачать резервную копию базы данных;
  • На следующей вкладке выберите резервный файл базы данных с диска своего компьютера. Дата файла должна соответствовать дате восстановленных файлов системы;
  • Кнопка действия типа «OK» восстановит базу данных магазина.

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

Восстановление из копии Akeeba

Akeeba отличный плагин для быстрого создания резервной копии WooCommerce. О нём я писал статью тут. Для восстановления WooCommerce из резервной копии плагина Akeeba, делаем следующее:

  • Авторизуйтесь в панели сайта-магазина;
  • Зайдите в панель Akeeba;
  • Далее на вкладку «Менеджер резервных копий»;
  • Выделите чек нужной резервной копии, сделанной заранее, и нажмите кнопку «Восстановить»;
  • В следующем окне выберите Метод извлечения файлов «FTP …» и нажмите начать восстановление.

Если вы хотите восстановить сайт магазина вручную, то для распаковки архива резервной копии вам понадобится бесплатный плагин Akeeba Kickstart Core. Вот ссылка для скачивания: https://www.akeebabackup.com/latest-kickstart-core.zip .

Поясню последнее. Этот вариант работает, если вы заранее скачали резервную копию сайта, сделанную плагином Akeeba. Для этого в менеджере копий есть кнопки «Скачать» и у вас НЕТ доступа в административную панель сайта. Шагаете так:

  • Входите в каталог сайта по FTP;
  • Удалите все папки и файлы сайта;
  • В «чистый» корень сайта заливаете архив резервной копии Akeeba;
  • В корень сайта заливаете один файл kickstart.php из архива «latest-kickstart-core.zip»;
  • В браузере введите ваш домен через слэш kickstart.php;
  • Следуйте инструкции восстановления.

Видео плагин Akeeba

Более подробно на видео:

Из копии других плагинов

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

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

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

Вывод

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

BackupBuddy v8.3.6.0 – резервное копирование и восстановление WordPress

Вашему сайту WordPress нужна надежная стратегия резервного копирования с использованием надежного модуля резервного копирования WordPress, такого как BackupBuddy. WordPress не включает встроенное резервное копирование, поэтому разработчики iThemes создали BackupBuddy в 2010 году, чтобы удовлетворить потребность в надежном решении для резервного копирования WordPress. Даже если ваша резервная копия может оказаться недоступной, если вы столкнулись с сбоем сервера.

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

Твердая стратегия резервного копирования WordPress

BackupBuddy сочетает все четыре элемента резервного копирования в одном плагине.
Для создания полной резервной копии требуется четыре компонента. Некоторые решения для резервного копирования охватывают их, но не все, что делает ваш сайт уязвимым. BackupBuddy охватывает все четыре резервных элемента в одном плагине.

Комплексное резервное копирование веб-сайта на WordPress

Создайте резервную копию всего веб-сайта WordPress (база данных + все файлы WP).

Запланированное резервное копирование

Настройте расписание резервного копирования для автоматического запуска.

Удалённое хранение бэкапов

Отправляйте и храните резервные копии файлов за пределами хоста в безопасно месте.

Восстановление сайта на WordPress

Быстро и легко восстанавливайте веб-сайт WordPress из резервной копии.

Как восстановить WordPress-сайт из бэкапа

Этот урок — продолжение первой части — «Как сделать бэкап WordPress-сайта«. Теперь рассмотрим обратную процедуру. Я опишу, как восстановить WordPress-сайт из бэкапа и развернуть его на другом сервере с другим доменом.

Сразу оговорюсь, что выполнение этого урока требует немного большей подготовки, чем в первом случае. Нам предстоит вручную править .php файлы, импортировать таблицы в базу данных через phpMyAdmin и загружать весь контент по FTP-соединению.

Ну что же, давайте попробуем.

Предыстория

Итак, допустим у нас был вот такой WordPress-сайт с набитым тестовым контентом, оформленный на замечательной теме iTheme2.

В описанной далее ситуации я рассмотрю один из худших возможных сценариев.

Мы воспользовались бэкап-плагином wp Time Machine, и все, что у нас осталось — это папочка backup да всего 5 файлов (если эти файлы лежат у вас на ящике Dropbox, загрузите их на компьютер, они нам сейчас понадобятся).

А сайта больше нет, как и всего содержимого. И домена нет. А восстановить надо!

Подготовка

Процедура восстановления будет построена следующим образом. Для чистоты эксперимента я зарегистрировал новый бесплатный домен в зоне .pp.ua. Хостинг у меня уже был, поэтому я просто привязал домен к хостингу.

Нам нужно будет создать новую базу данных, куда мы импортируем все записи из старого сайта. Потом мы на компьютере «слепим» сам сайт с движком WordPress и его потрохами (папка wp-content). И потом зальем сайт через FTP на новый хостинг.

Создаем новую Базу Данных

В папке бэкапа есть файл wpTimeMachine-data-files.sql. В нем хранится набор инструкций на языке SQL для импорта таблиц и значений в базу данных. Но, чтобы импортировать эти таблицы и значения, нужно сначала создать Базу Данных, а потом в нее импортировать.

Воспользуйтесь консолью управления вашего нового (или текущего) сайта, чтобы создать новую БД. Имя базы роли не играет, как и имя пользователя. Главное, чтобы это была новая база с уникальным пользователем и паролем.

В cPanel это находится тут:

На Plesk-e — тут:

Создайте новую Базу Данных и добавьте к ней нового Пользователя.

Импорт Базы Данных

Перед импортом файла wpTimeMachine-data-files.sql надо его немного отредактировать. Дело в том, что внутри в некоторых значениях хранятся ссылки на старый домен. Т.к. по нашему сценарию его больше не существует, обновим эти ссылки на новый домен.

Откройте файл текстовым редактором с поддержкой разметки языка SQL (например Notepad++ ) и замените значение старого домена на новый.

Теперь файл .sql готов к импорту в новую Базу Данных.

Открываем phpMyAdmin (или через cPanel, или через Plesk, или обратитесь к хостинг-провайдеру для этой процедуры). Слева выбираем нашу новую Базу, жмем на Import в верхней панели и указываем на отредактированный файл wpTimeMachine-data-files.sql. Другие параметры менять не нужно, просто жмем Go.

Если вы все сделали правильно, то слева появится структура БД с импортированными таблицами, и вы увидите следующее сообщение:


Теперь можем закрыть phpMyAdmin, он нам больше не понадобится.

На этом работа с Базой Данных закончена. Переходим к следующему этапу.

«Собираем» сайт

Теперь займемся файловой структурой самого сайта.

Распакуйте архив wpTimeMachine-content-files.zip из папки бэкапа. Внутри архива может быть несколько подкаталогов, нам нужно добраться до папки wp-content. В ней хранятся все наши темы, загруженные плагины, изображения и медиафайлы. Но одной этой папки не достаточно для работы сайта. Нужен сам движок WordPress.

Загрузите отсюда последнюю версию WordPress и распакуйте архив. Внутри архива среди всех файлов WordPress-а уже будет папка wp-content. Удалите ее и замените папкой wp-content из архива бэкапа.

wp-config.php

Теперь в нашем каталоге уже есть движок WordPress и папка с контентом wp-content. Но для работы сайта еще не хватает файла wp-config.php. Он не включается в архив бэкапа потому, что в нем хранится информация о привязке к старой Базе Данных. Не беда, восполним упущенное!

Загрузите файл wp-config.php и отредактируйте следующие значения:

Укажите Базу Данных, ее Пользователя и Пароль. Эту информацию вы указывали на этапе создания новой БД.

Затем перейдите по этой ссылке:

и скопируйте полученные ключи безопасности в файл wp-config.php несколькими строками кода ниже:

Сохраните файл wp-config.php и поместите его в папку с остальными файлами сайта.

.htaccess

Остался последний штрих. Возьмите файл wpTimeMachine-htaccess.txt и переименуйте его в .htaccess

Обратите внимание, что у файла не должно быть расширения .txt !

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

Загрузка сайта на сервер

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

  1. Установите FTP-соединение с сервером и просто загрузите файлы на сайт (здесь инструкция по установке FTP-соединения).
  2. Или зайдите в Менеджер файлов сайта через консоль управления (cPanel, Plesk, etc.), если у вас есть такое право доступа, и загрузите файлы через веб-интерфейс.

Выберите тот вариант, который вам удобнее.

На этом все. Зайдите на новый сайт и убедитесь, что все работает как и раньше.

Насколько полезным был этот пост?

Нажмите на звезду, чтобы оценить этот пост!

Средний рейтинг: 5 / 5. Количество голосов: 1

Резервное копирование и восстановлении базы данных WordPress

Всем привет друзья, сегодня поговорим о дополнительной безопасности блога, а именно о резервном копировании и восстановлении базы данных WordPress. Я решил связать воедино эти понятия – копирование и восстановление, так как они тесно взаимосвязаны. Начнем с резервного копирования – делать копию базы данных нужно делать регулярно, и лучше всего, если этот процесс будет на автоматическом потоке и архив с базой данных будет приходить нам на e-mail.

Реализация этого процесса проста – скачиваем плагин wp-db-backup и устанавливаем его себе на блог (копируем папку с плагином в каталог /wp-content/plugins/ и активируем с админки) и делаем некие настройки. Настройка плагина простая, отмечаем выбранные поля и указываем е-mail для получения базы данных, также прописываем периодичность, с которой будут приходить архивы. Я рекомендую выставлять периодичность – раз в неделю.

Теперь представим ситуацию, что по тем или иным причинам наша база данных стает поврежденной или вообще стает недоступной (авария в дата-центре хостинг компании, взлом сайта, глюки самой базы данных…), нам нужно перенести сайт на другой домен и т.д., в этом случае нам понадобится та самая резервная копия для восстановления.

Рассмотрим 2 варианта восстановления базы данных.

Заходим в phpMyAdmin (приложение для работы с базами данных) – в левой колонке выбираем базу данных, для которой мы хотим сделать восстановление, и переходим на вкладку ”SQL”, открываем наш файл с базой и оттуда копируем содержимое в форму SQL и нажимаем кнопку Ок. Если все сделано правильно – то через некоторое время появится надпись — «SQL-запрос был успешно выполнен».

Аналогично заходим в приложение phpMyAdmin, выбираем нашу базу данных и переходим на вкладку ”Импорт”, после чего нажимаем кнопку “Обзор”, выбираем наш архив с базой данных (который приходит нам на почту) и нажимаем кнопку “Ок” (все настройки в окно оставляем по умолчанию). Если все сделано, верно, то появится надпись — «Импорт успешно завершен, запросов выполнено:» ваша цифра.

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

Если в процессе у вас возникнут вопросы пишите в комментариях, обязательно помогу.

Как восстановить сайт? 4 способа восстановления сайта

Сегодня я решил подробно написать о том, как восстановить сайт, который уже потерян. Вы узнаете, как восстановить сайт из бэкапа (резервной копии), с кэша поисковых систем, с архива archive.org и с RSS ленты.

В общем, если вы потеряли свой ресурс, то это не проблема, есть много вариантов, как его можно восстановить.

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

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

Как часто делать копии сайта? Я, например, делаю после каждого обновления блога, и вам также советую. Конечно, копии сайта должны делаться автоматически на хостинге, но как я уже писал в начале статьи, с хостингом могут случиться различные проблемы, поэтому я ему не доверяю :smile:. Да, кстати, о том, как сделать резервное копирование сайта, я уже писал на своем блоге, советую прочитать данную статью, там все подробно написано на примере моего хостинга Макхост.

Мастер Йода рекомендует:  Nival создала первый в мире нейросетевой ИИ для игры «Блицкриг 3»

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

1) Как восстановить сайт из резервной копии?
Этот способ подойдет для тех, у кого есть бэкап сайта и базы данных. Если у вас нет копии своего ресурса, то вы также можете написать хостеру, возможно они у него сохранились.

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

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

Давайте сначала разберемся с файлами. Зайдите в корневую папку на своем хостинге, обычно она называется public_html , www, domains или HTDOCS. Дальше нужно нажать на кнопку «закачать файл», или что-то вроде этого, в каждом хостинге по-разному. Потом найдите на компьютере архив и закачайте его на хостинг. Дальше разархивируйте файлы, а сам архив можете удалить. Ну, вот и все, с файлами, думаю все понятно.

Для экспорта базы данных вам нужно войты в phpMyAdmin. Если у вас уже есть база данных, то отлично, открывайте ее, если базы нет, то ее нужно создать. В разделе phpMyAdmin должна быть где-то кнопка под названием «Создать базу». Нажимайте на нее и вас попросят ввести имя базы, логин и пароль. Если ваш ресурс сделан на движке wordpress, то эти данные нужно брать с файла wp-config.php. Подробнее об этом я писал в статье о переносе сайта с одного хостинга на другой.

После создания базы данных, открывайте ее, и в самом верху вы увидите кнопку «Импорт», нажмите на нее:

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

Если вы все сделали правильно, то ваш сайт должен работать. Давайте приступим к следующему способу восстановления сайта на случай, если копий у вас нет.

2) Восстановление сайта с помощью поисковых систем.
Если ваш ресурс уже не молодой, и он был проиндексирован поисковыми системами, то вполне возможно, что страницы еще остались в кэше. Для примера открываем поисковую систему Яндекс и вводим такой запрос:

site:vachevskiy.ru

Вместо vachevskiy.ru укажите свой домен. Яндекс нам находит все страницы, а рядом с ссылкой есть надпись «копия»:

Просто нажмите на эту надпись, и вы увидите копию страницы сайта, даже если ее уже не существует.

Точно такую же операцию можно сделать и в Гугле. Ввожу site:vachevskiy.ru, и вижу все страницы своего блога в выдаче. Дальше в конце URL нажимаю на маленький зеленый треугольник, появляется надпись «Сохраненная копия», нажимаю на нее:

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

3) Восстановление сайта с RSS.
Я уже писал на своем блоге о том, что такое RRS, можете прочитать. Если вы настроили rss ленту для своего сайта, то можете восстановить от туда страницы. Но здесь также важно, чтобы документы транслировались в полном содержании, поскольку иногда идет трансляция только анонса как у меня. А, например, тут, транслируются полные статьи и можно легко вытащить контент оттуда.

4) Как восстановить сайт из archive.org?
Об этом проекте я уже упомянул, когда писал статью на тему, как проверить историю своего домена. Archive.org – это сервис, на котором хранятся кэшированные копии почти всех проектов интернета. Если ресурс не молодой, то он должен там быть. Для того чтобы найти свой сайт, перейдите сюда, введите свой домен и нажмите на кнопку «BROWSE HISTORY». Вот я вижу, что последний архив моего блога был сделан 8 февраля 2014 года. Если навести курсор на дату, то можно увидеть даже время, когда был сделан архив.

Для того чтобы посмотреть, как выглядел ресурс 8 февраля 2014 года, я просто нажимаю на «8». Мне открываются все HTML страницы блога, но что с ними делать? Можно просто залить их на хостинг, изменить ссылки, и блог будет работать, но это, как вы понимаете, очень долго и нудно :smile:.

Чтобы быстро восстановить сайт с archive.org, есть прекрасный сервис r-tools.org. Сейчас я постараюсь разобрать работу этого ресурса подробно. Для начала перейдите по этой ссылке и пройдите простую регистрацию, после регистрации войдите на сайт. Вы увидите перед собой вот такую картинку. Возле надписи «имя домена для поиска на веб архиве» нажимаем на кнопку «списком»:

Вводим свой домен или несколько доменов и нажимаем «принять». Только домен нужно вводить без http и слеша в конце:

После нажатия кнопки принять сервис задаст вопрос «Что с этим делать, сэр?». Вам нужно нажать на кнопку «Восстановить сайт из веб архива»:

Дальше подождите несколько секунд, и вы увидите вод такое окошко:

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

Также укажите, как должны выглядеть внешние ссылки. Лучше всего ссылки преобразовать в текст, а уже потом самостоятельно их исправить. Дальше нажмите на кнопку «Начать процесс восстановления». Вы должны увидеть такое окошко:


Нажмите на кнопку «Перейти к списку заданий». Дальше нужно подождать несколько минут, чтобы сервис восстановил сайт с archive.org. Когда работа будет сделана, то ниже надписи «состояние» будет писать «завершено». Дальше нажмите на зеленую кнопку со стрелкой вниз, чтобы посмотреть результаты:

В отчетах вы можете увидеть, сколько файлов удалось восстановить. Потом нажмите на кнопку «Собрать ZIP-архив». Сервис вам создаст архив, вам останется его только скачать:

Сам архив состоит с файлов, которые удалось восстановить. Дальше вам остается залить эти файлы на хостинг, исправить ссылки и радоваться тому, что сайт опять появился на свет :smile:.

На этом я данную статью заканчиваю. Теперь вы знаете, как восстановить сайт на wordpress. Всем, пока!

Автоматическое резервное копирование WordPress сайта с помощью WordPress Database Backup

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

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

Начнем с вопроса обсуждения важности резервного копирования сайта.

Сейчас ни для кого не секрет, что в любой момент может что-то пойти не так:

  • Могут взломать сайт;
  • От некорректных настроек сайт может лечь (перестать работать);
  • Хостинг перестанет существовать;
  • Случайно можете удалить какие-то страницы или файлы сайта.

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

Один раз я проводил технические эксперименты на сайте, который размещен на реальном хостинге (нужно делать это на локальном сервере). Из-за этого сайт просто перестал загружаться. Пришлось заново устанавливать WordPress, что доставило мне массу неудобств.

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

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

Дело в том, что файлы сайта не хранят никакой информации об опубликованных материалах, комментариях и так далее. Все данные содержаться в базе данных. Файлы сайта — это по сути просто набор плагинов и сам движок. Единственное, над чем может потребоваться поработать, так это над загрузкой изображений, так как в случае их исчезновения (удаления) придется заново их искать и загружать на сайт.

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

Этим мы и займемся сейчас. Рассмотрим процесс создания бэкапов базы данных и файлов движка сайта.

Автоматическое резервное копирование базы данных WordPress сайта

Как вы понимаете, раз резервное копирование будет проходить автоматически (без нашего участия), то будем использовать какое-то готовое решение. В нашем случае это плагин WordPress Database Backup. Отношу его к важным плагинам. Скачиваем с официального сайта по кнопке ниже.

Существуют и другие плагины, но мне понравился данный вариант своей простотой и надежностью.

После установки данного плагина в админ-панели блога появляется новый пункт «Инструменты — Резервное копирование».

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

За ручное резервное копирование отвечают первые 2 блока:

  1. Таблицы;
  2. Настройки резервного копирования;

База данных состоит из таблиц и, поэтому, в данной области мы выбираем содержимое базы, которое будет сохраняться при создании бэкапа.

Видно, что имеется 2 типа таблиц:

  1. Основные — таблицы, которые создаются самим движком WordPress и они по умолчанию всегда архивируются в резервную копию;
  2. Дополнительные — таблицы, создающиеся каким-либо плагинами. В моем случае можем увидеть, что имеются 2 таблицы, которые создались сторонним плагином (плагин опросов wp-polls).

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

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

После выбора всех таблиц можем создать архив, нажав на кнопку ниже «Создать архив» и выбрав место, куда он сохранится. Выберу вариант «Скачать на компьютер».

После нажатия на кнопку начнется процесс архивации БД, который будет сопровождаться полосой прогресса, появившейся вверху страницы.

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

После этого, в месте сохранения должен появиться файл резервной копии с расширением «sql» в сжатом архиве «gz».

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

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

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

Для этого внизу настроек плагина имеется блок «Расписание резервного копирования» и в нем все точно также. Только архив будет отправляться на указанный e-mail.

Выбираем все существующие таблицы (основные таблицы автоматически все включены), выбираем интервал создания архива БД ( минимум каждый день ) и жмем на кнопку «Запомнить расписание». Также не забываем указать правильный e-mail адрес.

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

Данный вариант очень удобный для ленивых владельцев сайта, которые не хотят делать это действие каждый день руками. Я сам из таких.

Вот видео-урок по плагину WordPress Database Backup.

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

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

Чтобы сделать архив базы данных, заходим в панель управления своего хостинга и ищем пункт «Базы данных».

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

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

В левой колонке будет список баз (если кнопка одна) или же одна база, напротив которой вы нажали на кнопку phphMyAdmin. Жмете на базу данных и попадаете на страницу со списком всех таблиц.

На данной странице также появляется верхнее меню. В нем нас интересует кнопка «Экспорт». Жмем на нее и попадаем на страницу экспорта таблиц базы данных в архив.

Выбираем обычный способ экспорта, после чего нам откроется множество настроек, из которых нужно выбрать только «Компрессия — gzip», кодировку utf-8 и нажать в самом низу страницы на кнопку «ОК». При этом все таблицы должны быть выделены.

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

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

Кроме такого ручного способа на хостинге может быть возможность создавать резервные копии без вмешательства в phpMyAdmin. Например, на Макхосте имеется такая возможность. Да и на других должна 100% быть.

Как видно на скриншоте, я поставил чек-бокс «Не создавать архив сайта». То есть можно вместе с архивом БД создать архив с файлами сайта. При таком способе все архивы помещаются в папку на вашем хостинге. У каждого хостинга папка может быть разная, но ее название и путь к ней будет вам предоставлен.

Теперь рассмотри процесс, как можно создать резервную копию самого сайта, то есть всех файлов, лежащих на хостинге.

Резервное копирование файлов сайта

В данном процессе нет абсолютно ничего сложно.

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

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

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

Вот, как это выглядит у меня.

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

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

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

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

Курс называется «Резервное копирование по методу Евгения Попова» .

На этом я данную статью заканчиваю. Если имеются какие-то неясности, вопросы и идеи, то добро пожаловать в комментарии. Был рад вас видеть.

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