Восстановление баз данных sql. Восстановление отдельных страниц в базе данных. Как восстановить базу данных из бэкапа

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

Восстановление баз данных в SQL Server

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

SQL Server предоставляет множество возможностей для восстановления баз данных. Во-первых, это восстановление базы данных целиком - оно может занимать довольно много времени (зависит от размера БД и скорости жестких дисков). Во-вторых, восстановление отдельных файловых групп, либо файлов, если ваша БД состоит из нескольких файловых групп (или, соответствено, файлов). В этом случае, есть возможность восстановления только поврежденных частей БД, не затрагивая остальных. Эти два вида восстановления БД используются довольно часто и затрагиваться в дальнейшем не будут.
В-третьих, в SQL Server 2005 появилась возможность восстановления отдельных страниц БД - в этом случае из бэкапа будут восстановлены только указанные страницы. Такое восстановление будет особенно актуально, если DBCC CHECKDB найдет несколько поврежденных страниц в какой-нибудь огромной таблице, «лежащей» в здоровенном файле. За счет того, что восстанавливаться будет не весь файл, и даже не вся таблица, а только несколько страниц - время простоя может быть значительно сокращено.

Требования и ограничения

Модель восстановления и доступность резервных копий журнала транзакций

Самое главное, что нужно помнить - для восстановления отдельных страниц, база данных должна использовать полную (full) модель восстановления, либо модель восстановления с неполным протоколированием (bulk-logged). Если ваши базы находятся в простой (simple) модели восстановления - дальше вы можете уже и не читать.
Второе требование - ваши полные бэкапы и бэкапы журнала транзакций должны образовывать неразрывную цепочку журналов (log chain). Если вы никогда не выполняете команду BACKUP LOG WITH TRUNCATE_ONLY (NO_LOG) и не переключаетесь в простую модель восстановления для того, чтобы уменьшить журнал транзакций, и у вас есть ВСЕ резервные копии журнала транзакций с момента последней полной резервной копии не содержащей поврежденных страниц (включая эту самую полную резервную копию) - за цепочку журналов можно не волноваться.
В модели восстановления с неполным протоколированием, теоретически, восстановление отдельных страниц должно работать нормально в том случае, если соблюдаются условия описанные выше, и восстанавливаемые страницы не изменялись операциями, выполняемыми с минимальным протоколированием .

Редакции SQL Server

Восстановление страниц возможно в любой редакции SQL Server, но для редакций Enterprise Edition и Developer Edition возможно восстановление поврежденных страниц on-line, т.е. к базе данных, во время восстановления, можно обращаться (и более того, обращаться можно даже к той таблице, к которой относятся восстанавливаемые в данный момент страницы, если сами эти страницы не будут «затрагиваться» - в противном случае, запрос завершится ошибкой). Для редакций «ниже» Enterprise Edition, восстановление страниц проходит в режиме off-line и база данных, на время восстановления, становится недоступной.

Тип поврежденной страницы

В том случае если повреждены страницы индекса, либо данных, их восстановление возможно в режиме online в редакции Enterprise Edition.
Страницы, приндалежащие критически важным системным таблицам могут быть восстановлены, но база данных, при восстановлении, будет недоступна в любой редакции SQL Server.
«Карты размещения» не могут быть восстановлены «отдельно». Если повреждены GAM, SGAM, PFS, ML, DIFF-страницы, необходимо восстанавливать базу данных целиком. Единственным исключением являются IAM-страницы. Хотя они и относятся к «картам размещения», но они описывают только одну таблицу, а не всю базу данных, и их восстановление возможно.
Загрузочная страница базы данных (9-я страница в 1-м файле БД) и страница заголовка файла (0-я страница в каждом файле) не могут быть восстановлены «отдельно», при их повреждении придется восстанавливать БД целиком.

Собственно, восстановление

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

Портим БД

Для экспериментов я буду использовать базу данных AdventureWorks, которая поставляется вместе с SQL Server. Если вы не устанавливали ее, при желании, можно скачать . Перевожу ее в модель восстановления full:
ALTER DATABASE AdventureWorks SET RECOVERY FULL убеждаюсь, что ошибок в ней еще нет:
DBCC CHECKDB("AdventureWorks") WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY и создаю полный бэкап:
BACKUP DATABASE AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_full_ok1.bak"

В этой базе данных я создаю таблицу crash.
CREATE TABLE crash (txt varchar(1000)) Поле типа varchar мы и будем портить, для того, чтобы проверить что произойдет, если вдруг SQL Server обнаружит в нем не те данные, которые он сам туда записал.
Прежде чем что-то испортить, надо это чем-то заполнить. Я забиваю в созданную таблицу левые данные.
SET NOCOUNT ON DECLARE @i INT SET @i = 1 WHILE @i<100000 BEGIN INSERT INTO crash SELECT REPLICATE("a", 1000) SET @i = @i + 1 END SET NOCOUNT OFF Теперь делаю резервную копию журнала транзакций:
BACKUP LOG AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_log_ok1.trn"

