Sql восстановление из копии. Описание процесса восстановления базы данных из Backup. Восстановление баз данных в SQL Server

У разработчиков и администраторов 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.

Читайте, как восстановить утерянную или удалённую базу MySQL . Как восстановить повреждённые таблицы базы MySQL с помощью myisamchk. База данных MySQL по умолчанию устанавливается на компьютере в папку не диске С:

C:\Program Files\MySQL\MySQL Server 5.7

Но, данные таблиц хранятся в файлах в другой папке на диске С компьютера, это:

Расположение данных файлов указано в меню Server Status приложения MySQL Workbench, в разделе Server Directories.

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

Содержание:

Файлы базы данных MySQL

MySQL совместима с большим количеством форматов файлов, как например: .sql, .arm, .cnf, .dbs, .ddl, .frm, .ibd, .ism, .mrg, .myd, .myi, .mysql, .opt, .phl, .sal, .sqr, .tmd, .arz, .ibz, .ibc, .qbquery, .rul. Но данная статья не об этом. Сегодня нам интересны именно те файлы, в которых хранятся данные и таблицы базы, восстановив которые пользователь будет иметь возможность вернуть важную информацию и избежать её возможной утери в будущем.

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

db.opt – файл в котором хранятся характеристики базы данных, указанные при её создании;
.frm – файл структуры таблиц;
.myd – файл, в котором хранятся данные MyISAM таблиц;
.myi – файл, в котором хранятся индексы MyISAM таблиц;
.ibd – файл, в котором хранятся данные и индексы InnoDB таблиц.

Как восстановить базу данных MySQL

Восстановление базы данных MySQL это технически не сложный процесс, но он зависит от множества условий. Для пользователей MySQL Workbench предусмотрена функция Экспорта и Импорта/Восстановления данных баз данных.

Кроме этого, возможно создание резервной копии и восстановление базы данных MySQL с помощью mysqldump (которую мы детально описали в одной из наших статей).

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

Создание копии данных таблиц базы MySQL возможно путём копирования файлов структуры и данных (*.opt, *.frm, *.myd, *.myi для MyIsam; *.opt, *.frm, *.ibd для InnoDB) и сохранения их в другой папке.
Восстановление данных таблиц базы MySQL возможно путём подстановки скопированных раннее файлов структуры и данных в папки уже существующих баз (в нашем случае это две базы: my_db и my_db2).

Восстановление утерянной или удалённой базы MySQL

Так, если по какой-то причине вы удалили базу данных MySQL, переустановили Windows или отформатировали жесткий диск, то восстановить её можно описанным выше способом, путём подставки скопированных раннее файлов базы данных в папку с названием базы:

C:\ProgramData\MySQL\MySQL Server 5.7\Data

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

Для этого:

Восстановление повреждённых таблиц базы MySQL с помощью myisamchk

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

В результате повреждения из таблицы могут исчезнуть или неправильно отображаться данные, но чаще всего в результате повреждения таблицы пользователи сталкиваются с ошибкой: «Incorrect key file for table: ‘название_таблицы’. Try to repair it»

Для восстановления повреждённых MyISAM таблиц можно использовать команду myisamchk .

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

Так, чтобы восстановить повреждённую таблицу, используйте команду:

myisamchk -r -q ИМЯ_ТАБЛИЦЫ

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

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

myisamchk -r ИМЯ_ТАБЛИЦЫ

где, -r – это просто режим восстановления. В таком случае из файла данных будут удалены некорректные и утерянные записи, и индексный файл будет создан заново (как описано выше).

Обратите внимание . Если отладку и восстановление таблицы планируется выполнять из командной строки, то предварительно необходимо остановить сервер. Следует отметить, что при выполнении mysqladmin shutdown с удаленного сервера mysqld все еще будет некоторое время работать после завершения mysqladmin, пока не будут остановлены все запросы и сброшены на диск все ключи.

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

Восстановление баз данных в 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-сервере). Помните, что никакой ответственности за ваши действия я не несу.

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. Не верьте мне на слово - попробуйте все это сделать на своих копиях!

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

Запомните, если Вы восстанавливаете базу, используя Simple Recovery Model, Вам нужно будет восстановить только последнюю полную копию. Если же Вы используете Full или Bulk Recovery Model , Вы должны восстановить полную копию, затем последнюю дифференциальную копию и все копии журналов транзакций. Изучим подробнее процессы восстановления.

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

Независимо от модели восстановления, первым шагом всегда является восстановление последней полной резервной копии. Для восстановления БД в Enterprise Manager, следует выделить базу данных, дважды щелкнуть по ней правой кнопкой мыши и выбрать в контекстном меню “All Tasks > Restore Database”, после этого откроется диалоговое окно, показанное на Рисунке A.

Рисунок А.

Диалоговое окно Restore Database позволяет просматривать все последние резервные копии в хронологическом порядке. Там же Вы можете выбрать базу данных, которую нужно восстановить. На вкладке Options показанной на Рисунке B, Вы можете выбрать сделующие опции:

Eject tapes after restoring each backup (выгружать ленту после каждого восстановления)
Prompt befor restoring each backup (выдавать дополнительное предупреждение перед началом восстановления каждой копии)
Force restore over existing database (осуществлять восстановление поверх существующей базы данных), эта опция эквивалентна Move в T-SQL.

Рисунок B.

В нижней части окна находятся три переключателя, которые позволяют определить состояние базы после восстановления копии:

Leave Database Operational. No Additional Transaction Logs Can Be Restored.
- Если Вы выбрали это значение, то после загрузки резервной копии будет инициирован процесс восстановления, что приведет к откату всех незавершенных транзакций. Станет невозможной загрузка дополнительных копий журнала транзакций. Пользователи получат возможность нормально работать с базой данных.
Leave Database Nonoperational But Able To Restore Additional Transaction Logs.
- По окончании загрузки копии база данных будет оставаться временно недоступной. Будет необходимо загрузить дополнительные копии, после чего инициировать процесс восстановления.
Leave Database Read-Only And Able To Restore Additional Transaction Logs.
- База данных становится доступной только для чтения. Вы можете загрузить дополнительные резервные копии журнала транзакций. Эта опция используется для создания резервного сервера (Standby Server)

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

Восстановление базы данных с помощью T-SQL.

Восстановление базы данных можно выполнить и с помощью T-SQL, который предлагает больше опций чем Enterprise Manager. Синтакс использования T-SQL команды следующий:

RESTORE DATABASE { database_name | @ database_name_var }
[ 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 ] ]

Для детального изучения каждой опции следует прочитать описание в 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 согласно Вашему плану аварийного восстановления. Если же у Вас нет плана аварийного восстановления, я рекомендую начать работать над ним. В случае, если что-то произойдет и данные будут потеряны, следующей потерей для Вас может стать потеря места работы.