Sql server как восстановить базу данных из bak файла бэкапа

Обновлено: 06.07.2024

Резервные копии рабочих баз данных, т.н. backup (бэкап), рекомендуется делать регулярно (на случай аппаратных и/или программных сбоев на сервере) с использованием планировщиков заданий, процесс настройки которых подробно описан в инструкциях по установке сетевых версий программ Альта-Софт (включая «Альта-ГТД»). Кроме того, в самой программе «Альта-ГТД» имеется функция, позволяющая создать резервную копию рабочей базы – см. меню Сервис/Бэкап БД SQL.

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

Перенос базы данных с одного SQL-сервера на другой также необходимо делать с помощью операций:

Создание резервной копии базы данных (backup)

Запустить утилиту SQL Server Management Studio (из состава MS SQL Server).
Подключиться к серверу под учетной записью администратора или владельца БД (можно использовать встроенную учетную запись «sa», пароль для которой задавался при установке SQL Server, либо выбрать вариант «Проверка подлинности Windows» в случае если текущий пользователь сеанса Windows обладает правами администратора в SQL Server, а также использовать любую другую учетную запись SQL Server или Windows, которая включена в роль «db_owner» копируемой базы):
Нажать правой кнопкой мыши на имени копируемой БД (в разделе «Базы данных») и выбрать меню «Задачи/Создать резервную копию»:
В разделе «Назначение» указать путь и имя файла (путь всегда задается для компьютера, где установлен сам SQL Server!), в который будет выгружена база данных, для чего использовать кнопки «Удалить» и «Добавить» до тех пор, пока в поле «Создать резервную копию на» не будет отображен ровно один желаемый путь:
На странице «Параметры» установить переключатель «Создать резервную копию в новом наборе носителей…» и галочку «Проверить резервную копию после завершения»:
Нажать кнопку «ОК».

Примечание. Резервные копии баз данных SQL Server обычно хорошо сжимаются архиваторами (WinRAR, WinZIP и т.п.), поэтому размер полученного файла (*.bak) можно сильно уменьшить с их помощью.

Восстановление базы данных из резервной копии (restore)

Запустить утилиту SQL Server Management Studio (из состава MS SQL Server).
Подключиться к серверу под учетной записью администратора или владельца БД (можно использовать встроенную учетную запись «sa», пароль для которой задавался при установке SQL Server, либо выбрать вариант «Проверка подлинности Windows» в случае если текущий пользователь сеанса Windows обладает правами администратора в SQL Server, а также использовать любую другую учетную запись SQL Server или Windows, которая включена в роль «db_owner» восстанавливаемой базы при наличии таковой или серверную роль «dbcreator»):
Нажать правой кнопкой мыши на разделе «Базы данных» и выбрать меню «Восстановить базу данных»:
На странице «Общие» выполнить следующие действия:
- В поле «В базу данных» ввести имя для восстанавливаемой базы (если будет указано имя существующей базы, то это эквивалентно тому, что сначала полностью удалить существующую базу и затем восстановить из резервной копии новую базу, т.е. все данные существующей базы будут утеряны!);
- Установить переключатель «С устройства» и указать путь к файлу резервной копии, нажав кнопку «…»;
- Установить галочку «Восстановить» в нужной строке (которых может быть несколько, если один файл *.bak содержит несколько резервных копий базы):
На странице «Параметры» установить галочку «Перезаписать существующую базу данных» и проверить пути в списке «Восстановить файлы базы данных как» (должны указывать на существующую папку на SQL-сервере, к которой предоставлены права на запись – пути по умолчанию обычно должны заканчиваться папкой DATA, а не просто MSSQL):
Нажать кнопку «ОК».

Примечание. После восстановления базы данных на другой версии SQL Server (например, при переносе с SQL2005 на SQL2008) рекомендуется в свойствах базы данных переключить параметр «Уровень совместимости» на последнюю версию (см. страницу «Параметры» в свойствах БД).

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