Теперь немного изменим данные:

Итак, все готово. Отсоединяем БД и открываем mdf-файл FAR"ом (или чем вам удобнее), ищем в нем строку «zzzzzzz» и заменяем несколько "z" на произвольные символы:

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

Ищем ошибки

Итак, испорченная БД успешно вернулась в строй. Снова запустим проверку целостности:
DBCC CHECKDB("AdventureWorks") WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY В результате то, чего мы ждали (обязательно запоминайте номера поврежденных страниц! ):

Msg 8928, Level 16, State 1, Line 1
Object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data): Page (1:20455) could not be processed. See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data), page (1:20455). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 29493257 and -4.
CHECKDB found 0 allocation errors and 2 consistency errors in table "crash" (object ID 1883153754).
CHECKDB found 0 allocation errors and 2 consistency errors in database "AdventureWorks".
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (AdventureWorks).
В данном случае повреждены сами данные, находящиеся в куче (index id = 0), поэтому SQL Server эти данные восстановить не сможет.
Сейчас у нас есть три варианта:

Смириться с потерей данных и выполнить DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS)
Сделать бэкап активной части журнала транзакций и восстановить БД целиком - в результате потери данных не будет, но это займет продолжительное время
Сделать бэкап активной части журнала транзакций и восстановить только одну(!), поврежденную, страницу

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

Восстанавливаем поврежденную страницу

В первую очередь нам надо сделать бэкап заключительного фрагмента журнала транзакций (tail backup). При этом, если у вас Enterprise Edition, вы можете не добавлять параметр NORECOVERY, который переведет БД в состояние «restoring», поскольку эта редакция поддерживает on-line восстановление страниц. Более того, если у вас резервные копии журнала транзакций выполняются на регулярной основе, чтобы не нарушать цепочку журналов, в редакции Enterprise Edition, вы можете сделать COPY_ONLY бэкап.
Я же иду по пути off-line восстановления и выполняю:
BACKUP LOG AdventureWorks TO DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" WITH NORECOVERY

Теперь, можно восстанавливать поврежденную страницу. В первую очередь, используем полный бэкап (aw_full_ok1.bak):

RESTORE DATABASE AdventureWorks PAGE = "1:20455" FROM DISK = "D:\tmp\aw_backups\aw_full_ok1.bak" WITH NORECOVERY
В итоге, имеем:

Обратите внимание на то, что необходимо использовать опцию NORECOVERY, поскольку нам предстоит еще накатывать на нее бэкапы журнала транзакций.
RESTORE LOG AdventureWorks FROM DISK = "D:\tmp\aw_backups\aw_log_ok1.trn" WITH NORECOVERY и
RESTORE LOG AdventureWorks FROM DISK = "D:\tmp\aw_backups\aw_log_fail3.trn" WITH RECOVERY

Вроде бы все прошло успешно, запускаем DBCC CHECKDB и…

Восстановление прошло успешно.
Обратите внимание, что время простоя сокращается за счет того, что из полного бэкапа мы восстанавливаем не всю БД, а только поврежденные страницы (если бы я восстанавливал бэкап целиком - бэкап восстановился бы за 8,5 секунд, но, чем больше размер БД - тем больше будет разница во времени). Счастливчики с SQL Server Enterprise Edition, использующие on-line восстановление, так же сэкономят время на восстановлении из бэкапов лога, а при off-line восстановлении, увы, журналы будут обрабатываться целиком.
Стоит так же добавить, что в SQL Server 2005, 2008, 2008 R2 восстановление отдельной страницы возможно только с помощью T-SQL, в Denali появилась возможность делать это через GUI.

А если все-таки DBCC CHECKDB?

На всякий случай я решил проверить что сделает SQL Server, если я запущу DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Все та же ошибка:

Сначала переводим БД в режим SINGLE_USER:
ALTER DATABASE AdventureWorks SET SINGLE_USER А затем, запускаем восстановление:
DBCC CHECKDB("AdventureWorks", REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY В итоге:
Repair: The page (1:20455) has been deallocated from object ID 1883153754, index ID 0, partition ID 72057594054246400, alloc unit ID 72057594061651968 (type In-row data).
Ага, SQL Server удалил «испорченную» страницу. Переводим БД в режим MULTI_USER, чтобы она стала доступной для всех и проверяем что пропало:

Учитывая, что размер страницы в SQL Server 8КБ, а для пользовательских данных доступно чуть меньше - то все закономерно, таблица «похудела» на 7 записей (в начале их было 99999). Поскольку на этой таблице не было кластерного индекса, данные могли храниться в произвольном порядке, т.е. мы даже не могли узнать какие данные будут потеряны.

Так почему, все-таки, не перевод?

Итак, почему это все-таки не перевод, а пост «по мотивам». Дело в том, что, в открытом доступе статьи «Page Restore» за авторством Gail Shaw нет. Есть такой раздел в книге SQL Server MVP Deep Dives vol.2, которая продается за довольно-таки ощутимые деньги (но, естественно, легко находится в интернетах) и я не уверен, что публиковать перевод - это эм… правильно что ли.
В общем, я прочитал статью, взял на заметку основные моменты, а потом уже сам писал текст и, попутно, проводил эксперимент по восстановлению. Надеюсь, кому-нибудь этот опыт был полезен.
И, господа, я искренне надеюсь, что если вы решите повторять этот эксперимент, то будете предельно осторожны (например, не будете эксперементировать с основной БД на production-сервере). Помните, что никакой ответственности за ваши действия я не несу.

У разработчиков и администраторов Microsoft SQL Server достаточно часто возникает необходимость восстановить базу данных из архива (backup), например, для создания копии базы, которая будет использоваться для тестирования приложения, или например, Вы переустановили операционную систему и Вам нужно восстановить базу данных, именно этим мы сегодня и займемся.

В данной статье мы будем рассматривать восстановление базы данных на примере СУБД Microsoft SQL Server 2000 . Для того чтобы восстановить базу данных нужно, соответственно иметь архив этой базы данных. Он создается с расширением *.dat . Всем рекомендую создавать архивы своих баз данных, причем ежедневные, если что случится, у Вас всегда будет архив для восстановления.

Описание процесса восстановления базы данных из Backup

Начнем, открывайте Enterprise Manager выбирайте базу данных, которую Вы хотите восстановить или если Вы только что установили СУБД, и там нет еще баз данных, то просто создайте базу данных и восстанавливайте ее из архива. Открывайте меню «Tools->Restore Database » и у Вас откроется вот такое окошко:

Выбираем «From device » и жмем «Select Devices ».

{loadposition banner3

Жмите OK и в окне «Choose Restore Database » также нажмите OK. А в главном окне «Restore Database » пока не спешите нажимать OK, перейдите на вкладку «Options » и поставьте галочку как на картинке.

Также здесь задайте путь для файлов базы данных, так как он может быть неправильный, и Вы можете переписать, например, существующую базу данных, если Вы создаете копию базы, а если Вы только что все установили (СУБД), то можно и не менять.

Все, после этого можете нажимать OK. Через некоторое время база восстановится, и Вы ее можете использовать.

Кстати, если кому интересен язык T-SQL (это расширение языка SQL в Microsoft SQL Server ), то могу порекомендовать книгу «Путь программиста T-SQL. Самоучитель по языку Transact-SQL », после прочтения которой Вы легко сможете программировать на T-SQL.

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

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

Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. При ведении журнала придерживаются стратегии "упреждающей" записи, которая заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается данное условие, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

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

Поделюсь опытом как восстановить базу данных (БД) сайта из бэкапа через phpMyAdmin на вашем хостинге.

Данная вещь может ни разу вам не пригодиться, но на всякий случай должны понимать как действовать в критической ситуации. Как говорится: "Готовь сани летом...".

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

Как восстановить базу данных из бэкапа
На данный момент у вас уже есть бэкап БД на компьютере. Остается его залить в текущую БД с подменой, чтобы сайт снова начал работать, либо вступили в силу изменения, которые вы делали на локалке или другом сайте. Для этого необходимо попасть в phpMyAdmin у вас на хостинге. Покажу на примере своего (на других будет похоже в функциональной части).
Сам phpMyAdmin выглядеть у вас будет аналогично, быть может с небольшими отличиями.
Перехожу в соотв. раздел - правый верхний угол предыдущей картинки MYSQL
Напротив нужной БД (если у вас не одна, а несколько) нажимаю на надпись phpMyAdmin (картинка ниже)

Перед вами откроется вот такая страница, где необходимо кликнуть по названию своей БД:
Теперь у вас появится возможность восстановить сайт из бэкапа. Кликаете на "Импорт " в верхней панели:
По-умолчанию все сайты на WordPress идут в кодировке UTF-8, поэтому данную настройку трогать не нужно. Если же у вас сайт в другой кодировке, то подберите подходящую из выпадающего списка. Остальные оставляем как есть на странице.
После нажатия ОК запустится процесс восстановления сайта. Это можете занять несколько секунд или минут, в зависимости от размера БД.
Если в процессе возникнут проблемы с восстановлением, то в верхней части страницы появится соответствующая надпись с описанием ошибки. Здесь вам уже придется обратиться за помощью к хостеру, т.к. ошибки возникают чаще всего из-за настроек сервера (сюда не относится ситуация, когда у вас поврежден сам бэкап БД).
Из своей практики скажу, что чаще всего ошибка при восстановлении БД бывает из-за размера самого БД, когда сервер не может корректно обработать бэкап. В этом случае 2 пути выхода:
Распаковать архив с БД, чтобы получился просто файл.sql, либо наоборот запаковать (по ситуации).
Обратиться за помощью к тех.поддержке хостера.

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

От автора: добрый день, уважаемые. У вас что-то случилось? Опять «выкинули» не ту базу данных? Ну, это не смертельно, если знать все про восстановление MySQL. Сейчас мы расскажем вам все тонкости данного ритуала. Для этого нужен бубен, козявка из носа белохвостого тюленя… Это шутка! А все серьезное по этой теме будет изложено дальше.

Горе поправимо, если удалили базу

Без баз данных и систем управления ими (СУБД) в интернете никуда. Большая часть современных CMS и «самописных» движков, на которых развернуты сайты, используют MySQL. Поэтому ее можно смело назвать «всея интернетной» системой управления базами данных.

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

Быстрый способ восстановления

Чаще всего работа с БД в интернете происходит через phpMyAdmin, который является веб-интерфейсом для данной СУБД. Чтобы восстановить базу MySQL вручную:

Зайдите в phpMyAdmin и выберете нужную БД.

Перейдите по вкладке «Импорт», которая расположена в главном верхнем меню.

В разделе «Импортируемый файл» выберете источник резервной копии нужной базы.

Нажатие на кнопку «Ok».

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

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

Работа через MySQLdump

MySQLdump представляет собой веб-приложение, работающее на стороне сервера. Оно предназначено для восстановления баз MySQL из резервных копий, созданных с помощью приложения. Чтобы сильно «не зарываться», мы продемонстрируем создание простого бэкапа и восстановление из него БД. В качестве площадки для эксперимента используем самый популярный локальный сервер Рунета Denwer.

Для начала нужно скачать MySQLdump и поместить его по следующему адресу: F:\Webserver\usr\local\mysql-5.5\bin

MySQLdump является консольным приложением, поэтому вся последующая работа с ним будет происходить через командную строку (cmd.exe). Теперь поэтапно:

Запускаем Denwer.

Через командную строку заходим на виртуальный диск (в примере – это диск Z).

Заходим в папку, где «лежит» MySQLdump.

После этого запускаем утилиту на выполнение. Перед тем, как восстановить БД MySQL, в качестве примера создадим в папке bin резервную копию базы my_db1, и назовем бэкап «db1». Для этого мы используем команду mysqldump.

Теперь восстановим из созданной копии (db1) другую базу данных. Для этого используем команду mysql.

Код примеров использования обеих команд:

C:\Users\домашний>Z: Z:\>cd usr\local\mysql-5.5\bin Z:\usr\local\mysql-5.5\bin>mysqldump -uroot my_db1>db1.sql Z:\usr\local\mysql-5.5\bin>mysql -uroot db2

C : \ Users \ домашний> Z :

Z : \ > cd usr \ local \ mysql - 5.5 \ bin

Z : \ usr \ local \ mysql - 5.5 \ bin > mysqldump - uroot my_db1 > db1 . sql

Z : \ usr \ local \ mysql - 5.5 \ bin > mysql - uroot db2 < db1 . sql

Если немного присмотреться к коду, то можно заметить, что обе команды имеют общий синтаксис. Единственное, что их различает – это названия источников данных и копий. А также знак направления движения данных («<», «>»).

uroot – это имя пользователя. Оно указывается сразу после параметра u (без пробела). Кроме этого синтаксис команд включает еще несколько параметров. Среди них: пароль, адрес удаленного хоста. С помощью команды mysqldump можно экспортировать БД в различные форматы, сжимать данные. Также это проверенный способ, как можно восстановить таблицу MySQL.

Утилита MySQLdump (с помощью одноименной команды) позволяет экспортировать базы в простом текстовом формате (.txt). А так как текст обладает высокой степенью сжатия, то это эффективный способ уменьшения объемов бэкапов, в ситуации, когда наблюдается «дефицит» серверного пространства.

Что можно сделать еще

Кроме рассмотренных двух основных методов для восстановления данных MySQL можно использовать еще несколько консольных утилит:

MySQL-консоль

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

Также для популярных CMS разработано множество специализированных плагинов. Например, для WordPress:

Keep Backup Daily.

UpdraftPlus Backup and Restoration.

Perfect Dashboard.

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