Ms sql как восстановить базу из бэкапа в другую базу

PROИТ

Office 365, AD, Active Directory, Sharepoint, C#, Powershell. Технические статьи и заметки.

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-скрипт:

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

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

26.02.2020
insci
SQL Server
комментариев 16

В этой статье мы рассмотрим, как настроить резервное копирование баз данных в 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.

Выберите базу данных. В окне появится список резервных копий, зарегистрированных в SQL Server для этой базы данных.

Для примера, воспользуемся 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

Рекомендации и best practice по резервному копированию SQL Server

• Резервные копии не должны храниться на том же диске, что и ваш SQL Server. Это правило касается любых резервных копий. При выходе из строя основного дискового массива вы должны иметь доступ к вашим резервным копиям. Если позволяют ресурсы, лучше хранить резервные копии сразу на нескольких разрозненных массивах.
• Процесс резервного копирования должен минимально влиять на работу пользователей. Полные резервные копии лучше делать тогда, когда пользовательская активность на сервере минимальна.
• Регулярно проверяйте целостность резервных копий и проводите тестовые восстановления. Вы всегда должны быть уверены, что ваши бекапы валидны и готовы к восстановлению в любое время.
• Заранее рассчитайте время, необходимое для полного восстановления при аварии. Часто в базах хранится критически важная для бизнеса информация, поэтому ваш руководитель должен знать минимальное время, которое потребуется для восстановления после аварии. Если даже вас об этом не спрашивают, лучше заранее уведомить об этом, чтобы в случае аварии не возникло недопонимания.

Предыдущая статья Следующая статья

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

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

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

В Обозревателе объектов разверните дерево сервера, нажав на имени сервера. Раскройте узел «Базы данных» и выберите из раскрывающегося списка базу данных для восстановления, нажмите по ней правой кнопкой мыши и в появившемся контекстном меню выберите «Задачи» — команду «Восстановить» — «База данных…».

Запустится Мастер восстановления базы данных.
Чтобы указать источник и расположение восстанавливаемых резервных наборов данных, выберите вариант «Устройство».

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

После добавления устройства в список «Расположение резервной копии» нажмите «OK» для возвращения на вкладку «Общие».

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

В поле «Восстановить в» оставьте значение по умолчанию «Последняя созданная резервная копия».

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

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

Для просмотра или выбора дополнительных параметров нажмите на вкладку «Параметры» на панели «Выбор страницы». При необходимости здесь можно указать любые из следующих параметров, подходящих к ситуации:

• переписать существующую базу данных;
• сохранить настройки репликации;
• ограничить доступ к восстановленной базе данных.

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

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

Восстановление bak базы sql в другую базу?

И запроси у начальства курсы по обучению пользованием гугля.

(0) Да можно.
Имя базы при восстановлении СМЕНИ!
Ну так SQL робит 🙂

Восстановление SQL
1. Создать новую базу, любого имени (Лучше правлильного)
2. Сперва при восстановлении, открываешь третью вкладку (их тама в окне 3)
Ставишь галки (Закрывать соединение и Перезаписать существующие данные)
. Почему с третьей? — Потому что эти галки блокируются, при выборе файла. В некоторых случаях.
3. Открываешь первую вкладку и выбираешь восстановить из файла
а. Выбираешь файл
б. У тебя после выбора файла, имя базы сменится на то имя базы с которой делался бекап. Смени имя на то, что тебе надо (это просто выбор из списка)
4. Перейди на вкладку 2 и укажи галочку (Переместить файлы и заменить — для страховки)
Укажи нужные каталоги для нужных файлов- там их два Данные и Лог, трудно перепутать.
5. Восстанавливай, все ок. получится.

6. Если будет ошибка, то закрывай окно восстановления и открывай его повторно, SQL привередлив, любит все новое 🙂