Для переноса большого количества «имен входа» (логинов) с их паролями на новый сервер можно воспользоваться способом, описанным в статье базы знаний Microsoft. Однако, следует иметь в виду, что данный способ не переносит серверные права логинов (принадлежность «серверным ролям», право на «просмотр состояния сервера» и т.п.), а также не подходит для переноса с SQL 2012 на более ранние версии SQL Server.

Этот раздел содержит сведения о восстановлении полной резервной копии базы данных с использованием среды SQL Server Management Studio.

Важно!

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

При восстановлении базы данных из другого экземпляра примите во внимание сведения из раздела Управление метаданными при обеспечении доступности базы данных на другом экземпляре сервера (SQL Server).

Чтобы восстановить зашифрованную базу данных, потребуется доступ к сертификату или асимметричному ключу, использовавшемуся для шифрования этой базы данных. Без сертификата или асимметричного ключа вы не сможете восстановить базу данных. Сохраняйте сертификат, который использовали для шифрования ключа шифрования базы данных, в течение всего периода хранения резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.

Если восстановить базу данных более старой версии до SQL Server 2019 (15.x), эта база данных будет автоматически обновлена до SQL Server 2019 (15.x). Это исключает возможность использования базы данных с более старой версией Компонент Database Engine. Но это относится к обновлению метаданных и не влияет на уровень совместимости базы данных. Если уровень совместимости пользовательской базы данных до обновления был 100 или выше, после обновления он останется таким же. Если уровень совместимости до обновления был 90, в обновленной базе данных он устанавливается в 100, что является минимально поддерживаемым уровнем совместимости в SQL Server 2019 (15.x). Дополнительные сведения см. в разделе Уровень совместимости инструкции ALTER DATABASE (Transact-SQL).

Как правило, база данных сразу становится доступной. Однако если база данных SQL Server 2005 (9.x) содержит полнотекстовые индексы, то в процессе обновления будет произведен их импорт, сброс или перестроение в зависимости от установленного значения свойства сервера Режим обновления полнотекстового каталога . Если выбран режим обновления Импортировать или Перестроить, то полнотекстовые индексы во время обновления будут недоступны. В зависимости от объема индексируемых данных процесс импорта может занять несколько часов, а повторная сборка — до десяти раз дольше.

Если выбран режим обновления Импорт, а полнотекстовый каталог недоступен, то связанные с ним полнотекстовые индексы будут перестроены. Сведения о просмотре и изменении параметра Режим обновления полнотекстового поиска см. в статье Наблюдение за полнотекстовым поиском для экземпляра сервера и управление им.

Сведения о восстановлении SQL Server из службы хранилища BLOB-объектов Microsoft Azure см. в разделе Резервное копирование и восстановление SQL Server с помощью службы хранилища BLOB-объектов Microsoft Azure.

Примеры

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

В обозревателе объектов подключитесь к экземпляру компонента Компонент SQL Server Database Engine и разверните его.

Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных.

Чтобы указать источник и расположение восстанавливаемых резервных наборов данных, используйте страницу Общие , раздел Источник . Выберите один из следующих вариантов.

База данных

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

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

Устройство

Диалоговое окно Выбор устройств резервного копирования .

Носитель данных резервной копии
Выберите тип носителя в раскрывающемся списке Тип носителя данных резервной копии . Примечание. Параметр Лента появляется только в случае, если на компьютере установлен ленточный накопитель, а параметр Устройство резервного копирования — только в случае, если имеется хотя бы одно устройство резервного копирования.

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

Тип носителя данных	.	Описание
Файл	Локальный файл резервной копии	В данном диалоговом окне можно выбрать локальный файл из дерева или указать удаленный файл, используя его полное имя в формате UNC. Дополнительные сведения см. в разделе Устройства резервного копирования (SQL Server).
Устройство	Выбор устройства резервного копирования	В данном диалоговом окне из списка можно выбрать логические устройства резервного копирования, определенные на экземпляре сервера.
Лента	Выбор ленты с резервной копией	В данном диалоговом окне из списка можно выбрать ленточные накопители, физически подключенные к компьютеру, на котором запущен экземпляр SQL Server.
URL-адрес	Выберите расположение файла резервной копии	В этом диалоговом окне можно выбрать существующие учетные данные SQL Server или контейнер хранилища Azure, добавить новый контейнер хранилища Azure с подписанным URL-адресом или сформировать подписанный URL-адрес и учетные данные SQL Server для уже существующего контейнера хранилища. См. также статью Соединение с подпиской Microsoft Azure

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

