Ms sql восстановление базы данных из bak

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

Приветствую, в данной заметке будет рассмотрено создание резервных копий и восстановление в MS SQL Server

Создание резервных копий

1 Резервное копирование системных баз данных.

2 Полное резервное копирование базы данных.

3 Разностное резервное копирование базы данных.

4 Резервное копирование журнала транзакций базы данных.

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

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

6 Восстановление из полной резервной копии.

7 Восстановление из разностной резервной копии.

8 Восстановление журнала транзакций.

9 Восстановление файловых групп.

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

Создадим нашу тестовую базу данных “sbase”, модель восстановления — полная:

Создание резервных копий

1Резервное копирование системных баз данных.

Список системных баз: master, model, msdb, tempdb.

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

Model: Используется в качестве шаблона для создаваемых баз данных. Резервное копирование необходимо при изменении настройки самой базы model.

Msdb: Содержит сведения о заданиях и для агента сервера MS SQL Server. копирование необходимо делать каждый раз при добавлении задания для агента сервера MS SQL Server.

Tempdb: Хранит временные данные например для транзакций. Уничтожается и создается при перезапуске экземпляра MS SQL Server. Резервное копирование делать нет смысла.

Создадим новый запрос:

Выполним следующий запрос:

BACKUP DATABASE master

TO DISK = ‘C:sqlmaster.bak’

BACKUP DATABASE model

TO DISK = ‘C:sqlmodel.bak’

BACKUP DATABASE msdb

TO DISK = ‘C:sqlmsdb.bak’

Как видим, на диск ‘C’ было произведено успешное резервное копирование системных баз данных.

2Полное резервное копирование базы данных.

Включает в себя файлы данных и журнал транзакций. По сути является базой данных на момент создания резервной копии базы данный MS SQL Server.

Включает в себя:

Резервное копирование данных в базе.

Резервное копирование изменений, возникающих во время резервного копирования

Резервное копирование транзакций, не зафиксированных в журнале транзакций.

Способ 1(Графический интерфейс):

Выберем «создать резервную копию»

Указываем куда копировать и модель – полная.

Способ 2(Запрос SQL):

BACKUP DATABASE sbase

TO DISK = ‘C:sqlsbase.bak’

3 Разностное резервное копирование базы данных.

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

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

При создании разностного резервного копирования выполняются следующие действия:

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

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

—Создадим таблицу test

