SQL Server поддерживает три различных вида резервных копий – полную (full backup), дифференциальную (differential backup) и резервную копию журнала транзакций (transaction log backup). Первые два вида резервных копий доступны для баз данных в любой модели восстановления, резервная копия журнала транзакций – для баз данных в модели восстановления FULL и BULK-LOGGED (про модели восстановления вкратце вы можете прочитать , а лучше в BOL).
Если вы используете модель восстановления SIMPLE – вы сможете восстановить свою базу только из полного бэкапа (ну и накатить, дополнительно, дифференциальную копию). Вы никогда не восстановитесь на момент времени предшествующий сбою, только если вы не создали резервную копию непосредственно перед сбоем. Если ваша база данных находится в модели восстановления FULL и вы никогда не делаете бэкап журнала транзакций, но время от времени «обрезаете лог», прочитайте дальше – узнайте чего вы лишаетесь:).
Если вы это читаете, я полагаю, что ваша база находится в модели восстановления FULL, вы регулярно делаете полные резервные копии и копии журналов транзакций. Кроме того, ваша «цепочка восстановления» из резервных копий журнала транзакций должна быть неповрежденной.
Что такое «цепочка восстановления»? Это непрерывная последовательность резервных копий, состоящая из полного бэкапа и непрерывной последовательности резервных копий журнала транзакций. Например, в 12.30 вы создали полный бэкап (назовем его full1), а в 12.45, 13.00 и 13.15 создавали резервные копии журнала транзакций (trlog1, trlog2, trlog3, соответственно). До тех пор пока у вас есть все эти резервные копии, вы сможете восстановить свою базу данных на любой момент времени между 12.30 и 13.15, на 12.48, например.
Если вы удалите копию trlog2, созданную в 13.00, то резервная копия trlog3 (и все копии сделанные в дальнейшем) станет абсолютно бесполезной – восстановиться вы сможете на любой момент времени между 12.30 и 12.45. То же самое произойдет в случае, если кто-то создаст копию в 12.31 и удалит ее – все последующие копии станут бесполезны. Чтобы начать новую цепочку восстановления вам нужно будет сделать полную резервную копию и, затем, резервную копию журнала транзакций.
Во всем этом есть один не очень очевидный (по крайней мере, так было для меня) момент. Полная резервная копия всегда начинает, но никогда не прерывает цепочку восстановления (это справедливо для SQL Server 2005 и старше). Разберем это на примере. Вдобавок к уже имеющимся копиям (full1, trlog1, trlog2, trlog3 – непрерывная цепочка восстановления) сделаем в 13.30 полную резервную копию full2 и резервные копии журнала транзакций trlog3, trlog4, trlog5 в 13.45, 14.00 и 14.15, соответственно.
Теперь, если нам нужно восстановить базу данных на 14.15, проще всего использовать «новую» цепочку восстановления, т.е. восстановить full2 и «накатить» на нее последовательно trlog3, trlog4, trlog5. Но, если окажется, что из копии full2 мы не можем восстановиться (например, посыпался диск, содержащий эту копию), то мы можем воспользоваться нашей «первой» цепочкой восстановления – восстановить резервную копию full1 и последовательно накатить на нее копии журнала транзакций trlog1, trlog2, trlog3, trlog4, trlog5, trlog6. Точно также, мы можем использовать первую цепочку восстановления, для восстановления базы данных на 13.29 – восстанавливаем full1 и накатываем trlog1, trlog2, trlog3 и trlog4.
Таким образом, имея полную цепочку восстановления, мы можем восстановить нужную базу данных на любой момент времени между временем создания полной резервной копии и временем создания последней резервной копии. Небольшой хинт – если у вас полная модель восстановления, есть несколько резервных копий и ни одной копии журнала транзакций, но вы никогда не «обрезали» журнал транзакций – вы можете прямо сейчас создать эту резервную копию и получить возможность восстановления на любой момент времени между временем создания самой первой полной резервной копии и текущим моментом времени. Но, повторюсь, только в том случае, если резервные копии журнала транзакций раньше не создавались и журнал транзакций не обрезался.
Дальше я расскажу несколько способов использования резервных копий SQL Server.
Первый вариант (он работает для всех моделей восстановления) – необходимо восстановить базу данных из полной резервной копии
. Здесь все просто – необходимо выполнить T-SQL скрипт:
RESOTRE DATABASE [имя_базы_данных]
FROM DISK = "путь к полной резервной копии"
WITH REPLACE, RECOVERY, STATS = 10
Параметр REPLACE указывает на то, что если база данных с именем [имя_базы_данных] существует, то мы заменяем ее содержимое содержимым резервной копии. Если вы восстанавливаете базу данных с помощью GUI – нужно указать «Overwrite the existing database» на вкладке «Options».
RECOVERY говорит о том, что базу данных необходимо перевести в согласованное состояние и разрешить соединения пользователей. В GUI это соответствует опции «Leave the database ready to use by rolling back uncommitted transactions. Additional transaction logs cannot be restored.». Т.е., SQL Server откатывает все незафиксированные транзакции и позволяет пользователям работать с данными. После того как вы восстановили резервную копию с параметром RECOVERY, к ней нельзя применять дополнительно копии журналов транзакций и дифференциальные копии. Будьте внимательны, этот параметр устанавливается по умолчанию и если вы захотите «накатить» еще одну копию – процесс восстановления придется начать заново.
STATS = 10 отвечает за вывод информации о процессе восстановления. В данном случае, при восстановлении каждых 10 % резервной копии, на вкладке Messages в SSMS будет появляться сообщение. При восстановлении с помощью GUI вы не можете управлять этим параметром – за изменениями можно следить на «графике» в нижнем левом углу.
По умолчанию копия восстанавливается в то же самое место откуда она была сделана. Т.е. если изначально все файлы базы данных лежали в каталоге C:\Database, а вы хотите восстановить копию в другое место, то необходимо использовать параметр MOVE. Для использования MOVE вам необходимо знать логические имена файлов – их можно посмотреть с помощью представления sys.database_files. На рисунке показан пример использования этого представления.
Таким образом, чтобы восстановить базу данных AdventureWorks из резервной копии и одновременно перенести ее в другое место, можно воспользоваться следующим скриптом:
WITH REPLACE, RECOVERY, STATS = 10,
Если восстановление производится с помощью GUI, необходимо задать новые имена файлов на вкладке «Options» (таблица «Restore the database files as:», колонка «Restore As»).
Второй вариант – восстановление из полной резервной копии и всех резервных копий журнала транзакций (или дифференциальных копий).
Восстановление всегда начинается с восстановления полной резервной копии, но если вы хотите после этого восстанавливать какие-либо дополнительные копии, вам нужно оставить базу в состоянии RESTORING. Для этого воспользуемся следующим скриптом:
RESTORE DATABASE
FROM DISK = "D:\backup\awfull.bak"
WITH REPLACE, NORECOVERY, STATS = 10,
MOVE "AdventureWorks_Data" TO "D:\database\AW_data.mdf",
MOVE "AdventureWorks_Log" TO "D:\database\AW_log.ldf"
Если после выполнения восстановления вы попробуете обратиться к базе – получите ошибку:
Database "AdventureWorks" cannot be opened. It is in the middle of a restore.
После восстановления полной резервной копии восстанавливаем последнюю дифференциальную копию (если есть):
RESTORE DATABASE
FROM DISK = "D:\backup\awDIFF.bak"
WITH NORECOVERY, STATS = 10
На этом, если у вас модель SIMPLE, вы можете остановиться – больше вы ничего не сделаете. Если у вас модель FULL, вы можете дополнительно накатить резервные копии журнала транзакций :
RESTORE LOG
FROM DISK = "D:\backup\awlog1.trn"
WITH NORECOVERY
….
RESTORE LOG
FROM DISK = "D:\backup\awlog12.trn"
WITH RECOVERY
Обратите внимание, последняя копия должна быть восстановлена с параметром RECOVERY. Если база данных осталась в состоянии RESTORING, ее можно привести в работоспособное состояние и без резервных копий:
RESTORE DATABASE
WITH RECOVERY
После этого база данных «вернется к жизни».
Третий вариант – восстановление на момент времени
. У меня есть база данных AdventureWorks, ее полная резервная копия и резервная копия журнала транзакций, сделанная ранее. Результат выполнения запроса
SELECT *
FROM Person.AddressType
представлен на рисунке:
В 13.46 эта таблица была удалена. Тот же самый запрос теперь возвращает:
Invalid object name "Person.AddressType"
Чтобы вернуть все на свои места, в первую очередь делаем резервную копию журнала транзакций:
BACKUP LOG
TO DISK = "D:\backup\awlog2.trn"
После того как копия создана, восстанавливаем полную резервную копию и первую резервную копию журнала транзакций (обе с параметром NORECOVERY).
Теперь восстановим последнюю резервную копию, созданную ПОСЛЕ удаления таблицы:
RESTORE LOG
WITH RECOVERY, STOPAT = "09/10/2010 13:45"
(дата здесь задается в формате "ММ/ДД/ГГГГ ЧЧ:ММ")
После этого исходный запрос возвращает нормальный результат, таблица восстановилась.
Еще один вариант восстановления данных. История из жизни
:).
Несколько месяцев назад попали в не очень приятную ситуацию – записи в одном из регистров сведений (периодическом, не подчиненном регистратору) были «испорчены». То есть они как бы остались, но свой смысл потеряли. Регистр был большим и нужным. Ошибка произошла несколько часов назад, так что полностью восстанавливать базу данных было нельзя. Собирались переносить данные с помощью обработки ВыгрузкаЗагрузкаДанныхXML, но программисты попросили попробовать перенести данные средствами SQL, в надежде, что это будет быстрее.
Мы восстановили из бэкапов копию базы на момент времени предшествующий порче данных. С помощью функции «ПолучитьСтруктуруХраненияБазыДанных» узнали имя регистра сведений в базе данных - _InfoReg4452 (например, точно я уже не помню). Очистили в основной базе этот «испорченный» регистр с помощью TRUNCATE TABLE _InfoReg4452.
На копии базы выбрали TASKS -> ExportData, в качестве источника указали копию с нормальным регистром, в качестве приемника рабочий сервер и рабочую базу (с очищенным регистром). На странице выбора объектов выбрали только одну – нужную нам таблицу:
Еще два клика мышью и все. Таблица перенеслась, люди продолжили работу.
Хочу обратить внимание на несколько нюансов. Во-первых, если не очищать таблицу-приемник, все данные в ней останутся, а новые могут и не появиться. Во-вторых, такой метод может подойти для некоторых регистров сведений и справочников, но для таблиц по которым делаются движения, или объектов, совершающих движения, придется восстанавливать множество дополнительных таблиц – 100 раз подумайте, прежде чем применять этот метод. Ну и вообще этот метод идет в разрез с лицензионным соглашением, но он быстр и удобен в некоторых случаях.
Надеюсь эта информация была хоть кому-нибудь полезной.
P.S. Не верьте мне на слово - попробуйте все это сделать на своих копиях!
От автора: добрый день, уважаемые. У вас что-то случилось? Опять «выкинули» не ту базу данных? Ну, это не смертельно, если знать все про восстановление 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, рекомендую пройти Вам наш . Сегодня в уроке: MySQL.
(MySQL - система свободного управления базами данных). Восстановить базу данных достаточно просто, но для этого нужно иметь резервную копию базы. Когда у меня появились проблемы с базой, то я не мог зайти на сайт, и все мои статьи пропали. Пришлось срочно решать, как восстановить базу данных Wordprerss. Такая ситуация у меня произошла пару дней назад, когда я писал 59 урок. Мне буквально через несколько минут пришло СМС от Яндекс-Метрики, что мой сайт не доступен. Если Вы с такой проблемой раньше сталкивались, то знаете как все вернуть в рабочее состояние, а если нет - читайте далее. В Интернете в основном пишут, как сделать резервную копию базы данных, но мало кто пишет, как восстановить базу данных WordPress
. Не обязательно, что с базой данных
могут возникнуть проблемы по Вашей вине. В базе могут возникнуть ошибки и по другим причинам. Если на Вашем блоге еще не установлен плагин , или ему подобный, то Вы рискуете остаться без блога. Представьте, Вы ведете блог долгое время, а потом раз, и все! Амба! Этот плагин не позволит случится такому. Он сохраняет базу данных Вашего блога постоянно в автоматическом режиме и без Вашего участия. Информации по восстановлению базы данных много в Интернете, но, бывает такую ерунду пишут, за которую люди еще и благодарят. Автор статьи дает советы, как правильно делать то и то, но сам даже не понимает, о чем пишет. Все, пора перейти к делу 🙂 Чтобы вернуть блог в прежнее состояние, у Вас должна быть свежая резервная копия базы данных. Распакуйте файл базы и откройте распакованный файл в блокноте Windows. Скопируйте содержимое фала в . Перейдите в панели управления на Вашем хостинге в PhpMyAdmin. Щелкните по названию базы данных, которую хотите восснановить. Потом нужно щелкнуть по "SQL
" и вставьте в окошко то, что скопировали с файла базы данных, нажав "CTRL
" + "V
". Нажмите потом "ОК
". Подождав пока закончится восстановление базы данных. Должна появится надпись об успешном выполнении. Теперь Ваш блог полностью восстановлен. Итак, без лишних вступлений. Переходите на Вашем хостинге в контрольную панель (cPanel). Найдите ссылку «MySQL
» или «PhpMyAdmin
». Теперь нужно осуществить вход в панель управление базами данных, т. е. в PhpMyAdmin. Нажимаем «Войти
» Вы попадете в PhpMyAdmin. Слева щелкните по базе, которую собираетесь восстановить. В моем случае это база dvpress. После того, как выберите базу, появятся все таблицы этой базы данных. Чтобы во время восстановления, не возникало никаких ошибок, надо эту базу полностью удалить. Опускаемся в самый низ и находим «Отметить все / Снять выделение
». Нажимаете на «Отметить все
», чтобы все таблицах базы стояли галочки в чекбоксе. Выбираем в окошке правее «Удалить
», а потом подтвердите "Да
". База данных должна полностью очиститься от всех таблиц. Теперь Ваша задача восстановить эту базу из резервной копии. Жмите вверху «Импорт
», потом щелкайте по кнопке «Выберите файл
». Найдите на своем компьютере резервную копию базы и нажмите «Открыть
». Теперь в PhpMyAdmin внизу нажмите «Ок
». Операция должна пройти успешно, о чем должна оповестить надпись «SQL запрос успешно выполнен
». Вам необходимо научиться восстанавливать данные из
резервной копии. Восстановление может понадобиться в случае сбоя в работе оборудования или при необходимости
создания на другом сервере абсолютно идентичной копии существующей базы данных. Запомните, если Вы восстанавливаете базу, используя Simple Recovery Model, Вам нужно будет восстановить
только последнюю полную копию. Если же Вы используете Full или Bulk Recovery Model , Вы должны восстановить полную
копию, затем последнюю дифференциальную копию и все копии журналов транзакций. Изучим подробнее процессы
восстановления.
Восстановление базы данных из полной копии.
Независимо от модели восстановления, первым шагом всегда является восстановление последней полной резервной копии.
Для восстановления БД в Enterprise Manager, следует выделить базу данных, дважды щелкнуть по ней правой кнопкой
мыши и выбрать в контекстном меню “All Tasks > Restore Database”, после этого откроется диалоговое окно,
показанное на Рисунке A. Рисунок А. Диалоговое окно Restore Database позволяет просматривать все последние резервные копии в хронологическом порядке.
Там же Вы можете выбрать базу данных, которую нужно восстановить. На вкладке Options показанной на Рисунке B,
Вы можете выбрать сделующие опции: Рисунок B. В нижней части окна находятся три переключателя, которые позволяют определить состояние базы после восстановления
копии: Для восстановления базы данных и журналов транзакций осталось просто нажать кнопку OK.
Восстановление базы данных с помощью T-SQL.
Восстановление базы данных можно выполнить и с помощью T-SQL, который предлагает больше опций чем Enterprise
Manager. Синтакс использования T-SQL команды следующий: RESTORE DATABASE { database_name
| @
database_name_var
} Для детального изучения каждой опции следует прочитать описание в SQL Server 2000 Books Online . На Рисунке C показано восстановление базы данных Pubs из полной копии с устройства резервного копирования. Рисунок С.
Восстановление базы данных из дифференциальной копии.
Если Вы используете Full или Bulk Recovery Model, Вы должны выполнить сначала восстановление полной резервной
копии, затем последней дифференциальной копии и всех журналов транзакций. Для выполнения восстановления базы
данных, используя дифференциальную копию, в Enterprise Manager необходимо выделить базу данных, дважды щелкнуть
по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, выбрать восстановления
полной и дифференциальной копии базы данных, а затем нажать OK. (исунок D) Рисунок D. Синтаксис команды Restore для выполнения восстановления с использованием дифференциальных копий, показан на
Рисунке Е. Рисунок Е.
Восстановление журнала транзакций.
Перед началом восстановления журнала транзакций, Вы должны восстановить полную и последнюю дифференциальную
копию базы. Затем Вы можете восстанавливать журналы транзакций в соответсвующем порядке. Если Вы используете
Enterprise Manager, нужно выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном
меню “All Tasks > Restore Database”, выбрать все нужные копии и, если есть необходимость, опцию Point in Time
Restore (восстановление на определенный момент времени) (Рисунок F). Рисунок F. Синтаксис команды Restore для восстановления журнала транзакций, показан на РисункеG. Рисунок G. Подведем итоги. Резервное копирование и восстановление базы данных – это одна из основных, наиболее важных
задач администратора баз данных. В любой момент времени Вы должны быть уверены в своей способности восстановить
базу данных SQL Server 2000 согласно Вашему плану аварийного восстановления. Если же у Вас нет плана аварийного
восстановления, я рекомендую начать работать над ним. В случае, если что-то произойдет и данные будут
потеряны, следующей потерей для Вас может стать потеря места работы.
Что можно сделать еще
Как восстановить базу данных WordPress (способ 1)
Как быстро восстановить базу данных WordPress (способ 2)
[ FROM < backup_device > [ ,
...n
] ]
[ WITH
[ RESTRICTED_USER ]
[ [ ,
] FILE =
{ file_number
| @
file_number
} ]
[ [ ,
] PASSWORD=
{ password
| @
password_variable
} ]
[ [ ,
] MEDIANAME=
{ media_name
| @
media_name_variable
} ]
[ [ ,
] MEDIAPASSWORD=
{ mediapassword
| @
mediapassword_variable
} ]
[ [ ,
] MOVE "
logical_file_name
"
TO "
operating_system_file_name
"
]
[ ,
...n
]
[ [ ,
] KEEP_REPLICATION ]
[ [ ,
] { NORECOVERY | RECOVERY | STANDBY =
undo_file_name
} ]
[ [ ,
] { NOREWIND | REWIND } ]
[ [ ,
] { NOUNLOAD | UNLOAD } ]
[ [ ,
] REPLACE ]
[ [ ,
] RESTART ]
[ [ ,
] STATS [ =
percentage
] ]