Содержание
Отображает содержимое носителя выбранного файла, ленты или устройства резервного копирования. Эта кнопка может не работать, если тип носителя — URL-адрес.

Тип носителя резервной копии
Перечисляет выбранные носители.

После добавления нужных устройств в списке Носитель резервной копии нажмите кнопку ОК для возвращения на страницу Общие .

В списке Источник > Устройство > База данных выберите имя базы данных, которую нужно восстановить.

Данный список доступен, только если выбран параметр Устройство . Будут выбраны только те базы данных, резервные копии которых доступны на выбранном устройстве.

В разделе Назначение , в поле База данных автоматически появится имя базы данных для восстановления. Для изменения имени базы данных введите новое имя в окно База данных .

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

В сетке Резервные наборы данных для восстановления выберите нужные резервные наборы. В этой сетке отображаются резервные копии, доступные в указанном месте. По умолчанию предлагается план восстановления. Чтобы переопределить предложенный план восстановления, можно изменить выбранные элементы в сетке. Выбор всех резервных копий, которые зависят от восстановления более ранних копий, отменяется автоматически, как только отменяется выбор более ранних копий. Дополнительные сведения о столбцах сетки Резервные наборы данных для восстановления см. в статье Восстановление базы данных (страница "Общие").

При необходимости нажмите кнопку Файлы на панели Выбор страницы и перейдите в диалоговое окно Файлы . Отсюда можно восстановить базу данных в новое расположение, определив новое место восстановления для каждого файла в сетке Восстановить файлы базы данных как . Дополнительные сведения об этой сетке см. в разделе Восстановление базы данных (страница "Файлы").

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

Параметры WITH (необязательно):

Перезаписать существующую базу данных (WITH REPLACE)

Сохранить параметры репликации (WITH KEEP_REPLICATION)

Ограничить доступ к восстановленной базе данных (WITH RESTRICTED_USER)

Выберите параметр в поле Состояние восстановления . В данном окне определяется состояние базы данных после операции восстановления.

По умолчанию используется схема RESTORE WITH RECOVERY, которая выполняет откат незафиксированных транзакций и после завершения оставляет базу данных работоспособной. Дополнительные журналы транзакций восстановить невозможно. Выберите этот вариант, если выполняется восстановление сразу всех необходимых резервных копий.

Схема RESTORE WITH NORECOVERY оставляет базу данных в нерабочем состоянии и не выполняет откат незафиксированных транзакций. Можно восстановить дополнительные журналы транзакций. Вы не сможете использовать эту базу данных, пока она не будет восстановлена.

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

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

Если имеются активные соединения с базой данных, то операция восстановления может завершиться ошибкой. Проверьте окно Закрыть существующие соединения и убедитесь, что все активные соединения между Среда Management Studio и базой данных закрыты. Эта настройка переводит базу данных в однопользовательский режим перед началом процедуры восстановления, а затем возвращает в многопользовательский режим после ее завершения.

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

Дополнительные сведения об этих параметрах восстановления см. в разделе Восстановление базы данных (страница "Параметры").

Б. Восстановление более ранней резервной копии диска поверх существующей базы данных

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

В обозревателе объектов подключитесь к экземпляру компонента Компонент SQL Server Database Engine и разверните его.

Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных.

На странице Общие выберите пункт Устройство в разделе Источник .

в разделе Параметры восстановления установите флажок Перезаписать существующую базу данных (WITH REPLACE) .

В разделе Резервная копия заключительного фрагмента журнала снимите флажок Делать резервную копию заключительного фрагмента журнала перед восстановлением.