CREATE TABLE test(

INSERT INTO test (id,name)

Далее по аналогии с полным запустим задачу резервного копирования, но модель выберем – разностную:

Проведем полный бэкап, добавим еще данных, проведем разностный бэкап:

—Делаем полный бэкап

BACKUP DATABASE sbase

TO DISK = ‘C:sqlsbase_razh2’

—Добавим еще данные

INSERT INTO test (id,name)

BACKUP DATABASE sbase

TO DISK = ‘C:sqlsbase_razh3’

А вот и результат:

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

4 Резервное копирование журнала транзакций базы данных.

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

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

В процессе выполняются следующие действия:

Создается копия журнала транзакций от последнего резервного копирования лога до конца текущего.

Очищаются части журнала транзакций до начала активной части и отбрасываются сведения в неактивной части.

По аналогии с полным и разностным копированием запускаем задачу, но тип выбираем – лог транзакций:

Или с помощью запроса:

BACKUP LOG sbase

TO DISK = ‘C:sqlsbase_tran.bak’

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

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

Файлы журналов не входят в состав файловых групп.

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

Пример полного копирования:

По аналогии с другими видами копирования запускаем мастер:

Тоже, только запросом:

BACKUP DATABASE sbase

TO DISK = ‘C:sqlprimary.bak’

Про восстановление можно почитать на русском языке :

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

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

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

Режим WITH RECOVERY включает и стадию повтора, и стадию отката и восстанавливает базу данных. Более поздние резервные копии восстановить невозможно. Это значение по умолчанию.Если набор данных наката не был восстановлен в достаточной степени, чтобы обеспечить согласованность с базой данных, стадия отката выполнена быть не может. Компонент Database Engine выдает ошибку и прекращает восстановление. Если весь набор данных наката согласован с базой данных, то выполняется восстановление, после чего базу данных можно перевести в режим в сети.

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

6 Восстановление из полной резервной копии.

Или с помощью запроса:

RESTORE DATABASE sbase

7 Восстановление из разностной резервной копии.

В начале восстанавливается полная копия(например в прошлом шаге мы это уже сделали), а далее восстановим разностную копию.

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

RESTORE DATABASE sbase

FROM DISK = ‘C:sqlsbase_razh2’

WITH FILE = 1, NORECOVERY, REPLACE

RESTORE DATABASE sbase

FROM DISK = ‘C:sqlsbase_razh3’

WITH FILE = 1, RECOVERY

8 Восстановление журнала транзакций.

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

Графический вариант интуитивно понятен, будет продемонстрирован только SQL запрос:

Для того, чтоб все отработало корректно, вернемся разностному бэкапу 2, и после него накатим журнал транзакций:

RESTORE DATABASE sbase

FROM DISK = ‘C:sqlsbase’

WITH FILE = 1, NORECOVERY, REPLACE

RESTORE DATABASE sbase

FROM DISK = ‘C:sqlsbase_razh2’

WITH FILE = 1, NORECOVERY, REPLACE

RESTORE LOG sbase

FROM DISK = ‘C:sqltran.bak’

WITH FILE = 1, NORECOVERY

9 Восстановление файловых групп.

Графический вариант показан не будет, он довольно интуитивен, запрос SQL:

RESTORE DATABASE sbase FILEGROUP = ‘PRIMARY’

FROM DISK = ‘C:sqlprimary.bak’

WITH PARTIAL, RECOVERY, REPLACE

Так как мы восстанавливали только часть базы – файловую группу, то мы использовали параметр «PARTIAL».

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

Если экземпляр SQL сервера доступен, то системные базы восстанавливаются согласно приведенной таблице:

Системная база данных

Запускаем экземпляр сервера в однопользовательском режиме. Восстановление базы осуществляется так же, как полное восстановление пользовательской базы данных. После восстановления следует перезапустить экземпляр SQL сервера.

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

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

Запускаем экземпляр сервера в однопользовательском режиме: выключим и включим экземпляр сервера с параметром запуска /m, введя в командной строке Windows (CMD):

net stop MSSQLSERVER

net start MSSQLSERVER /m

Подключимся к серверу и запустим процесс восстановления базы.

sqlcmd

RESTORE DATABASE master FROM DISK = ‘C:sqlsbase.bak’ WITH REPLACE;

GO

Вернем экземпляр SQL в состояние «в сети».

Стартуем сервер в многопользовательском режиме:

net start MSSQLSERVER

На этом – все, желаю удач.

Если Вы хотите обменяться ссылками со мной между сайтами — пишите в контактах

Восстановление базы 1С из бэкапа MS SQL

Модели восстановление базы данных в MS SQL существует две «простая» и «полная». Отличаются они тем, что в полной модели восстановления ведется еще и бэкап журнала транзакций. Рассмотрим восстановление базы 1С в MS SQL на примере простой модели восстановления.

Бэкапы баз данных MS SQL хранятся в файлах с расширением .bak. Сами бэкапы баз тоже бывают двух типов: полный бэкап и разностный бэкап. В полном бэкапе содержится полная копия базы данных, а в разностном только изменения внесенные в базу с момента полного бэкапа.

Восстанавливаем полный бэкап.

В Microsoft SQL Server Managment Studio создаем базу данных в которую будет выполнятся восстановление. Как настроить базу в MS SQL для 1С рассмотренно здесь.

Выбираем созданную базу и в контекстном меню переходим Задачи — Восстановить — База данных.

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

Слева в меню «Выбор страницы» переходим к пункту «Параметры». В пункте параметры восстановления отмечаем «Перезаписать существующую базу данных (WITH REPLACE)».

Если восстанавливаете только полный бэкап, то в разеде состояние восстановления оставляем пункт «Оставить базу готовой к использованию»

Если далее планируется восстанавливать еще и разностный бэкап, то в разеде состояние восстановления отмечаем «Оставить базу данных в неработающем состоянии…».

Жмем ОК и дожидаемся сообщения о завершении восстановления.

Восстанавливаем разностный бэкап.

Снова в целевой базу данных выбираем из контекстного меню Задачи — Восстановить — База данных.

Указываем источник восстановления. Выбираем файл .bak разностного бэкапа.

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

Жмем ОК, дожидаемся завершения и переходим к добавлению базы на сервер 1С.

Добавляем базу на сервер 1С.

Запускаем в 1С настройку добавление информационной базы и выбираем пункт «Создание новой информационной базы»

На следующем шаге должен быть отмечен пункт «Создание информационной базы без конфигурации..»

Вписываем имя базы и указываем тип расположения информационной базы «На сервере 1С предприятия»

Указываем настройки для подключения к базе сервера MS SQL

Далее оставляем настройки как есть и жмем Готово. База добавлена — запускаем 1С и проверяем работоспособность.

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

Раннее я уже писал о создании резервных копий в 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).

Слева, в обозревателе объектов (Object Explorer), раскрываем вкладку «Базы данных» (Server Oblects), находим в списке базу данных из которой (или в которую) необходимо восстановить данные, кликаем по ней правой кнопкой мыши, затем в появившемся контекстном меню выбираем «Задачи» (Tasks) — «Восстановить» (Restore) — «База данных…» (Database…)

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

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

Затем необходимо выбрать базу данных назначения (Destination for restore), т. е. ту информационную базу в которую будут загружаться данные. Эта может быть как база с которой делалась резервная копия, так и любая другая база данных, зарегистрированная на текущем экземпляре SQL Server.

Нажав кнопку «Временная шкала…» (Timeline) можно указать время на которое необходимо восстановить данные. При имеющейся копии журнала транзакций время восстановления можно выбрать с точностью до секунды (или имеющегося checkpoint’а в журнале транзакций).

Очень важно (!) также помнить о том, что если восстановление данных осуществляется в информационную базу отличную от той с которой производилось резервное копирование (т. е. необходимо скопировать базу данных) то на вкладке «Файлы» (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. Просмотр информации о событиях резервного копирования и восстановления для базы данных

Для того чтобы узнать, когда производилось создание резервных копий конкретной базы данных, а также восстановление базы данных из резервной копии, можно воспользоваться стандартным отчетом «События резервного копирования и восстановления» (Backup and Restore Events). Для формирования данного отчета необходимо в Обозревателе объектов (Server Oblects) кликнуть правой кнопкой мыши по соответствующей базе данных, в контекстном меню выбрать «Отчеты» (Reports) — «Стандартный отчет» (Standart Reports) — «События резервного копирования и восстановления» (Backup and Restore Events).

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

• Среднее время, затрачиваемое на операции резервного копирования (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) алгоритм получения резервной копии…

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

В этой статье мы рассмотрим, как настроить резервное копирование баз данных в 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.NODE2MSSQLBackupTestDatabase2_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.NODE2MSSQLBackupfull.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N’E:MSSQL15.NODE2MSSQLBackuptrans.bak’ WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
RESTORE LOG [TestDatabase2] FROM DISK = N’E:MSSQL15.NODE2MSSQLBackuptrans.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