ms sql скрипт восстановления базы
Восстановление резервной копии базы данных в простой модели восстановления (Transact-SQL)
Этот раздел содержит сведения о восстановлении полной резервной копии базы данных.
При восстановлении базы данных из полной резервной копии системный администратор должен быть единственным пользователем, работающим с базой данных.
Предварительные требования и рекомендации
Чтобы восстановить зашифрованную базу данных, необходимо иметь доступ к сертификату или асимметричному ключу, который использовался для шифрования базы данных. Без сертификата или асимметричного ключа восстановить базу данных нельзя. Поэтому сертификат, используемый для шифрования ключа шифрования базы данных, должен храниться в течение всего времени, пока есть необходимость в резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.
В целях безопасности рекомендуется не присоединять и не восстанавливать базы данных, полученные из неизвестных или ненадежных источников. В этих базах данных может содержаться вредоносный код, вызывающий выполнение непредусмотренных инструкций Transact-SQL или появление ошибок из-за изменения схемы или физической структуры базы данных. Перед тем как использовать базу данных, полученную из неизвестного или ненадежного источника, выполните на тестовом сервере инструкцию DBCC CHECKDB для этой базы данных, а также изучите исходный код в базе данных, например хранимые процедуры и другой пользовательский код.
Уровень совместимости баз данных после обновления
Если уровень совместимости пользовательской базы данных до обновления был 100 или выше, после обновления он останется таким же. Если уровень совместимости до обновления был 90, в обновленной базе данных он устанавливается в значение 100, что является минимально поддерживаемым уровнем совместимости в SQL Server 2019 (15.x).
Процедуры
Восстановление полной резервной копии базы данных
Для восстановления полной резервной копии базы данных выполните инструкцию RESTORE DATABASE, указав:
Имя базы данных для восстановления.
устройство резервного копирования, с которого происходит восстановление полной резервной копии базы данных;
предложение NORECOVERY при наличии журнала транзакций или разностной резервной копии, которые необходимо применить после восстановления полной резервной копии.
Чтобы восстановить зашифрованную базу данных, необходимо иметь доступ к сертификату или асимметричному ключу, который использовался для шифрования базы данных. Без сертификата или асимметричного ключа восстановить базу данных нельзя. Поэтому сертификат, используемый для шифрования ключа шифрования базы данных, должен храниться в течение всего времени, пока есть необходимость в резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.
Дополнительно можно указать следующее.
Пример
Описание
В следующем примере восстанавливается полная резервная копия базы AdventureWorks2012 с магнитной ленты.
Автоматизированное восстановление баз данных MS SQL из бэкапов
В этой статье я хотел бы рассказать о том, как с помощью утилиты Quick Maintenance & Backup for MS SQL настроить автоматическое восстановление баз данных из бэкапов на тестовом экземпляре SQL Server в сети. При этом создавать бэкапы будет штатный План обслуживания. Потребность в автоматизированном восстановлении может возникнуть в следующих случаях:
Задача
Итак, допустим имеется рабочий SQL Server (Srv01) на котором развернуты несколько баз данных с Полной моделью восстановления. На сервере создан План обслуживания с произвольной стратегией резервного копирования. В моем случае это:
Полный бэкап – каждую неделю 24.00 в воскресенье
Разностный бэкап – каждую ночь в 24.00 кроме воскресенья
Бэкап лога – каждый день с 9.00 до 23.59 через каждые 1 час
Бэкапы создаются в папке F:\MS SQL\Backup. При этом для каждой базы агент SQL Server создает отдельные подпапки.
Задача: каждый день в 23:00 на резервном SQL Server (London) выполнять восстановление баз данных на последнее возможное состояние из бэкапов созданных на Srv01. Оба сервера находятся в единой локальной сети. После восстановления каждой базы данных необходимо проверить её целостность (DBCC CHECKDB). Таким образом, каждый вечер кроме воскресенья, будет выполняться восстановление из Полного бэкапа, разностного и журналов транзакций, созданных в течении дня. В понедельник восстановление будет проводится из Полного бэкапа и журналов транзакций, созданных в течении понедельника. Если по каким-то причинам восстановление не выполнится администратору должно прийти email-уведомление.
Понятно, что для того чтобы тестовый SQL Server (London) смог выполнить восстановление он должен иметь доступ к файлам бэкапов. Тут возможны два варианта:
Общий порядок действий
Итак, нам потребуется проделать следующие шаги:
Утилиту можно скачать тут. Пробный период — 30 дней.
Я поставил утилиту на тестовом сервере London. В общем случае программу можно установить на любом компьютере, работающем круглосуточно т.е. установка именно на SQL Server не обязательна. При установке программы оставляем все параметры по умолчанию. Инсталлятор установит службу QmbService и клиента.
Регистрация SQL Server и настройка уведомлений
При первом старте программы откроется мастер. Перейдем на следующий шаг и установим галку «Включить email-оповещения» и введем адрес электронной почты для получения уведомлений.
Для отправки уведомлений рекомендуется настраивать собственную учетную запись SMTP, но для простоты мы будем использовать встроенную. Далее введем имя SQL Server и учетную запись для подключения к SQL Server. Необходимо указать учетную запись имеющую привилегии sysadmin (по умолчанию sa).
На следующем шаге программа отобразит версию сервера, лицензию и признак сжатия резервных копий. Все параметры оставляем по умолчанию и нажимаем кнопку «Вперед».
В следующем окне можно настроить слежение за свободным местом на дисках. Если в этом нет необходимости, то снимите все чекбоксы с дисков.
Жмем кнопку «Вперед».
Нам не требуется обслуживать базы данных поэтому на последней странице мы выберем «Создать пустой автономный сценарий». Затем снимем галку «Создать автономный сценарий для обслуживания системных баз данных» и нажмем кнопку «Завершить».
Программа зарегистрирует SQL Server и откроет форму нового пустого сценария.
Создание XML-плана восстановления
Любые задачи в программе исполняются в рамках сценариев. В окне нового автономного сценария ведем его имя Создание XML плана восстановления.
Добавим в сценарий задачу, которая будет создавать XML файл плана восстановления. Нажмем кнопку «Добавить». Откроется форма выбора задачи. Кликнем кнопку «Добавить новую задачу». Откроется форма новой задачи.
Примечание: Для сети без домена имя пользователя необходимо указывать в формате: Компьютер\Пользователь
Обратите внимание на признак «Копировать недостающие файлы архивных копий в общую папку». Благодаря этой опции программа автоматически скопирует недостающие файлы бэкапов с локального диска SQL Server в сетевую папку. При этом, путь к файлу источнику программа определит самостоятельно по информации о созданных резервных копиях, которую SQL Server хранит в системной базе msdb.
Нажмем кнопку Принять и выберем созданную задачу в сценарий. На форме сценария установим флаг «Запуск сценария по расписанию» и укажем расписание: Каждый день, через 1 час начиная с 9:30 до 22:30. Напомню, что План обслуживания создает бэкап лога каждый час с 9:00 до 23:59. Таким образом QMB будет обновлять XML план восстановления со сдвигом в 30 минут (9:30, 10:30, 11:30 и т.д). Нужно отметить, что если бы бэкапы создавались Политикой обслуживания QMB, то XML файл плана восстановления обновлялся бы автоматически.
Сценарий должен выглядеть как на рисунке ниже.
Теперь проверим сценарий. Для этого нажмем кнопку «Выполнить». Если все настроено верно, то в сетевую папку будут скопированы файлы резервных копий и создан файл RestorationPlan.xml. Если в ходе работы программа не найдет нужных файлов резервных копий, то задача завершится ошибкой. Таким образом мы заранее узнаем о потенциальных проблемах. Например, довольно часто, администраторы для передачи базы данных создают её полный бэкап (без параметра COPY_ONLY), а после передачи сразу удаляют его чтобы он не занимал место. Однако при этом рвется цепочка резервных копий и восстановление на актуальный момент времени становится невозможно. Программа выявит эту проблему ещё на этапе создания XML плана восстановления.
Сохраним сценарий. Теперь QMB через каждый час будет пересоздавать XML файл плана восстановления и копировать новые файлы бэкапов, которые создает штатный агент SQL Server.
Нужно отметить, что задача по созданию XML плана копирует файлы, необходимые только для восстановления на последний возможный момент времени. При этом файлы копируются без папок т.е. все файлы будут размещены в указанной сетевой папке. В программе существует возможность настроить копирование подпапок, а даже удаление устаревших файлов в сетевой папке. Это можно сделать через пользовательскую задачу, содержащую CMD скрипт или используя Политику обслуживания QMB.
Восстановление на тестовом сервере
Восстановление по XML плану выполняется аналогично, с помощью специальной задачи, размещенной в сценарии. Однако восстановление должно выполняться на тестовом SQL Server (London), поэтому этот сервер тоже необходимо зарегистрировать в программе. Для этого в древовидном списке слева нажмем кнопку «Зарегистрировать сервер». Процедура регистрации сервера полностью аналогична описанной ранее.
После регистрации сервера откроется окно автономного сценария. Введем наименование Восстановление по XML плану с Srv01 и укажем его расписание: Каждый день в 23:00.
Теперь из формы сценария добавим новую задачу, аналогично тому как мы создавали задачу для создания XML плана. Однако, теперь в поле тип укажем Восстановление по XML плану, выберем ранее созданное подключение к сетевой папке и укажем имя XML файла. Переключатель База источник определяет какие именно базы данных XML плана восстановления необходимо восстанавливать.
База данных в которую будет выполнено восстановление определяется одноименным переключателем. В нашем случае я буду восстанавливать в одноименные базы данных. Это значит, что на SQL Server будут созданы/перезаписаны базы данных имеющие аналогичные имена (в моем случае это три базы: Account2013, Account2014, Account2015). Таким образом эти базы будут актуализироваться до последнего состояния.
Режим Восстанавливать во временную базу данных следует выбирать, если восстановление выполняется с целью проверки файлов резервных копий и процедуры восстановления. В этом режиме QMB создаст временную базу с наименованием qmbTempRestoreDb[Случайный индекс], которая будет удалена после восстановления и проверки её целостности.
Сохраняем задачу и выбираем её в нашем сценарии.
Чтобы убедиться, что восстановление пройдет успешно выполним сценарий в ручном режиме. Программа последовательно восстановит каждую базу данных и выполнит тестирование её целостности. В зависимости от размеров баз данных процедура может занимать значительное время.
Сохраним сценарий. Теперь каждый день в 23:00 программа будет автоматически восстанавливать базы данных и в случае сбоя отправлять уведомления на Email.
Кроме этого, используя XML файл плана восстановления, администратор с помощью программы может вручную, в несколько кликов, восстанавливать базы данных на других SQL Server.
Скрипт удобного восстановления базы MSSQL при дифференциальном резервировании
Для начала немного истории.
Так сложилось, что в моей компании резервированием баз 1С, которые у нас лежат на MSSQL, занимаюсь лично я. Вначале, пока база еще не так сильно разрослась, все было просто: каждую ночь выгружался dt-файл. Этот путь не понравился по 3-м причинам: долго восстанавливается, при бекапе в базе не должно быть пользователей, на диске временного каталога должно быть место, расное файлу бекапа.
Время шло, база росла, было решено делать бекап базы MSSQL. Но банный файл оказался гораздо больше файла dt. Пришлось засесть за интернет и узнать как реализовать и потом реализовать на практике разностный бекап. Но так как у нас есть команда программистов, то для каждого программиста выделили еще и по паре тестовых баз.
Через некоторое время мне надоело заниматься копипастом постоянно изменяя в скрипте имя базы и добавляя блоки для каждого файла разностного бекапа в итоге было потрачено немного времени и получился следующий скрипт:
—Здесь ничего не трогаем
declare @SQLString nvarchar(4000), @TableName nvarchar(16)
declare @t table (fname NVARCHAR(50))
DECLARE @counter INT, @backupfile NVARCHAR(50)
SET @counter = 0
—————————————————————————
— Здесь изменяем имя базы
set @TableName = N’Ins_3_3′
— Здесь вставляем необходимое количество бекапов.
— Вначале полный, потом все разностные
INSERT INTO @t (fname) VALUES (‘2011-01-16_ins.bak’)
INSERT INTO @t (fname) VALUES (‘2011-01-17_ins_diff.bak’)
INSERT INTO @t (fname) VALUES (‘2011-01-18_ins_diff.bak’)
OPEN bkf;
FETCH bkf INTO @backupfile;
WHILE @@FETCH_STATUS=0
BEGIN
IF @counter = 0
BEGIN
set @SQLString = N’restore Database ‘ + @TableName + ‘
FROM DISK = N»N:\Backup1C\’ + @backupfile + »’
with NORECOVERY,
move »Ins81» to N»F:\SQLBases\Data\’ + @TableName + ‘.mdf»,
move »Ins81_log» to N»F:\SQLBases\Data\’ + @TableName + ‘_Log.ldf»,
STATS = 5′
END
ELSE
BEGIN
set @SQLString = N’restore Database ‘ + @TableName + ‘
FROM DISK = N»N:\Backup1C\’ + @backupfile + »’
with NORECOVERY’
END
exec sp_executesql @SQLString
set @counter = @counter + 1
FETCH bkf INTO @backupfile;
END;
CLOSE bkf;
DEALLOCATE bkf;
set @SQLString = N’restore Database ‘ + @TableName + ‘
with RECOVERY’
exec sp_executesql @SQLString
Надеюсь, скрипт будет полезным.
Новая база будет создаваться по пути F:\SQLBases\Data\. Исправьте путь согласно своему серверу.
Бекапы у меня лежать в N:\Backup1C\. Естественно этот путь нужно тоже поменять.
Восстанавливаем базу данных SQL Server из режима “suspect”
В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса.
Автор: Waqas, журналист в сфере информационной безопасности
В случае выхода базы данных из строя может быть потеряна важная информация. Последствия потери данных могут быть катастрофическими как для пользователя, так и для бизнеса. Если крупные организации понесут огромные убытки, малые предприятия могут поплатиться своим существованием.
По словам разработчиков, ошибка присутствует в каждой программе. Даже самое лучшее программное обеспечение может иногда давать сбой.
Иногда работа и жизнь людей зависят от функциональности программного обеспечения. Корректная работа ПО влияет на финансовое благополучие или здоровье людей. Поэтому особенно важно, чтобы при сбоях программного обеспечения, имелась возможность быстро его вернуть в нормальное рабочее состояние.
Программы работают с базами данных. В случае выхода базы данных из строя, может быть повреждена важная информация, потеря которой обернется катастрофическими последствиями как для пользователя, так и для бизнеса. Большинство баз данных работают на сервере Microsoft SQL. В случае проблем с сервером для восстановления базы потребуется много времени и сил.
Существует несколько способов восстановить базу данных после инцидента. Во-первых, следует разобраться с таблицей подозрительных(suspect) страниц. Информация в таблице подозрительных страниц доступна любому пользователю, имеющему доступ к базе данных MSDB. Обновлять базу также может любой пользователь, имеющий разрешение на обновление. Владельцы базы, исправив роль базы данных в MSDB, или сисадмин, исправив роль сервера, могут вставлять, обновлять и удалять записи.
Способы восстановления базы данных из подозрительного режима:
Сброс статуса базы данных + DBCC CHECKDB
Используйте программное обеспечение Recovery Toolbox for SQL Server
Таблица подозрительных страниц содержит информацию о потенциально поврежденных страницах и используется при принятии решения о восстановлении страниц. Подозрительная страница из таблицы находится в базе данных MSDB.
Страница считается «подозрительной», если при попытке ее чтения ядром СУБД SQL Server обнаруживается одна из следующих ошибок.
Ошибка 823: возникает во время проверки циклической контрольной суммы (CRC), запущенной операционной системой, например, ошибка диска (возникает при некоторых аппаратных ошибках)
Ошибка 824: например, разрыв страницы (или любая другая логическая ошибка)
Идентификатор каждой «подозрительной» страницы записывается в таблицу подозрительных страниц. В данную таблицу компонент Database Engine записывает все подозрительные страницы, с которыми сталкивается во время обработки, в частности:
Когда при обработке запроса необходимо прочитать страницу.
При выполнении DBCC CHECKDB.
Во время операции резервного копирования.
Во время операции восстановления, исправления DBCC или удаления базы данных таблица подозрительных страниц также обновляется по мере необходимости.
Ниже приведены несколько способов восстановления базы данных, если она перешла в режим “suspected”.
Во время своей работы я однажды столкнулся с ситуацией, когда рабочая база данных в конце дня перешла в режим “suspected”. Причем в последний раз база была заархивирована много часов назад. К сожалению, вернуться в штатный режим не получилось. DBCC checkdb также отказался запускаться.
Я очень расстроился, пока не нашел решение. Рассмотрим первый способ восстановления базы данных.
Сначала необходимо перевести базу данных в АВАРИЙНЫЙ режим, выполнив следующие действия:
Затем требуется протестировать базу данных:
Если не получилось восстановить базу первым способом
У вас имеется поврежденная база данных сервера (MS SQL 2005) и она неисправна. Такую базу невозможно восстановить путем тестирования-исправления (возникает ошибка контрольной суммы). В таком случае база данных не выгружается в файл – выдается та же ошибка. Вы попробовали несколько раз, и это не помогло. Попробуйте восстановить базу данных, протестировав сам SQL.
Команды для тестирования SQL приведены ниже:
Если обе команды не работают, можно использовать третью. Рекомендуем использовать данную команду только в крайнем случае в связи с опасностью возможной потери данных.
DBCC CHECKDB (‘database’, REPAIR_ALLOW_DATA_LOSS)
Если команда не выполняется из-за не однопользовательского режима, используйте команду:
Alter database db-name set SINGLE_USER
! Перед тестированием обязательно сделайте бэкап!
Программа позволяет комплексно восстанавливать файлы базы данных. Особенности программы Recovery Toolbox for SQL Server приведены ниже:
1. Данные из нечитаемых баз данных можно восстановить в приостановленном состоянии (suspended state);
2. Программа работает со всеми версиями Microsoft SQL Server;
3. Программа позволяет восстановить самое важное и ценное в базе данных;
5. Восстановливает таблицы при работе с MDF файлами;
6. SQL MDF Recovery экспортирует данные непосредственно в Microsoft SQL Server;
7. Информация сохраняется в том числе в виде скриптов;
8. Извлеченные данные напрямую экспортируются в новую базу данных;
9. Программа работает с любой версией Windows;
10. Мультиязычный интерфейс;
11. Возможен просмотр данных перед восстановлением;
Сбой базы данных после сбоя сервера является самым страшным сном любого сисадмина. Как в такой ситуации восстановить поврежденную базу?
Для восстановления данных после сбоя обычно используется резервная копия. Однако, если по какой-то причине копия не была сделана, попробуйте использовать Recovery Toolbox for SQL Server. Скорее всего, вам удастся восстановить рабочее состояние базы данных.
Для этого необходимо выполнить следующие действия:
1. Установите Recovery Toolbox for SQL Server на свой компьютер. Нет необходимости использовать полную версию, достаточно демонстрационной версии;
3. После выполнения действий начнется анализ базы данных;
4. Изучите список всех восстановленных таблиц;
5. Просматривайте данные в таблицах;
6. Изучайте восстановленные объекты;
7. Настройте параметры сохранения;
8. Выберите необходимые данные;
9. Сохраните их (для этого потребуется полная версия)
Восстановление базы данных
Как видим, для быстрого исправления MDF файла потребовалось нажать всего несколько кнопок. Все восстановленные данные копируются в новую базу данных или в виде скриптов на диск. Таким образом, программа никак не влияет на поврежденные файлы.
1. Выбираем поврежденную базу данных.
2. Смотрим, какие данные можно восстановить.
3. Определяемся с вариантом экспорта.
4. Выбираем данные для восстановления.
5. Просматриваем отчет после сохранения.
Программа условно-бесплатная, стоит 99 долларов. Скачать программу можно здесь.
Инструкции RESTORE (Transact-SQL)
Восстанавливает резервные копии баз данных SQL, созданные с помощью команды BACKUP.
Щелкните одну из следующих вкладок, чтобы изучить синтаксис, аргументы, примечания, разрешения и примеры для используемой вам версии SQL.
Дополнительные сведения о соглашениях о синтаксисе см. в статье Соглашения о синтаксисе в Transact-SQL.
Выберите продукт
В следующей строке выберите название нужного продукта, и отобразится информация только об этом продукте.
* SQL Server *
SQL Server
Эта команда позволяет выполнить следующие сценарии восстановления.
Дополнительные сведения о сценариях восстановления SQL Server см. в статье Обзор процессов восстановления (SQL Server). Дополнительные сведения об аргументах см. в статье Аргументы инструкций RESTORE (Transact-SQL). При восстановлении базы данных из другого экземпляра примите во внимание сведения из раздела Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server).
Синтаксис
Аргументы
Сведения о сценариях восстановления
SQL Server поддерживает различные сценарии восстановления.
полное восстановление базы данных
Восстанавливает всю базу данных, начиная с полной резервной копии, за которой может последовать восстановление из копии разностной резервной копии базы данных (и резервных копий журналов). Дополнительные сведения см. в статьях Выполнение полного восстановления базы данных (простая модель восстановления) и Выполнение полного восстановления базы данных (модель полного восстановления).
Восстанавливается файл или файловая группа в базе данных, содержащей несколько файловых групп. Следует заметить, что при использовании простой модели восстановления файл должен принадлежать к файловой группе, находящейся в режиме только для чтения. После полного восстановления файлов может быть восстановлена разностная резервная копия файлов. Дополнительные сведения см. в статьях Файлы из резервных копий (модель полного восстановления) и Восстановление файлов (простая модель восстановления).
Производится восстановление отдельных страниц. Восстановление страницы возможно только в моделях полного восстановления и восстановления с неполным протоколированием. Дополнительные сведения см. в статье Восстановление страниц (SQL Server).
Восстановление базы данных производится по этапам, начиная с первичной файловой группы и одной или нескольких вторичных файловых групп. Поэтапное восстановление начинается с инструкции RESTORE DATABASE с параметром PARTIAL и указания одной или нескольких восстанавливаемых вторичных файловых групп. Дополнительные сведения см. в статье Поэтапное восстановление (SQL Server).
Данные восстанавливаются в том случае, если они уже согласованы с базой данных и необходимо только сделать их доступными. Дополнительные сведения см. в статье Восстановление базы данных без восстановления данных (Transact-SQL).
Восстановление журнала транзакций
В моделях полного восстановления и восстановления с неполным протоколированием восстановление резервных копий журналов необходимо для достижения необходимой точки восстановления. Дополнительные сведения о восстановлении резервных копий журналов см. в статье Применение резервных копий журналов транзакций (SQL Server).
Подготовка базы данных доступности для группы доступности AlwaysOn
Подготовка зеркальной базы данных к зеркальному отображению
Восстановление в сети
Восстановление в сети допускается только в выпуске SQL Server Enterprise.
Если поддерживается оперативное восстановление и база данных доступна в сети, автоматически выполняется оперативное восстановление файлов и страниц. Кроме того, после начального этапа поэтапного восстановления выполняется восстановление вторичной файловой группы.
При оперативном восстановлении могут использоваться отложенные транзакции.
Дополнительные сведения см. в статье Восстановление в сети (SQL Server).
Дополнительные сведения о параметрах инструкции RESTORE
Неподдерживаемые ключевые слова инструкции RESTORE
В SQL Server 2008 следующие ключевые слова больше не поддерживаются.
RESTORE LOG
Инструкция RESTORE LOG может включать список файлов, создаваемых во время наката. Эта возможность используется, если резервная копия журналов содержит журнальные записи, произведенные во время добавления файла в базу данных.
Для базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, необходимо, чтобы перед восстановлением базы данных была создана резервная копия конца журнала. Восстановление базы данных без создания резервной копии заключительного фрагмента журнала приведет к ошибке, если инструкция RESTORE DATABASE не содержит предложение WITH REPLACE или WITH STOPAT, в котором должно указываться время или транзакция, выполняемая после завершения резервного копирования данных. Дополнительные сведения о резервных копиях заключительного фрагмента журнала см. в статье Резервные копии заключительного фрагмента журнала (SQL Server).
Сравнение параметров RECOVERY и NORECOVERY
Откат контролируется инструкцией RESTORE при помощи параметров [ RECOVERY | NORECOVERY ].
Параметр NORECOVERY указывает на то, что откат не выполняется. Это позволяет продолжать накат при помощи следующей инструкции в последовательности.
В этом случае последовательность восстановления может восстановить другие резервные копии и выполнить их накат.
Параметр RECOVERY (параметр по умолчанию) указывает на то, что откат должен быть выполнен после завершения наката для текущей резервной копии.
Для восстановления базы данных необходимо, чтобы весь набор восстанавливаемых данных (набор данных наката) был согласован с базой данных. Если набор данных наката, необходимый для согласования с базой данных, достаточно велик и указан параметр RECOVERY, компонент Компонент Database Engine формирует ошибку. Дополнительные сведения о процессе восстановления см. в статье Обзор процессов восстановления (SQL Server).
Поддержка совместимости
Резервные копии баз данных master, model и msdb, созданные в более ранней версии SQL Server, не могут быть восстановлены в SQL Server.
Резервная копия SQL Server не может быть восстановлена на SQL Server, имеющем более раннюю версию.
В каждой версии SQL Server используется путь по умолчанию, отличный от пути в предыдущих версиях. Поэтому, чтобы восстановить из резервной копии базу данных, созданную в расположении по умолчанию для архивов предыдущих версий, необходимо использовать параметр MOVE. Сведения о новом пути по умолчанию см. в разделе Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server.
При первом присоединении базы данных к новому экземпляру SQL Server или ее восстановлении копия главного ключа базы данных (зашифрованная главным ключом службы) еще не хранится на сервере. Необходимо расшифровать главный ключ базы данных с помощью инструкции OPEN MASTER KEY. Как только главный ключ базы данных будет расшифрован, появится возможность разрешить автоматическую расшифровку в будущем с помощью инструкции ALTER MASTER KEY REGENERATE, чтобы оставить на сервере копию главного ключа базы данных, зашифрованного с помощью главного ключа службы. После обновления базы данных с переходом от более ранней версии главный ключ базы данных должен быть создан повторно для использования нового алгоритма шифрования AES. См. дополнительные сведения о повторном создании главного ключа базы данных. Время, необходимое для повторного создания главного ключа базы данных с обновлением до алгоритма шифрования AES, зависит от числа объектов, защищаемых главным ключом базы данных. Повторное создание главного ключа базы данных с обновлением до алгоритма шифрования AES необходимо произвести только один раз. Это никак не повлияет на последующие операции повторного создания, выполняемые в соответствии со стратегией смены ключей.
Общие замечания
Во время автономного восстановления, если указанная база данных используется, функция RESTORE после короткой задержки принудительно отключает пользователей. Для восстановления в режиме «в сети» непервичной файловой группы база данных может продолжать использоваться, за исключением тех случаев, когда восстанавливаемая файловая группа переводится в режим вне сети. Данные в указанной базе данных заменяются восстановленными данными.
Операции восстановления между несколькими платформами, даже между процессорами различных типов, могут выполняться, если параметры сортировки базы данных поддерживаются операционной системой.
После возникновения ошибки инструкция RESTORE может быть запущена вновь. Кроме того, можно указать, чтобы, несмотря на ошибки, инструкция RESTORE продолжала работу и восстановила как можно большее количество данных (см. параметр CONTINUE_AFTER_ERROR ).
Инструкция RESTORE недопустима в явной или неявной транзакции.
Восстановление поврежденной базы данных master выполняется при помощи специальной процедуры. Дополнительные сведения см. в статье Резервное копирование и восстановление системных баз данных (SQL Server).
Восстановление базы данных из копии удаляет кэш планов для восстанавливаемой базы данных. Очистка кэша планов становится причиной перекомпиляции всех последующих планов выполнения и приводит к непредвиденному временному снижению производительности обработки запросов.
Чтобы восстановить базу данных доступности, сначала восстановите базу данных в экземпляре SQL Server, а затем добавьте базу данных в группу доступности.
Совместимость
Настройка базы данных и восстановление
Во время восстановления большинство параметров базы данных, устанавливаемых при помощи инструкции ALTER DATABASE, сбрасывается в значения, в которых они находились в конце резервного копирования.
Однако использование параметра WITH RESTRICTED_USER переопределяет этот режим работы для настройки параметра доступа пользователя. Эта настройка всегда сохраняется, если инструкция RESTORE включает параметр WITH RESTRICTED_USER.
Восстановление зашифрованной базы данных
Чтобы восстановить зашифрованную базу данных, необходимо иметь доступ к сертификату или асимметричному ключу, который использовался для шифрования базы данных. Без сертификата или асимметричного ключа восстановить базу данных нельзя. Поэтому сертификат, используемый для шифрования ключа шифрования базы данных, должен храниться в течение всего времени, пока есть необходимость в резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.
Восстановление базы данных с включенным форматом хранения vardecimal
Резервное копирование и восстановление правильно работают с форматом хранения vardecimal. Дополнительные сведения о формате хранения vardecimal см. в статье sp_db_vardecimal_storage_format (Transact-SQL).
Восстановление полнотекстовых данных
Во время полного восстановления полнотекстовые данные восстанавливаются вместе с другими данными базы данных. С помощью обычного синтаксиса RESTORE DATABASE database_name FROM backup_device полнотекстовые файлы восстанавливаются как часть файлов базы данных.
Инструкция RESTORE может также использоваться для восстановления в разные расположения, для разностного восстановления, восстановления файлов и файловых групп, а также для восстановления файлов и файловых групп полнотекстовых данных. Кроме того, инструкция RESTORE может восстанавливать как полнотекстовые файлы, так и файлы с данными базы данных.
Полнотекстовые каталоги, импортированные из SQL Server 2005 (9.x), по-прежнему рассматриваются как файлы базы данных. Для них остается применимой процедура SQL Server 2005 (9.x) по резервному копированию полнотекстовых каталогов, за исключением того, что более нет необходимости использовать паузу и возобновление в процессе выполнения резервного копирования. Дополнительные сведения см. в разделе Резервное копирование и восстановление полнотекстовых каталогов.
Кластеры больших данных SQL Server
Метаданные
SQL Server включает таблицы журналов резервного копирования и восстановления, в которые заносятся данные слежения за резервным копированием и восстановлением для каждого экземпляра сервера. При выполнении восстановления таблицы журнала резервного копирования также изменяются. Сведения об этих таблицах см. в статье Журнал и сведения о заголовке резервной копии (SQL Server).
Влияние параметра REPLACE
Параметр REPLACE должен использоваться редко и после тщательного анализа. Восстановление обычно не допускает случайной перезаписи базы данных другой базой данных. Если указанная в инструкции RESTORE база данных уже существует на текущем сервере, а идентификатор GUID семейства для заданной базы данных отличается от идентификатора GUID семейства для базы данных, записанного в резервном наборе данных, то ее восстановление не будет выполнено. Это является важной защитной мерой.
Параметр REPLACE отменяет несколько важных проверок, обычно выполняемых операцией восстановления. Отменяются следующие проверки.
Проверка на восстановление поверх существующей базы данных резервной копии, созданной для другой базы данных.
При использовании параметра REPLACE при восстановлении можно записать данные поверх существующей базы данных независимо от того, какие базы данных содержатся в резервном наборе данных, даже если указанное имя данных отличается от записанного в резервном наборе. Это может привести к случайной перезаписи поверх базы данных другой базы данных.
Проверка на восстановление базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, для которой не была создана резервная копия заключительного фрагмента журнала, и не был применен параметр STOPAT.
При использовании параметра REPLACE возможна потеря зафиксированных данных, поскольку последние записанные в журнал данные еще не были скопированы в резервную копию.
Перезапись существующих файлов.
Проверка на перезапись существующих файлов неверного типа (например XLS-файлов) или файлов, используемых другой базой данных, в данный момент находящейся не в режиме в сети. Возможна случайная потеря данных в случае перезаписи существующих файлов, несмотря на то, что восстановленная база данных будет полной.
Повторное восстановление
Отменить результаты восстановления невозможно, однако можно отменить результаты копирования данных и произвести накат для каждого файла по отдельности. Для перезапуска восстановите нужный файл и выполните накат повторно. Например, если случайно было восстановлено слишком много резервных копий журналов и нужная точка остановки восстановления пройдена, нужно перезапустить последовательность.
Последовательность восстановления может быть прервана и перезапущена при восстановлении всего содержимого соответствующих файлов.
Восстановление базы данных к моментальному снимку базы данных
Операция восстановления базы данных, указываемая с помощью параметра DATABASE_SNAPSHOT, переносит всю базу данных-источник назад во времени, восстанавливая ее на момент создания моментального снимка базы данных, т. е. перезаписывая базу данных-источник данными из указанного моментального снимка. В данный момент может существовать только моментальный снимок, к которому выполняется восстановление. Затем операция отката вновь создает журнал (поэтому впоследствии нельзя будет выполнить накат возвращенной базы данных к точке пользовательской ошибки).
Потеря данных затронет только изменения в базе данных, произведенные после создания моментального снимка. Метаданные возвращенной базы данных соответствуют метаданным времени создания моментального снимка. Однако при возвращении к моментальному снимку удаляются все полнотекстовые каталоги.
Возврат из моментальных снимков базы данных не предназначен для восстановления носителей. В отличие от обычного резервного набора данных, моментальный снимок базы данных является неполной копией файлов базы данных. В том случае, если база данных или моментальный снимок базы данных повреждены, возврат из моментального снимка может оказаться невозможным. Более того, даже если оно окажется возможным, восстановление в случае повреждения вряд ли поможет устранить проблему.
Ограничения на возврат
Возврат не поддерживается в следующих условиях.
Безопасность
В операции создания резервной копии могут дополнительно указываться пароли для набора носителей, резервного набора данных или и того и другого. Если для набора носителей или резервного набора данных установлен пароль, то в инструкции RESTORE необходимо указывать правильные пароли. Эти пароли предотвращают несанкционированные операции восстановления и присоединения резервных наборов данных к носителю при помощи инструментальных средств SQL Server. Однако защищенный паролем носитель может быть переписан инструкцией BACKUP с параметром FORMAT.
Данный пароль не обеспечивает надежную защиту. Он предназначен для предотвращения неверного восстановления при использовании средств SQL Server авторизованными или неавторизованными пользователями. При этом остается возможным чтение данных резервных копий с помощью других средств или замена пароля. В будущей версии Microsoft SQL Server этот компонент будет удален. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.Рекомендуемым способом защиты резервных копий является хранение лент с резервными копиями в безопасном месте или создание резервных копий на диске в виде файлов, защищенных соответствующими списками управления доступом (ACL). Списки ACL должны располагаться в корневом каталоге, в котором создаются резервные копии.
Сведения о резервном копировании и восстановлении SQL Server в хранилище BLOB-объектов Microsoft Azure см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.
Разрешения
Разрешения на выполнение инструкции RESTORE даются ролям, в которых данные о членстве всегда доступны серверу. Так как членство в предопределенной роли базы данных может быть проверено только тогда, когда база данных доступна и не повреждена, что не всегда имеет место при выполнении инструкции RESTORE, члены предопределенной роли базы данных db_owner не имеют разрешений RESTORE.
Примеры
Во всех примерах предполагается, что выполнено полное резервное копирование базы данных.
Примеры выполнения инструкции RESTORE.
Дополнительные примеры см. в разделах по восстановлению из статьи Обзор процессов восстановления (SQL Server).
A. Восстановление всей базы данных
Для базы данных, использующей модель полного восстановления или модель восстановления с неполным протоколированием, SQL Server в большинстве случаев требует, чтобы перед восстановлением базы данных была создана резервная копия конца журнала. Дополнительные сведения см. в статье Резервные копии заключительного фрагмента журнала (SQL Server).
Б. Восстановление полной и разностной резервных копий базы данных
В. Восстановление базы данных с использованием синтаксиса RESTART
Г. Восстановление базы данных и перемещение файлов
Д. Копирование базы данных с помощью BACKUP и RESTORE
Е. Восстановление состояния на определенный момент времени с помощью STOPAT
В следующем примере база данных восстанавливается в состояние на 12:00 AM«April 15, 2020 и демонстрируется операция восстановления, использующая несколько резервных копий журналов. На устройстве резервного копирования AdventureWorksBackups полная резервная копия базы данных, подлежащей восстановлению, — это третий резервный набор данных на устройстве ( FILE = 3 ), резервная копия первого журнала — это четвертый резервный набор ( FILE = 4 ), резервная копия второго журнала — это пятый резервный набор ( FILE = 5 ).
G. Восстановление журнала транзакций до метки
H. Восстановление с использованием синтаксиса TAPE
I. Восстановление с использованием синтаксиса FILE и FILEGROUP
Восстановление выполняется как отдельный шаг с целью снижения возможности преждевременного восстановления по журналу, до того как будут восстановлены все резервные копии журналов. Дополнительные сведения о процессе восстановления см. в статье Обзор процессов восстановления (SQL Server).
J. Возврат из моментального снимка базы данных
В следующем примере производится восстановление базы данных к моментальному снимку базы данных. В этом примере предполагается, что в базе данных в настоящее время существует только один моментальный снимок. Пример создания этого моментального снимка базы данных см. в этой статье.
Восстановление до моментального снимка удаляет все полнотекстовые каталоги.
K. Восстановление из службы хранилища BLOB-объектов Microsoft Azure
K3. Восстановление полной резервной копии базы данных из локального хранилища в службу хранилища Microsoft Azure