Не для всех сценариев восстановления требуется резервная копия заключительного фрагмента журнала. Резервная копия заключительного фрагмента журнала не нужна, если точка восстановления содержится в более ранней резервной копии журнала. Кроме того, резервная копия заключительного фрагмента журнала не требуется при перемещении или замещении (перезаписи) базы данных, при котором не нужно восстанавливать ее на определенный момент времени после создания ее последней резервной копии. Дополнительные сведения см. в разделе Резервные копии заключительного фрагмента журнала (SQL Server).

Этот параметр недоступен для баз данных при использовании ПРОСТОЙ модели восстановления.

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

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

В следующем примере восстанавливается более ранняя резервная копия диска из базы данных Sales и создается новая база данных с именем SalesTest . При этом исходная база данных, Sales , все еще существует на сервере.

В обозревателе объектов подключитесь к экземпляру компонента Компонент SQL Server Database Engine и разверните его.

Щелкните правой кнопкой мыши узел Базы данных и выберите команду Восстановить базу данных.

На странице Общие выберите пункт Устройство в разделе Источник .

Если оставить этот флажок установленным, существующая база данных Sales сменит состояние на состояние восстановления.

Г. Восстановление до точки во времени

В следующем примере база данных восстанавливается в состояние на 1:23:17 PM``May 30, 2016 и демонстрируется операция восстановления, использующая несколько резервных копий журналов. Указанная база данных не существует на сервере.

Д. Восстановление резервной копии с помощью службы хранилища Microsoft Azure

Общие шаги

В двух примерах ниже выполняется восстановление базы данных Sales из резервной копии, расположенной в службе хранилища Microsoft Azure. Имя учетной записи хранилища — mystorageaccount . Контейнер называется myfirstcontainer . Для краткости первые шесть шагов перечислены здесь однократно, а все примеры начинаются с шага 7.

SQL Server Как восстановить базу данных из bak файла бэкапа (restore DB from backup)

Задача: восстановить базу данных из файла бэкапа.
Шаг за шагом с иллюстрациями рассмотрим как это сделать на примере СУБД Microsoft SQL Server 2014. Кроме восстановления посмотрим также как сделать линковку (связь) пользователя базы данных и логина СУБД (будет использовать SQL скрипт sp_change_users_login).
Итак, залогиньтесь в СУБД SQL Server и в дереве в контекстном меню пункта Databases выберите пункт "Restore Database. ":

В параметрах выберем "Device" и перейдем по кнопке "Обзор" (кнопка с многоточием):

В открывшемся окне нажимаем "Add" и находим файл бэкапа базы данных:

Перед началом рекомендуется проверить корректность файла, нажав кнопку "Verify Backup Media":

Далее перейдем в левом меню на раздел "Files" и проверим пути для сохранения восстановленной базы данных. При необходимости меняем их (не обязательно):

Также можно перейти в раздел "Options" и сделать настройки, если требуется (не обязательно):

Если база данных содержала информацию о пользователях, то необходимо проверить их связь с логинами. Для этого в дереве находим вновь воссозданную БД, раскрываем пункт "Security" - "Users" и выбираем какого-либо существующего пользователя и в контекстном меню переходим на пункт "Properties":

В открывшемся окне свойств пользователя мы видим, что пользователь существует только в контексте это базы (т.е. не связан ни с каким логином "SQL user without login"):

Это не позволит Вам подключиться к базе данных под данным пользователем. Поэтому создадим логин для этого пользователя (если логин уже существует, пропустите этот шаг). В дереве объектов СУБД перейдем на уровень выше (выше, чем текущая БД) в пункт "Security" и в контекстном меню пункта "Logins" выберем "New Login. ":

В открывшемся окне заполняем:
- login name - имя логина (я всегда делаю его одноименным с пользователем базы)
- выбираем параметр "SQL Server authentication" и задаем пароль
- снимаем "галку" "Enforce password policy"
- default database - прописываем нужную базу данных:

Далее можно перейти в левом меню в раздел "User Mapping", где увидим, что можно закрепить за созданным логином некого пользователя в базе. Если у Вас база данных не содержит никаких пользователей, то задайте эти параметры, как показано на рисунке (в противном случае пропустите этот шаг) и будет автоматически создан пользователь БД связанный с данным логином:

При этом логин будет создан, но не связан с пользователем.

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

Теперь, если снова перейти в свойства пользователя БД, то мы видим, что пользователь связан с только что созданным логином.

26.02.2020

SQL Server

комментариев 12

В этой статье мы рассмотрим, как настроить резервное копирование баз данных в Microsoft SQL Server, покажем, как восстановить базу данных из резервной копии с помощью SQL Server Management Studio и Transact-SQL. Первая часть статьи посвящена теоретическим аспектам резервного копирование в SQL, во второй на примере мы покажем, как настроить регулярное резервное копирование базы данных MS SQL с помощью плана обслуживания и восстановить базу из резервной копии на примере установленного Microsoft SQL Server 2019.

Требования к плану резервного копирования баз данных SQL Server устанавливает бизнес, учитывая несколько критериев:

Допустимый объём потерянных данных (за последний день/час/минуту/секунду);
Требования к дисковому пространству и его стоимость;
Затраты ресурсов сервера на резервное копирование.

Следует понимать, что с помощью механизмов резервного копирования невозможно добиться резервирования данных в реальном времени. Для этой цели используются другие технологии высокой доступности SQL Server – группы доступности Always On, зеркалирование баз данных или репликация.

Типы резервного копирования SQL Server

Полное (Full Backup)

Полное резервное копирование делает копию всей базы данных, включая все объекты и данные системных таблиц. Полная резервная копия не будет усекать (truncate) журнал транзакций. Это основной тип резервных копий, который требуется выполнять перед другими типами резервных копий.

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

Если модель восстановления базы SQL данных установлена как “Полная”, то при восстановлении бекапа вы можете указать параметр “STOPAT”, где указывается время (до секунды) на котором нужно остановить восстановление данных. Например, сотрудник внёс некорректные данные в 14:46:07, с помощью параметра STOPAT вы можете восстановить данные на момент 14:46:06

Дифференциальное

Дифференциальное или разностное резервное копирование — это копирование только тех данных, которые появились с момента последней полной резервной копии.

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

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

Например, если полная резервная копия весит 300 GB, а дифференциальная спустя час работы 5 GB, то спустя сутки это будет 120 GB, что делает использование данного типа копий нерациональным.

Журнал транзакций

Резервное копирования журнала транзакций копирует все транзакции, которые произошли с момента последнего резервного копирования, а затем урезает журнал транзакций для освобождения дискового пространства.

Восстанавливая журнал транзакций, вы также можете указать параметр STOPAT, как и в восстановлении полной резервной копии.

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

Tail-Log

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

Tail-Log бекап рекомендуется делать перед восстановлением копий журнала транзакций, чтобы не потерять транзакции между последним бекапом и текущим моментом времени.

Copy-only

Этот вид бекапа не может служить “базой” для дифференциальных резервных копий и для копий журнала транзакций. Copy-only бекап не нарушает текущую цепочку резервных копий (полный-> дифференциальный или полный -> копии журналов транзакций) и используется только в том случае, если вам нужно снять полную резервную копию, не задевая текущую цепочку бекапов.

За исключением этих нюансов – ничем не отличается от обычной полной копии.

Частичная резервная копия

Partial backup этот тип резервной копии используется для того, чтобы снять копии с read-only файловых групп. На практике используется редко.

Резервное копирование файлов и файловых групп

Используется для снятия резервных копий определенных файлов или файловых групп.

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

Модель восстановления – это параметр базы данных SQL Server, который отвечает за регистрацию транзакций в журнале транзакций. Всего существует три модели восстановления:

Простая модель восстановления

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

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

При использовании этой модели восстановления, следующий функционал SQL Server недоступен:

Доставка журналов транзакций
Always On
Point-In-Time восстановление
Резервные копии журнала транзакций

Полная модель восстановления

