SEO Маяк

Всем привет! Не так давно, Ваш покорный слуга, в ходе экспериментов с базой данных seo-mayak.com, конечно «случайно», снес основную ее часть. Так бывает.

Но что делать в такой ситуации? Вот как раз об этом я и собираюсь Вам рассказать. Тема сегодняшнего дня — сохранение и восстановление базы данных MySQL.

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

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

Так-то оно так и до «судного дня» я спокойно себя чувствовал, зная, что бэкап мне поможет. Но случилось так, что свою последнюю статью — Динамическая карта сайта XML я опубликовал 5 февраля ближе к концу дня, а последнее автоматическое сохранение базы данных на хостинге, было за 4 февраля.

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

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

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

Мой мозг никак не мог согласится с формулировкой — «Безвозвратно утеряны» и я не сдался. Но об этом немного позже. А сейчас я хочу рассказать, как предотвратить возникновение подобной ситуации.

Причины повреждения базы данных

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

Причина №1. Самая банальная, но весьма актуальная для России — это внезапное отключение электричества. К данной группе можно отнести также скачки напряжения, которые могут привести к повреждению оборудования на сервере.

Причина №2. Технические проблемы на сервере Вашего хостинг-провайдера. Надо очень внимательно относится к выбору хостинга.

Причина №3. Повреждения базы данных в следствии взлома и заражение вирусами.

Причина №4. Повреждение во время установки плагинов и модулей или после обновления CMS.

Причина №5. Повреждение в ходе экспериментов или неумелых действий (как раз мой случай).

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

Сохранение базы данных

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

Способ №1. Плагины WordPress

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

Плагин WordPress Database Backup. Умеет делать копию базы данных, в зависимости от настроек, сохраняя ее на сервере, сохраняя ее на компьютере или отправляя ее на e-mail, через указанный временной промежуток.

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

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

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

Способ №2. Ручное сохранение

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

Для ручного сохранения надо зайти на свой хостинг и перейти во вкладку — «Базы данных MySQL». Входим в phpMyAdmin и на панели слева выбираем название базы данных, с которой мы будем делать резервную копию:

На открывшейся странице с таблицами, выбираем вкладку «Экспорт»:

Далее нам предложат на выбор два варианта:

Если выбрать первый вариант «Быстрый — отображать минимум настроек», то файл резервной копии будет иметь расширение .sql

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

Вы пункте «Компрессия» выбираем расширение «zip», прокручиваем страницу в низ и нажимаем «Ок»:

После чего на компьютер скачается архив  — «ваша_база.sql.zip». Именно с архива, с расширением .sql.zip, при необходимости, проще всего будет произвести восстановление базы данных MySQL.

Как сделать резервную копию файлов сайта

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

Как скачивать файлы на домашний компьютер с помощью FTP клиента FileZilla, читайте здесь.

На панели управление хостинга должна быть вкладка «Файловый менеджер», в которой можно выбрать нужную папку с файлами:

Выделяем папку с файлами и нажимаем «Архиватор», после чего откроется меню:

Выбираем пункт «Запаковать и скачать» и на компьютер будет скачен архив с расширением .zip.

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

Восстановление базы данных MySQL из бэкапа

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

Для этого заходим в phpMyAdmin, выбираем название поврежденной базы данных и нам откроется страница с ее таблицами:

Выбираем пункт «Отметить все» и открываем меню, с перечислением возможных операций с отмеченными таблицами:

Выбираем «Удалить». После чего откроется страница, где надо будет подтвердить выбранное действие:

После, поврежденная база данных будет «безвозвратно» удалена. Мне до сих пор не дает покоя слово «Безвозвратно», какое-то слово не хорошее 🙂

Идем дальше. Если вы делали бэкап без архивации, т.е. сохраняли файл с расширением .sql, то для восстановления базы данных, надо будет произвести действия схожие с переносом базы данных с Денвера на сервер.

Открываем вкладку SQL , копируем содержимое файла «Ваша_база.sql» (именно содержимое, а не сам файл) и вставляем в поле:

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

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

Но не надо расстраиваться, просто запакуйте файл ваша_база.sql в архив и дайте ему название ваша_база.sql.zip и приступим к правильному восстановлению базы данных.

Открываем вкладку импорт, выбираем файл с расширением .sql.zip и нажимаем «ОК»:

После чего должно появиться сообщение:

Радуемся успешному восстановлению базы данных MySQL.

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

Я не сдался и нашел способ вернуть свою «безвозвратно утерянную» статью.

Что делать, если статья безвозвратно утеряна

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

В голове перебирались всевозможные варианты и вдруг я вспомнил о всемирном архиве Alexa, возможно Alexa Toolbar успел «сфотографировать» мою статью. Я полез во всемирный архив, но нет, там был сохранен только предыдущий пост. Жаль!

Так, какие еще могут быть варианты? Конечно! Вездесущий Гугл, возможно успел проиндексировать страницу.

На заметку! Чтобы выполнить поиск по кэшу Google, надо в адресную строку браузера вписать следующее: http://google.com/search?q=cache: После двоеточия указать URL искомого сайта или страницы.

В моем случаи запрос выглядел так:

Опять неудача! Даже бродяга Гугл ничего не успел узнать о моем свежеиспеченном посте. Ужасно жаль! Хотя по кэшу Гугла можно восстановить всю базу данных, но в моем случаи это не помогло.

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

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

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

Браузер! Ведь только он мог видел мою статью и наверняка где-то она хранится, остается только ее найти.

Я вбил в адресную строку браузера about:cache и мне открылся целый список сохраненных URL адресов, среди которых был адрес и моей «безвозвратно утерянной» статьи.

Я аж подпрыгнул на месте, но явилась мне совсем не то, что я ожидал. Вот отрывок страницы кэша:

Да уж, здесь без шифровальной машины не обойтись.

Точно! Надо найти файлы кэша на компьютере.

На заметку! Все файлы кэша браузера Google Chrome хранятся в C:\Users\Имя пользователя\AppData\Local\Google\Chrome\User Data\Default\Cache.

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

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

После недолгих поисков я остановился на программе ChromeCecheView. Специальная утилита для работы с кэшом Google. Скачать ее можно здесь. Там же можно скачать русификатор.

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

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

Воспользовавшись горячими клавишами CTRL + F, я открыл функцию поиска по утилите, куда вбил URL потерянной страницы:

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

Во вкладке «Файл» выбираю опцию «Открыть в браузере»:

И вот он — момент истины! Мне явилась моя «безвозвратно утерянная» статья, целехонькая, со всем изображениями и все что мне оставалось сделать — это скопировать ее и вставить в редактор WordPress.

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

До встречи!

С уважением, Виталий Кириллов