Полная модель восстановления хранит все транзакции в журнале транзакций до усечения журнала (посредством снятия резервной копии журнала).

Это самая “надежная” модель восстановления, при аварийном сбое можно вы сможете восстановить все транзакции, кроме тех, которые не успели завершиться при аварии.

Эта модель нуждается в обслуживании журналов транзакций (регулярные резервные копии), иначе журналы займут всё дисковое пространство.

Восстановление с неполным протоколированием (bulk logged)

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

SELECT INTO
BULK INSERT и BCP
INSERT INTO SELECT
Операции с индексами (CREATE INDEX, ALTER INDEX REBUILD, DROP INDEX)

В остальном эта модель работает аналогично полной модели восстановления.

Настройка резервного копирования SQL Server с помощью плана обслуживания

Планы обслуживания SQL Server это самый распространенный способ настройки регулярного резервного копирования.

Рассмотрим настройку резервного базы данных на SQL Server копирования по плану:

Полная резервная копия каждые 24 часа
Копия журнала транзакций – каждые 30 минут

В SSMS (SQL Server Management Studio) перейдите в раздел Management -> Maintenance Planes и запустите -> мастер создания плана обслуживания (Maintenance Plan Wizard).

Укажите имя плана и выберите режим “Separate schedules for each task”.

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

Back Up Database (Full)
Back Up Database (Transaction Log)

Используйте следующую последовательность операций:

Выберите базу данных SQL Server, которую нужно бэкапить и выберите расписание.

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

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

Нажмите Next и аналогично создайте расписание резервного копирования для журнала транзакций.

Опционально можно указать файл для ведения лога плана обслуживания.

Завершение настройки плана обслуживания SQL Server.

Выполните план обслуживания вручную и проверьте журнал.

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

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

Теперь рассмотрим, как восстановить базы данных SQL Server из резервной копии. Для восстановления базы можно использовать графическую консоль SQL Server Management Studio или язык T-SQL.

Восстановление резервной копии с помощью SQL Server Management Studio

Запустите SSMS, щелкните по разделу Database и выберите пункт Restore Database.

Для примера, воспользуемся Point-In-Time восстановлением и выберем момент, на который мы хотим восстановить базу данных. Нажмите Timeline.

Выберите опцию “Close existing connections to destination database”, если ваша база данных находится в статус Online

Нажмите ОК. После этого база данных восстановится на выбранный момент времени.

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

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

USE [master]
ALTER DATABASE [TestDatabase2] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
BACKUP LOG [TestDatabase2] TO DISK = N'E:\MSSQL15.NODE2\MSSQL\Backup\TestDatabase2_LogBackup_2020-02-17_15-39-43.bak' WITH NOFORMAT, NOINIT, NAME = N'TestDatabase2_LogBackup_2020-02-17_15-39-43', NOSKIP, NOREWIND, NOUNLOAD, NORECOVERY, STATS = 5
RESTORE DATABASE [TestDatabase2] FROM DISK = N'E:\MSSQL15.NODE2\MSSQL\Backup\full.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N'E:\MSSQL15.NODE2\MSSQL\Backup\trans.bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N'E:\MSSQL15.NODE2\MSSQL\Backup\trans.bak' WITH FILE = 2, NOUNLOAD, STATS = 5, STOPAT = N'2020-02-17T15:38:23'
ALTER DATABASE [TestDatabase2] SET MULTI_USER
GO

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

Дальше выполняется tail-log бекап, затем восстанавливается полный бекап и следом восстанавливаются бекапы журнала транзакций. Обратите внимание на параметр STOPAT, база данных восстановиться на момент 15:38:23

Раннее я уже писал о создании резервных копий в MS SQL Server 2012. В данной статье подробно рассмотрим процессе восстановления базы данных из имеющейся резервной копии (резервных копий) в MS SQL Server 2012 (в более ранних версиях, например в MS SQL Server 2008 набор действий аналогичен).

0. Оглавление

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

Подключаемся к MS SQL Server c помощью программы «SQL Server Management Studio». В Microsoft Windows Server 2012 R2 ее можно найти в списке всех программ.

В Microsoft Windows Server 2008 R2 в меню «Пуск» (Start) — «Microsoft SQL Server 2012» — «Среда SQL Server Management Studio».

Вводим адрес сервера или его псевдоним, данные для авторизации и нажимаем «Соединить» (Connect).

Запустится мастер восстановления базы данных (Restore Database). Выбираем базу источник (Source for restore), при этом мастер попробует автоматически подобрать последовательность файлов резервных копий для восстановления базы на текущий момент времени.

Если же требуется загрузить данные из конкретного файла или устройства резервного копирования, то необходимо установить соответствующий переключатель в положение «Устройство» (From device) и вручную указать источник для восстановления.

Очень важно (!) также помнить о том, что если восстановление данных осуществляется в информационную базу отличную от той с которой производилось резервное копирование (т. е. необходимо скопировать базу данных) то на вкладке «Файлы» (Files) необходимо указать путь к файлам этой информационной базы.

На вкладке «Параметры» (Options) можно указать дополнительные параметры резервного копирования. В частности:

Флаг «Перезаписать существующую базу данных (WITH REPLACE)» (Overwrite the existing database) указывает, что операция восстановления перезапишет файлы любой базы данных, в настоящее время использующей имя, указанное в качестве базы данных назначения.
Флаг «Сохранить параметры репликации (WITH KEEP_REPLICATION)» (Preserve the replication settings) сохраняет настройки репликации при восстановлении опубликованной базы данных на сервере, отличном от сервера, на котором была создана база данных. Этот параметр имеет значение, только если во время создания резервной копии проводилась репликация базы данных.
Флаг «Ограничение доступа к восстановленной базе данных (WITH RESTRICTED_USER)» (Restrict access to the restored database) ограничит доступ к базе данных, за исключением пользователей с правами db_owner, dbcreator или sysadmin. Данный параметр имеет смысл использовать, например, если необходимо последовательно восстановить базу из нескольких файлов резервных копий, и доступ пользователей необходимо ограничить до завершения всех операций по восстановлению данных.
Если оставить флаг «Создание резервной копии заключительного фрагмента журнала перед восстановлением» (Take tail-log backup before restore) то будет создана резервная копия заключительного фрагмента журнала транзакций. Если для точки во времени, выбранной в окне «Временная шкала резервного копирования» (Backup Timeline) требуется резервная копия заключительного фрагмента журнала, этот флажок будет установлен и снять его будет нельзя.
Флаг «Закрыть существующие соединения» (Close existing connections option) переводит базу данных в однопользовательский режим перед началом выполнения процедуры восстановления, а затем возвращает в многопользовательский режим после ее завершения.
Ну и наконец, флаг «Выдавать приглашение перед восстановлением каждой резервной копии» ( Prompt before restoring each backup ) указывает, что после восстановления каждой резервной копии будет выводиться диалоговое окно с вопросом, нужно ли продолжать последовательность восстановления. Этот параметр позволяет приостанавливать последовательность восстановления после восстановления каждой резервной копии. Он будет полезен, например, когда нужно поменять ленты в устройстве, если на сервере имеется только одно ленточное устройство.

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

2. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Сформировавшийся отчет содержит в себе следующие данные:

Среднее время, затрачиваемое на операции резервного копирования (Average Time Taken For Backup Operations)
Успешные операции резервного копирования (Saccessful Backup Operations)
Ошибки операции резервного копирования (Backup Operation Errors)
Успешные операции восстановления (Saccessful Restore Operations)

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

Смотрите также:

Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…

Системная база данных tempdb служит рабочим пространством для хранения временных объектов, таких как временные таблицы, промежуточные результаты вычислений, временные хранимые процедуры, результаты буферов и сортировки, внутренние объекты, создаваемые компонентой Database…

Ниже будет подробно рассказано о том, как создать резервную копию базы данных в MS SQL Server 2012. В младших версиях (например в MS SQL Server 2008) алгоритм получения резервной копии…

Читайте также: