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

Содержание

Восстановление базы данных из резервной копии в 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 SQL Server 2012
Ниже приведена пошаговая инструкция, показывающая как добавить новую базу данных в Microsoft SQLServer 2012 (в более старых редакциях, например в Microsoft SQL Server 2008 R2, набор действий аналогичен). Запускаем…
Перемещение базы данных tempdb в MS SQL Server 2012
Системная база данных tempdb служит рабочим пространством для хранения временных объектов, таких как временные таблицы, промежуточные результаты вычислений, временные хранимые процедуры, результаты буферов и сортировки, внутренние объекты, создаваемые компонентой Database…

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

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

Обширный функционал Bacula Enterprise Edition, помимо прочего, позволяет быстро и просто создавать бэкапы БД под Windows. Например, речь идет об инструменте, с помощью которого можно осуществлять резервное копирование MS SQL Server. Сделать бэкап MS SQL пользователь может, создавая резервные копии специфических баз данных MS SQL больших объемов, используемых платформой Windows, при меньших затратах на ПО сторонних производителей, с возможностью восстановления данных до определенного момента времени (PITR-восстановление) на сетевой и локальный диск.

Скрипт Bacula Systems для создания бэкапов MS SQL Server характеризуется крайней эффективностью, достигаемой за счет реализации современной, высоконадежной архитектуры. Более того, ПО позволяет сделать бэкап MS SQL Server, использовать самые различные возможности по созданию резервных копий MS SQL.

Скрипт бэкапа MS SQL Bacula Systems функционирует независимо от VSS. Это значит, что инструмент резервного копирования MS SQL не использует снапшоты VSS для создания бэкапов. Поэтому пользователь может задать следующее значение “Enable VSS = no” в Bacula FileSet. Эффективное создание бэкапов MS SQL Server и их восстановление с помощью данного решения достигаются за счет использования Microsoft API для SQL Server. Благодаря этому Bacula Systems может поддерживать работу механизмов обеспечения защиты и все типы проверки подлинности, реализованные в Microsoft SQL Server.

Резервное копирование журнала транзакций MS SQL и восстановление MS SQL на момент времени: ПО Bacula Enterprise Edition позволяет восстанавливать блоки данных MS SQL или конкретные настройки до определенного момента времени. Благодаря реализации моделей полного восстановления и восстановления с неполным протоколированием вы сможете восстанавливать MS SQL, используя PITR-восстановление, либо использовать LSN для восстановления системы до конкретного состояния. Вы можете восстанавливать определенное состояние базы данных MS SQL на любой конкретный момент времени с точностью до секунды. В случае бэкапа журнала транзакций MS SQL, при восстановлении состояние БД будет восстанавливаться из различных выбранных бэкапов.

Краткий обзор функций  автоматического бэкапа и восстановления MS SQL с Bacula Enterprise

Компания Bacula Systems создала плагин для резервного копирования MS SQL Server для совместного использования с Bacula Enterprise Edition. Бэкап MS SQL Server с Bacula обладает следующими функциями:

Поддержка полного и дифференциального резервного копирования MS SQL
Поддержка инкрементального резервного копирования MS SQL
Резервное копирование MS SQL на сетевой и локальный диск
Резервное копирование MS SQL по расписанию
Создание бэкапов на уровне базы данных MS SQL Server
Возможность включать/исключать БД из процедуры создания бэкапов
Поддержка создания бэкапов БД «только для чтения»
Восстановление MS SQL бэкапов на диск
Отправка потока резервной копии напрямую в Storage Daemon
Восстановление MS SQL на момент времени

Обзор и настройка резервного копирования MS SQL 2008, 2008 R2, 2012 и 2014

В данном документе представлены решения для Bacula Enterprise Edition 8.4 и более поздних версий, которые не поддерживаются ранними версиями ПО. Резервное копирование базы MS SQL был протестировано и поддерживается MS SQL 2003 R2, MS SQL 2008 R2, MS SQL 2012, MS SQL 2005, MS SQL 2008, MS SQL 2014. Возможна работа резервного копирования MS SQL от Bacula с SQL Express.

Глоссарий резервного копирования MS SQL 2008, 2008 R2, 2012 и 2014

MS SQL означает Microsoft SQL Server.
Журнал транзакций (transaction log). Любая база данных MS SQL Server имеет журнал транзакций, в который записываются все транзакции и модификации БД, выполненные в ходе таких транзакций. Журнал транзакций – важный элемент БД. В случае отказа системы журнал транзакций может потребоваться для восстановления БД до рабочего состояния. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms190925.aspx.
Дифференциальное резервное копирование базы данных MS SQL Server. Дифференциальный бэкап основан на последнем полном бэкапе БД. В ходе выполнения дифференциального бэкапа захватываются только те данные, которые были изменены с момента создания последнего полного бэкапа. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en- us/library/ms175526.aspx.
Полное резервное копирование базы данных MS SQL Server. В ходе полного бэкапа БД создается резервная копия всей базы данных. Бэкап включает часть журнала транзакций с целью восстановления полной БД из резервной копии. Полные бэкапы БД содержат БД на момент завершения создания резервной копии. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en- us/library/ms186289.aspx.
Бэкап «только для копирования» (CopyOnly). Бэкапы «только для копирования» представляют собой бэкапы MS SQL, независящие от обычной последовательности создания традиционных резервных копий SQL Server. Иногда полезно создавать бэкапы для особых нужд, не влияя на общий процесс резервного копирования и восстановления БД. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms191495.aspx.
VDI (Интерфейс виртуального устройства) – это технология Microsoft, позволяющая создавать именованный канал между программами.
<glob> стандартные маски задают наборы строк с подстановочными знаками. Например, стандартная маска production* будет включать строки production1 и production2.
<str> строка
<bytes> целое число.
LSN Каждая запись в журнале транзакций MS SQL Server обозначается с помощью уникального регистрационного номера транзакции (LSN). Более подробную информацию вы найдете по ссылке https://technet.microsoft.com/en-us/library/ms190411%28v=sql.105%29.aspx.

Резервное копирование MS SQL Server 2008, 2008 R2, 2012 и 2014

Полное резервное копирование баз данных MS SQL Server 2008, 2008 R2, 2012 и 2014

В ходе полного резервного копирования базы данных MS SQL сохраняются файлы БД и журнал транзакций, что позволяет полностью защитить базу MS SQL на случай отказа носителя. В случае повреждения одного или более файлов восстановление базы MS SQL из бэкапа позволит восстановить все совершенные транзакции. Также будет произведен откат всех транзакций, находившихся в процессе выполнения. В данном режиме производится создание бэкапов БД master и mbdb.

Дифференциальное резервное копирование баз данных MS SQL Server 2008, 2008 R2, 2012 и 2014

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

Резервное копирование журнала транзакций MS SQL 2008, 2008 R2, 2012 и 2014

Функция создания бэкапа журнала транзакций MS SQL реализуется на инкрементальном уровне с помощью ПО Bacula. БД MS SQL должна быть сконфигурирована с помощью моделей полного восстановления и восстановления с неполным протоколированием. Если MS SQL использует простую модель восстановления, файл журнала транзакций будет «урезаться» после каждой контрольной точки, и бэкап журнала транзакций не позволит реализовать восстановление до выбранной конкретной точки, т.е. PITR-восстановление. Можно будет восстановить базу данных MS SQL полностью, но нельзя будет выбрать контрольную точку. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms189275.aspx.

Настройка резервного копирования MS SQL и конфигурирование БД

Необходимо всегда создавать резервную копию БД master. Если БД master будет так или иначе повреждена, например, в результате отказа носителя, возможно, не получится запустить инстанс MS SQL. В таком случае, необходимо восстановить БД master, и только потом восстановить из резервной копии саму БД. Возможно создание только полных бэкапов базы MS SQL. Более подробную информацию вы найдете по ссылке https://technet.microsoft.com/en-s/library/aa213839%28v=sql.80%29.aspx.

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

Вы можете использовать все стандартные способы запуска процедуры восстановления базы MS SQL из бэкапа. Однако вы должны убедиться в том, что, в случае восстановления дифференциальных данных, будет также восстановлен полный предыдущий бэкап базы MS SQL. В таком случае восстановление происходит автоматически, если вы запускаете его в консоли bconsole с помощью вариантов восстановления 5 или 12. В сгенерированной файловой структуре вам необходимо отметить восстановление полных БД или инстансов БД.

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

ПО Bacula Enterprise Edition позволяет пользователям использовать множество вариантов восстановления MS SQL и применять самые различные способы «отката» БД. Наиболее часто используемые варианты восстановления описаны ниже:

параметр Where: В случае с Bacula Enterprise Edition, данный параметр позволяет администратору восстанавливать БД в конкретном месте.
параметр Replace: Используется для того, чтобы определить, как ПО Bacula должно вести себя с текущей БД при восстановлении. Резервное копирование MS SQL от Bacula также позволяет использовать еще несколько опций при восстановлении, например:
Instance: Поскольку MS SQL использует несколько инстансов, бэкап базы MS SQL от Bacula позволяет выбирать, какой из инстансов следует восстанавливать. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа. По умолчанию, используется инстанс с именем “MSSQLSERVER”.
Database. Данная опция указывает имя БД для восстановления и она использует значение, заданное в момент создания БД. Данный параметре является опциональным. По умолчанию резервное копирование баз данных SQL Server использует параметр Where для определения имени новой БД. Если обоим параметрам Where и Database назначены валидное имя БД, то параметр Database будет использоваться.
User. Имя пользователя, используемое для подключения к инстансу базы данных MS SQL. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа.
Password. Пароль, используемый для подключения к инстансу базы данных MS SQL. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа.
Domain. Домен, используемый для подключения к инстансу базы данных MS SQL. Данный параметр является опциональным, и, если он не задан, при восстановлении будет использоваться значение, заданное при создании бэкапа.
Recovery. Параметр позволяет определить, будет ли произведен откат БД к предыдущему состоянию при восстановлении или нет. По умолчанию при восстановлении БД будет произведет откат к предыдущему состоянию.
Stop_before_mark. Условие WITH STOPBEFOREMARK = <point> используется для того, чтобы указать, что запись в журнале транзакций, которая находится непосредственно перед флагом, и является точкой восстановления. Точкой восстановления может служить дата и время, номер LSN или имя флага mark_name.
Stop_at_mark. Условие WITH STOPATMARK =<point> используется для того, чтобы показать, что помеченная транзакция является точкой восстановления. STOPATMARK перемещается вперед к флагу и включает повтор помеченной транзакции. Точкой восстановления может служить дата и время, номер LSN или имя флага mark_name.
Stop_at=<datetime>. Условие WITH STOPAT = <datetime> используется для того, чтобы указать, что точкой восстановления является дата/время.
Restrict_user. Условие WITH RESTRICT_USER используется для ограничения доступа к восстановленной БД. По умолчанию используется значение no.

В программе BWeb Management Suite, созданной Bacula Systems, настройка резервного копирования MS SQL находятся на вкладке восстановления.

Рисунок 1: Вкладка восстановления БД при использовании программы BWeb Management Suite

Восстановление MS SQL на момент времени

Данный вопрос относится только к тем БД SQL, которые используют модели полного восстановления и восстановления с неполным протоколированием. В случае модели восстановления с неполным протоколированием, если бэкап журнала содержит изменения, сделанные во время операций массовой обработки данных, то невозможно будет выполнить восстановление на какой-либо момент времени в пределах этого бэкапа. БД должна быть восстановлена до конца журнала транзакций, бэкап которого был создан. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms179451.aspx.

Восстановление MS SQL на момент времени можно совершать непосредственно из плагина бэкапа MS SQL. Также можно восстанавливать файлы локально и выполнять операции из консоли управления Microsoft SQL Server Mangement Console, чтобы иметь возможность использовать больше возможностей.

LSN

LSN номера используются для создания последовательности восстановления MS SQL с целью отслеживания момента времени, до которого данные были восстановлены. При восстановлении MS SQL из бэкапа данные восстанавливаются до LSN номера, соответствующего моменту времени, в который был выполнен бэкап. Более подробную информацию вы найдете по ссылке https://msdn.microsoft.com/en-us/library/ms190925.aspx.

LSN номер записи в журнале, в момент которой возникло конкретное событие по созданию бэкапа и восстановлению, можно просмотреть одним из следующих способов:

При выводе описания заданий по созданию бэкапа с помощью ПО Bacula
В названии файла журнала
В таблице msdb.backupset
В таблице msdb.backupfile

При выполнении задания по созданию бэкапа базы MS SQL при выводе описания задания отобразится следующая информация о LSN номерах:

Номер First LSN соответствует последнему LSN номеру последнего бэкапа журнала транзакций. Таким бэкапом может являться самый первый полный бэкап или последний бэкап (инкрементальный).

Номер Last LSN соответствует последней транзакции, зарегистрированной в журнале.

В случае бэкапа журнала транзакций (инкрементального), название файла, связанного с этой БД, в задании по созданию инкрементального бэкапа будет выглядеть следующим образом:

Число в названии, в нашем случае 42000162001, соответствует последнему LSN номеру предыдущего задания (по созданию полного или инкрементального бэкапа).

Рисунок 2: Первый номер LSN, последний номер LSN и номера LSN в названии файлов

Как показано в примере на рисунке 2, если администратору необходимо восстановить базу данных MS SQL в состояние, соответствующем LSN номеру 14, можно выполнить следующие действия:

В меню восстановления БД используйте опцию 5
Выберите директорию БД “/@mssql/db29187”
Выберите последний файл полного бэкапа “data.bak” (LSN: 10)
Выберите инкрементальный бэкап “log-10.trn”
Задайте параметр stop_at_mark равный “lsn:14”
Запустите задачу по восстановлению бэкапа

Или, если последний полный бэкап MS SQL Server не доступен, однако доступен предыдущий полный бэкап, то:

Используйте опцию восстановления 3, выберите соответствующие значения jobids
Выберите директорию БД “/@mssql/db29187”
Выберите файл полного бэкапа “data.bak” (LSN: 2)
Выберите инкрементальные бэкапы “log-2.trn”, “log-3.trn”, “log-10.trn”
Задайте параметр stop_at_mark равный “lsn:14”
Запустите задачу по восстановлению бэкапа

Сценарии восстановления MS SQL

Описание	Where	Database	Пример
Восстановить файлы на диск	Путь		where=c:/tmp
Восстановить исходную БД			where=/
Восстановить с новым именем	Имя		where=newdb
Восстановить с новым именем		Имя	database=newdb
Восстановить с новым именем и переместить файлы		Имя	where=c:/tmp database=newdb

Таблица 1: Сценарии восстановления MS SQL

2.3.1 Восстановление базы MS SQL с исходным именем

Чтобы восстановить БД с исходным именем, параметр Where должен быть не задан (пустое значение), либо должно быть задано значение “/”, а параметру Replace должно быть присвоено значение Always, или же сначала необходимо удалить исходную БД.

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

Чтобы восстановить бэкап базы данных MS SQL с новым именем, возможно, сначала потребуется переместить файлы БД на диск. Все зависит от того, существует ли еще исходная БД.

Если исходная БД более не доступна, то параметр where, либо поле “Plugin Options” может содержать название новой БД. Резервное копирование MS SQL от Bacula автоматически создаст БД с новым именем.

Если исходная БД все еще пока требуется, параметр where будет использоваться для перемещения файлов на диск, и необходимо будет задать название новой БД с помощью меню “Plugin Options”. В дереве восстановления необходимо выбрать файл layout.dat.

Используя каталог My Catalogue

Запустите задачу восстановления MS SQL:

Используя каталог My Catalogue, запустите задачу восстановления базы MS SQL:

Восстановление MS SQL на локальный диск

Если указать where=c:/path/, файлы будут восстановлены на локальный диск, и администратор базы данных MS SQL сможет использовать процедурное расширение TSQL для консоли управления Microsoft SQL Server Mangement Console для восстановления БД. Команды SQL, необходимые для восстановления БД, перечислены в описании Job output как показано на рисунке ниже.

Восстановление базы данных MS SQL «master»

Инструкции по восстановлению БД “master” подробно изложены на странице: https://technet.microsoft.com/en-us/library/aa213839%28v=sql.80%29.aspx

База данных MS SQL в состоянии восстановления

По завершению восстановления MS SQL, если опциональному параметру Recovery было присвоено значение No, восстановленная БД будет находиться в состоянии «восстановления». Чтобы завершить процесс восстановления, необходимо запустить процедуру отката БД. Для этого используйте следующую команду SQL:

Автоматизированное восстановление баз данных MS SQL из бэкапов

В этой статье я хотел бы рассказать о том, как с помощью утилиты Quick Maintenance & Backup for MS SQL настроить автоматическое восстановление баз данных из бэкапов на тестовом экземпляре SQL Server в сети. При этом создавать бэкапы будет штатный План обслуживания. Потребность в автоматизированном восстановлении может возникнуть в следующих случаях:

Если требуется регулярно актуализировать базы данных на тестовых серверах.

Если требуется периодически проверять через восстановление созданные бэкапы: полный, разностный и журналы транзакций.

В сети можно найти примеры скриптов позволяющие в той или иной мере автоматизировать эти задачи. Но большинство решений требуют хорошего понимания T-SQL, предметной области и скорее всего потребуют изменения ваших Планов обслуживания. Я покажу как это сделать за 15-20 минут с помощью утилиты Quick Maintenance & Backup for MS SQL (QMB). Мы задействуем механизм XML планов восстановления — это XML файл с последовательностью бэкапов, который умеет создавать утилита. По информации в XML файле программа получит последовательность бэкапов, сформирует T-SQL скрипт для восстановления и запустит его на выполнение. Подробнее об этой возможности можно почитать здесь.

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

Задача

Итак, допустим имеется рабочий 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) смог выполнить восстановление он должен иметь доступ к файлам бэкапов. Тут возможны два варианта:

Расшарить папку F:\MS SQL\Backup на Srv01 так чтобы она была доступна на London.

С помощью QMB копировать бэкапы в общую сетевую папку, которая доступна на London.

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

Общий порядок действий

Итак, нам потребуется проделать следующие шаги:

Настроить общую сетевую папку

Установить утилиту QMB

Настроить уведомления и зарегистрировать в программе два SQL Server: Srv01 и London.

Создать в программе две новых задачи:
- Создание XML плана восстановления на сетевом диске
- Восстановление по XML плану с сетевого диска

Создать в программе два сценария:
- Сценарий, на рабочем сервере Srv01, выполняющий создание XML плана восстановления в общей папке с копированием в неё файлов бэкапов. Старт каждый 1 час.
- Сценарий, на тестовом сервере London, выполняющий восстановление по XML плану из бэкапов, размещенных в общей папке. Старт каждый день в 23.00.

Ниже рассмотрим каждый шаг подробнее.

Установка QMB

Утилиту можно скачать тут. Пробный период — 30 дней.

Я поставил утилиту на тестовом сервере London. В общем случае программу можно установить на любом компьютере, работающем круглосуточно т.е. установка именно на SQL Server не обязательна. При установке программы оставляем все параметры по умолчанию. Инсталлятор установит службу QmbService и клиента.

Регистрация SQL Server и настройка уведомлений

При первом старте программы откроется мастер. Перейдем на следующий шаг и установим галку «Включить email-оповещения» и введем адрес электронной почты для получения уведомлений.

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

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

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

Жмем кнопку «Вперед».

Нам не требуется обслуживать базы данных поэтому на последней странице мы выберем «Создать пустой автономный сценарий». Затем снимем галку «Создать автономный сценарий для обслуживания системных баз данных» и нажмем кнопку «Завершить».

Программа зарегистрирует SQL Server и откроет форму нового пустого сценария.

Создание XML-плана восстановления

Любые задачи в программе исполняются в рамках сценариев. В окне нового автономного сценария ведем его имя Создание XML плана восстановления.
Добавим в сценарий задачу, которая будет создавать XML файл плана восстановления. Нажмем кнопку «Добавить». Откроется форма выбора задачи. Кликнем кнопку «Добавить новую задачу». Откроется форма новой задачи.
На форме нужно:

Изменить тип задачи на «Создание XML плана восстановления»

Создать новое подключение к общей папке. В моем случае это папка \\Server\Backup на файловом сервере.
Примечание: Для сети без домена имя пользователя необходимо указывать в формате: Компьютер\Пользователь

Выбрать базы данных которые войдут в XML план восстановления. В моем случае это три базы — Account2013, Account2014, Account2015.

Указать имя задачи — Создание XML плана для Account2013, Account2014, Account2015.

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

С удовольствием отвечу на ваши вопросы в комментариях или по электронной почте [email protected]

Спасибо за внимание!

Как восстановить базу данных Microsoft SQL из бэкапа

Как восстановить базу данных Microsoft SQL из бэкапа с помощью панели управления хостингом
Plesk?

Как восстановить базу данных Microsoft SQL из бэкапа, обратившись в службу технической
поддержки?

1. Как восстановить базу данных Microsoft SQL из бэкапа с помощью панели управления хостингом Plesk?

1.1. Убедитесь, что Вы предварительно создали базу данных Microsoft SQL, используя панель Plesk.
Подробнее читайте в инструкции Как создать базу данных Microsoft SQL в Plesk.

1.2. Зайдите в панель Plesk, используя предоставленные Вам учетные данные (примечание: данные на доступ к панели управления и адрес для входа в панель
управления высылались в письме о реализации заказа хостинга). После того, как у Вас отобразилась страница входа в
панель управления Plesk, введите имя пользователя и пароль и нажмите кнопку [Войти]:

1.3. После успешного входа нажмите [Базы данных]:

1.4. Откроется страница управления базами данных. Для базы данных, которую Вы хотите восстановить
из резервной копии (бэкапа), нажмите [Импортировать резервную копию]:

1.5. Откроется окно импорта (восстановления базы данных из бэкапа). Здесь возможны два варианта. Мы
рекомендуем использовать вариант № 2 (см. п. 1.5.2 настоящей инструкции):

1.5.1. Загрузка файла бэкапа и восстановление данных:

1.5.1.1. Нажмите [Обзор…] (или [Choose File]), затем выберите
файл бэкапа базы данных на локальном компьютере:

1.5.1.2. После этого нажмите [OK]:

1.5.1.3. Дождитесь загрузки файла бэкапа и восстановления данных. Мы не рекомендуем использовать
этот вариант, т.к. если загрузка файла бэкапа будет прервана, то для восстановления данных из бэкапа придется
загружать файл бэкапа повторно:

1.5.1.4. После того, как файл бэкапа будет загружен, и данные восстановлены, Вы увидите:

1.5.2. Восстановление данных из ранее загруженного по FTP файла бэкапа:

1.5.2.1. Предварительно загрузить файл бэкапа базы данных по FTP в папку
[/private] на хостинге. Как загружать файлы по FTP читайте в инструкции Как загрузить файлы сайта
на FTP-сервер.

1.5.2.2. В окне импорта (восстановления базы данных из бэкапа) нажмите
[Импортировать], затем выберите файл бэкапа базы данных на сервере и нажмите [OK]:

1.5.2.3. Дождитесь восстановления данных:

1.5.2.4. После того, как данные будут восстановлены, Вы увидите:

1.6. На этом восстановление базы данных MSSQL из бэкапа завершено.

2. Как восстановить базу данных Microsoft SQL из бэкапа, обратившись в службу технической
поддержки?

2.1. Создайте базу данных в Plesk, как описано в инструкции Как создать базу данных
Microsoft SQL в Plesk.

2.2. Создайте бэкап базы данных на локальном компьютере с помощью инструкции Как сделать бэкап
локальной базы данных Microsoft SQL.

2.3. Загрузите полученный файл бэкапа базы данных Microsoft SQL по FTP в папку
[/private] на хостинге. Как загружать файлы по FTP читайте в инструкции Как загрузить файлы сайта на
FTP-сервер.

2.4. Обратитесь в службу технической поддержки с просьбой восстановить базу данных Microsoft SQL из
бэкапа. При этом обязательно укажите следующую информацию:
2.4.1. Имя сайта, для которого выполняется восстановление базы данных Microsoft SQL;
2.4.2. Имя файла бэкапа, предварительно загруженного по FTP в папку [/private] на
[шаге 2.3] настоящей инструкции;
2.4.3. Имя базы данных (созданной в Plesk на [шаге 2.1] настоящей инструкции),
которая будет восстановлена из бэкапа.

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

Восстановление базы данных из резервной копии — Azure SQL Database & SQL Managed Instance

09/26/2019

Чтение занимает 10 мин

В этой статье

ОБЛАСТЬ ПРИМЕНЕНИЯ:
База данных SQL Azure
Управляемый экземпляр SQL Azure

Для восстановления базы данных доступны следующие параметры с помощью автоматически создаваемых резервных копий базы данных.The following options are available for database recovery by using automated database backups. Можно сделать следующее.You can:

Создайте новую базу данных на том же сервере, восстановленную до указанной точки во времени в течение срока хранения.Create a new database on the same server, recovered to a specified point in time within the retention period.
Создайте базу данных на том же сервере, восстановленную до времени удаления для удаленной базы данных.Create a database on the same server, recovered to the deletion time for a deleted database.
Создание новой базы данных на любом сервере в том же регионе, восстановленной до момента последнего резервного копирования.Create a new database on any server in the same region, recovered to the point of the most recent backups.
Создайте новую базу данных на любом сервере в любом другом регионе, восстановленную до момента последнего реплицированного резервного копирования.Create a new database on any server in any other region, recovered to the point of the most recent replicated backups.

Если вы настроили долгосрочное хранение резервных копий, можно также создать новую базу данных на основе любой долгосрочной резервной копии хранения на любом сервере.If you configured backup long-term retention, you can also create a new database from any long-term retention backup on any server.

Важно!

Невозможно перезаписать существующую базу данных во время восстановления.You can’t overwrite an existing database during restore.

Если вы используете уровень служб «Стандартный» или «Премиум», восстановление базы данных может привести к дополнительным затратам на хранение.When you’re using the Standard or Premium service tier, your database restore might incur an extra storage cost. Дополнительные затраты создаются, если максимальный размер восстанавливаемой базы данных превышает объем хранилища, включенный в уровень служб и производительности целевой базы данных.The extra cost is incurred when the maximum size of the restored database is greater than the amount of storage included with the target database’s service tier and performance level. Сведения о ценах на дополнительное хранилище см. на странице цен на Базу данных SQL.For pricing details of extra storage, see the SQL Database pricing page. Если фактический объем используемого пространства меньше, чем Включенный объем хранилища, можно избежать этой дополнительной платы, установив максимальный размер базы данных в включенном объеме.If the actual amount of used space is less than the amount of storage included, you can avoid this extra cost by setting the maximum database size to the included amount.

Время восстановленияRecovery time

Время восстановления базы данных с помощью автоматически создаваемых резервных копий зависит от ряда факторов.The recovery time to restore a database by using automated database backups is affected by several factors:

Размер базы данных.The size of the database.
Размер вычислений базы данных.The compute size of the database.
Количество задействованных журналов транзакций.The number of transaction logs involved.
Объем действий, которые необходимо воспроизвести для восстановления до точки восстановления.The amount of activity that needs to be replayed to recover to the restore point.
Пропускная способность сети, если восстановление происходит в другой регион.The network bandwidth if the restore is to a different region.
количество одновременных запросов на восстановление, обрабатываемых в целевом регионе.The number of concurrent restore requests being processed in the target region.

Для большой или очень активной базы данных восстановление может занять несколько часов.For a large or very active database, the restore might take several hours. В случае длительного простоя в регионе может быть инициировано большое количество запросов геовосстановления для аварийного восстановления.If there is a prolonged outage in a region, it’s possible that a high number of geo-restore requests will be initiated for disaster recovery. При наличии большого числа запросов время восстановления отдельных баз данных может увеличиться.When there are many requests, the recovery time for individual databases can increase. Большинство восстановлений баз данных завершается менее чем через 12 часов.Most database restores finish in less than 12 hours.

Для одной подписки существуют ограничения на количество одновременных запросов на восстановление.For a single subscription, there are limitations on the number of concurrent restore requests. Эти ограничения применяются к любому сочетанию восстановления на момент времени, георепликации и восстановления из резервной копии долгосрочного хранения.These limitations apply to any combination of point-in-time restores, geo-restores, and restores from long-term retention backup.

Параметр развертыванияDeployment option	Максимальное количество одновременно обрабатываемых запросовMax # of concurrent requests being processed	Максимальное количество одновременно отправляемых запросовMax # of concurrent requests being submitted
Отдельная база данных (на подписку)Single database (per subscription)	1010	6060
Эластичный пул (на пул)Elastic pool (per pool)	44	200200

Нет встроенного метода для восстановления всего сервера.There isn’t a built-in method to restore the entire server. Пример выполнения этой задачи см. в статье база данных SQL Azure: полное восстановление сервера.For an example of how to accomplish this task, see Azure SQL Database: Full server recovery.

Важно!

Чтобы выполнить восстановление с помощью автоматически создаваемых резервных копий, необходимо быть членом роли SQL Server участник или SQL Управляемый экземпляр участник (в зависимости от назначения восстановления) в подписке, или же вы должны быть владельцем подписки.To recover by using automated backups, you must be a member of the SQL Server Contributor role or SQL Managed Instance Contributor role (depending on the recovery destination) in the subscription, or you must be the subscription owner. Дополнительные сведения см. в статье Встроенные роли для управления доступом на основе ролей в Azure.For more information, see RBAC: Built-in roles. Восстановление можно выполнить с помощью портал Azure, PowerShell или REST API.You can recover by using the Azure portal, PowerShell, or the REST API. Нельзя использовать Transact-SQL.You can’t use Transact-SQL.

Восстановление на момент времениPoint-in-time restore

Вы можете восстановить изолированную базу данных, которая находится в пуле или экземпляре, до более ранней точки во времени с помощью портал Azure, PowerShellили REST API.You can restore a standalone, pooled, or instance database to an earlier point in time by using the Azure portal, PowerShell, or the REST API. Запрос может указывать любой уровень служб или размер вычислений для восстанавливаемой базы данных.The request can specify any service tier or compute size for the restored database. Убедитесь в наличии достаточного количества ресурсов на сервере, на котором выполняется восстановление базы данных.Ensure that you have sufficient resources on the server to which you are restoring the database.

По завершении инструкция RESTORE создает новую базу данных на том же сервере, что и исходная база данных.When complete, the restore creates a new database on the same server as the original database. В восстановленной базе данных оплаты начисляются по нормальным тарифам, исходя из уровня служб и размера вычислений.The restored database is charged at normal rates, based on its service tier and compute size. Плата не взимается, пока восстановление базы данных не будет завершено.You don’t incur charges until the database restore is complete.

Обычно база данных восстанавливается до более ранней точки во времени.You generally restore a database to an earlier point for recovery purposes. Восстановленную базу данных можно считать заменой исходной базы данных или использовать ее в качестве источника данных для обновления исходной базы данных.You can treat the restored database as a replacement for the original database or use it as a data source to update the original database.

Замена базы данныхDatabase replacement
Если восстанавливаемая база данных планируется заменить исходной базой данных, следует указать размер вычислений и уровень служб исходной базы данных.If you intend the restored database to be a replacement for the original database, you should specify the original database’s compute size and service tier. Затем можно переименовать исходную базу данных и присвоить восстановленной базе данных исходное имя с помощью команды ALTER DATABASE в T-SQL.You can then rename the original database and give the restored database the original name by using the ALTER DATABASE command in T-SQL.
Восстановление данныхData recovery
Если планируется получение данных из восстановленной базы данных для восстановления после ошибки пользователя или приложения, необходимо написать и выполнить сценарий восстановления данных, который извлекает данные из восстановленной базы данных и применяется к исходной базе данных.If you plan to retrieve data from the restored database to recover from a user or application error, you need to write and execute a data recovery script that extracts data from the restored database and applies to the original database. Несмотря на то, что операция восстановления может занять много времени, восстанавливаемая база данных будет отображаться в списке баз данных на протяжении всего процесса.Although the restore operation may take a long time to complete, the restoring database is visible in the database list throughout the restore process. Если удалить базу данных во время восстановления, операция восстановления будет отменена, и не будет взиматься дополнительная стоимость базы данных, которая не выполнила восстановление.If you delete the database during the restore, the restore operation will be canceled and you will not be charged for the database that did not complete the restore.

Восстановление до точки во времени с помощью портал AzurePoint-in-time restore by using Azure portal

Можно восстановить одну базу данных или экземпляр до точки во времени из колонки обзора базы данных, которую необходимо восстановить в портал Azure.You can recover a single or instance database to a point in time from the overview blade of the database you want to restore in the Azure portal.

База данных SQLSQL Database

Чтобы восстановить базу данных до точки во времени с помощью портал Azure, откройте страницу Обзор базы данных и на панели инструментов выберите восстановить .To recover a database to a point in time by using the Azure portal, open the database overview page and select Restore on the toolbar. Выберите источник резервного копирования и выберите точку резервного копирования на момент времени, из которой будет создана новая база данных.Choose the backup source, and select the point-in-time backup point from which a new database will be created.

Управляемый экземпляр SQLSQL Managed Instance

Чтобы восстановить базу данных управляемого экземпляра до точки во времени с помощью портал Azure, откройте страницу Обзор базы данных и выберите восстановить на панели инструментов.To recover a managed instance database to a point in time by using the Azure portal, open the database overview page, and select Restore on the toolbar. Выберите точку резервного копирования на момент времени, из которой будет создана новая база данных.Choose the point-in-time backup point from which a new database will be created.

Восстановление удаленной базы данныхDeleted database restore

Можно восстановить удаленную базу данных до времени удаления или более ранней точки во времени на том же сервере или в том же управляемом экземпляре.You can restore a deleted database to the deletion time, or an earlier point in time, on the same server or the same managed instance. Это можно сделать с помощью портал Azure, PowerShellили остальных (CreateMode = Restore).You can accomplish this through the Azure portal, PowerShell, or the REST (createMode=Restore). Чтобы восстановить удаленную базу данных, создайте новую базу данных из резервной копии.You restore a deleted database by creating a new database from the backup.

Важно!

При удалении сервера или управляемого экземпляра все его базы данных также удаляются и не могут быть восстановлены.If you delete a server or managed instance, all its databases are also deleted and can’t be recovered. Нельзя восстановить удаленный сервер или управляемый экземпляр.You can’t restore a deleted server or managed instance.

Восстановление базы данных удалено с помощью портал AzureDeleted database restore by using the Azure portal

Удаленные базы данных восстанавливаются из портал Azure из ресурса сервера или управляемого экземпляра.You restore deleted databases from the Azure portal from the server or managed instance resource.

База данных SQLSQL Database

Чтобы восстановить удаленную базу данных до времени удаления с помощью портал Azure, откройте страницу Обзор сервера и выберите Удаленные базы данных.To recover a deleted database to the deletion time by using the Azure portal, open the server overview page, and sele

Краткое руководство. Восстановление резервных копий (SSMS) — Azure SQL Managed Instance

12/14/2018

Чтение занимает 2 мин

В этой статье

ОБЛАСТЬ ПРИМЕНЕНИЯ:
Управляемый экземпляр SQL Azure

В этом кратком руководстве показано, как использовать SQL Server Management Studio (SSMS) для восстановления базы данных (Wide World Importers — стандартный файл резервной копии) из Хранилища BLOB-объектов Azure в Управляемый экземпляр SQL Azure.In this quickstart, you’ll use SQL Server Management Studio (SSMS) to restore a database (the Wide World Importers — Standard backup file) from Azure Blob storage to Azure SQL Managed Instance.

Предварительные требованияPrerequisites

В этом кратком руководстве:This quickstart:

Восстановление из файла резервной копииRestore from a backup file

В SQL Server Management Studio выполните следующие шаги для восстановления базы данных Wide World Importers в Управляемый экземпляр SQL.In SQL Server Management Studio, follow these steps to restore the Wide World Importers database to SQL Managed Instance. Файл резервной копии базы данных хранится в предварительно настроенной учетной записи хранения больших двоичных объектов Azure.The database backup file is stored in a pre-configured Azure Blob storage account.

Откройте SSMS и подключитесь к Управляемому экземпляру.Open SSMS and connect to your managed instance.
В обозревателе объектов щелкните правой кнопкой мыши Управляемый экземпляр и выберите Создать запрос, чтобы открыть окно нового запроса.In Object Explorer, right-click your managed instance and select New Query to open a new query window.
Запустите следующий скрипт SQL, в котором используется предварительно настроенная учетная запись хранения и ключ SAS, чтобы создать учетные данные в управляемом экземпляре.Run the following SQL script, which uses a pre-configured storage account and SAS key to create a credential in your managed instance.
```
CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = 'sv=2017-11-09&ss=bfqt&srt=sco&sp=rwdlacup&se=2028-09-06T02:52:55Z&st=2018-09-04T18:52:55Z&spr=https&sig=WOTiM%2FS4GVF%2FEEs9DGQR9Im0W%2BwndxW2CQ7%2B5fHd7Is%3D'
```
Чтобы проверить учетные данные, запустите следующий скрипт, который использует URL-адрес контейнера для получения списка файлов резервной копии.To check your credential, run the following script, which uses a container URL to get a backup file list.
```
RESTORE FILELISTONLY FROM URL =
   'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'
```
Запустите следующий скрипт, чтобы восстановить базу данных Wide World Importers.Run the following script to restore the Wide World Importers database.
```
RESTORE DATABASE [Wide World Importers] FROM URL =
  'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'
```

Запустите следующий скрипт, чтобы отслеживать состояние восстановления.Run the following script to track the status of your restore.

SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete
   , dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')

По завершении восстановления просмотрите базу данных в обозревателе объектов.When the restore completes, view the database in Object Explorer. Чтобы убедиться, что восстановление базы данных завершено, используйте представление sys.dm_operation_status.You can verify that database restore is completed using the sys.dm_operation_status view.

Примечание

Операция восстановления базы данных является асинхронной и повторяемой.A database restore operation is asynchronous and retryable. В случае разрыва подключения или истечения времени ожидания в SQL Server Management Studio может возникнуть ошибка.You might get an error in SQL Server Management Studio if the connection breaks or a time-out expires. База данных SQL Azure будет пытаться восстановить базу данных в фоновом режиме, и вы сможете отслеживать ход восстановления с помощью представлений sys.dm_exec_requests и sys.dm_operation_status.Azure SQL Database will keep trying to restore database in the background, and you can track the progress of the restore using the sys.dm_exec_requests and sys.dm_operation_status views.
На некоторых этапах процесса восстановления в системных представлениях вместо фактического имени базы данных будет отображаться ее уникальный идентификатор.In some phases of the restore process, you will see a unique identifier instead of the actual database name in the system views. Узнайте больше о различиях в поведении инструкции RESTORE.Learn about RESTORE statement behavior differences here.

Дальнейшие действияNext steps

Если на шаге 5 восстановление базы данных завершается и появляется сообщение ID 22003 (Идентификатор 22003), создайте новый файл резервной копии, содержащий контрольные суммы резервной копии, и снова выполните восстановление.If, at step 5, a database restore is terminated with the message ID 22003, create a new backup file containing backup checksums and perform the restore again. См. статью Включение или отключение вычисления контрольных сумм резервных копий во время архивации или восстановления.See Enable or disable backup checksums during backup or restore.
См. раздел Резервное копирование SQL Server на URL-адрес — рекомендации и устранение неполадок.For troubleshooting a backup to a URL, see SQL Server Backup to URL best practices and troubleshooting.
Обзор вариантов подключения для приложений см. в статье Подключение приложения к Управляемому экземпляру SQL.For an overview of app connection options, see Connect your applications to SQL Managed Instance.
Чтобы отправлять запросы с помощью привычных средств или языков, ознакомьтесь со статьей Краткие руководства. Подключение и создание запросов к Базе данных SQL Azure.To query using your favorite tools or languages, see Quickstarts: Azure SQL Database connect and query.

Копирование и восстановление баз данных в Microsoft SQL Server 2012 / 2008

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

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

1. Причины потери данных

Можно выделить 5 основных причин потери данных:

Программные ошибки — Возникновение условий, приводящих к аварийному завершению системы. Поскольку такие ошибки основываются на дефектах программной логики, система баз данных не может выполнить восстановление в подобных ситуациях. Поэтому восстановление должен проводить сам программист, выполнив обработку таких исключений.
Ошибки администратора (человеческий фактор) — Случаи, в которых пользователь с большими полномочиями может неумышленно (или умышленно) разрушить данные. Необходимо постараться создать такой режим работы, который сделает подобную ситуацию маловероятной, однако совсем исключать такую возможность нельзя.
Выход из строя компьютера (сбой системы) — Возникает в результате ошибок в оборудовании и программном обеспечении. В этом случае содержимое оперативной памяти компьютера может быть потерянно. В качестве защиты, можно рекомендовать использование резервного сервера, зеркальное отображение баз данных и пр.
Отказ дискового накопителя — Физическое разрушение жесткого диска. Рекомендуется использование технологий RAID для хранения файлов баз данных, кроме того необходимо, чтобы файлы резервных копий хранились на дисковом носителе, отличным от устройства, на котором располагаются файлы баз данных.
Катастрофы (пожар, наводнение, землетрясение) или кража — Обойти эту ситуацию станет возможным, если устройство, содержащее необходимую для восстановления данных информацию, будет храниться отдельно от основного оборудования и не будет потеряно в результате катастроф или краж.

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

2. Типы резервного копирования

Существует 2 режима создания резервных копий:

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

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

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

Выбор модели восстановления базы данных определяет объем данных, который может быть потерян во время разрушения базы данных, а также скорость использования, размер резервной копии протокола транзакций и период времени, необходимый для резервного копирования протокола. MS SQL Server поддерживает три модели восстановления:

Полная модель восстановления — модель, при которой все операции записываются в протокол транзакций. Поэтому эта модель предоставляет полную защиту против сбоев внешних устройств.
- Преимущества:
  1. Есть возможность восстановить базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола.
  2. Возможно восстановить данные на любой момент времени.
  3. Возможно восстановить данные на отметку в протоколе. Отметки в протоколе соответствуют заданной транзакции и добавляются только если эта транзакция подтверждается.
  4. Протоколируются все операции, связанные с изменением индекса. В этом случае пересоздание индекса выполняется быстрее, потому что не надо создавать их заново.
- Недостатки:
  1. Соответствующий протокол транзакций может быть очень большим по объему, и файлы на диске, содержащие этот протокол, могут увеличиваться в размере очень быстро. В связи с этим возможно заполнение протокола транзакций.
  2. Протокол транзакций должен быть защищен от сбоев внешних устройств. По этой причине использование технологии RAID для защиты протокола транзакций строго рекомендуется.
  3. Требуется значительно больше времени на резервное копирование.
- Заключение:
  Данная модель восстановления рекомендована для производственных баз данных, если позволяет аппаратная часть сервера баз данных.
Модель восстановления с неполным протоколированием — То же, что и полная модель восстановления, за тем исключением, что не ведется протоколирование массовых или bulk-операций. А резервные копии протокола транзакций содержат в этом случае результат такой операции.
- Преимущества:
  1. Как и с полной моделью восстановления, есть возможность восстановить базу данных с последней подтвержденной транзакции, которая была сохранена в файле протокола.
  2. Возможно восстановить данные на любой момент времени, если не выполнялось объемных операций.
  3. Возможно восстановить данные на отметку в протоколе, если не было объемных операций.
  4. Объемные операции выполняются намного быстрее, чем под полной моделью восстановления, так как они не протоколируются.
  5. Для резервной копии протокола требуется гораздо меньше памяти, чем в случае полного восстановления.
- Недостатки:
  1. Те же, что и при полной модели восстановления.
  2. Не протоколируется операции с изменением индекса. При восстановлении, индексы потребуется создать заново.
  3. Восстановление с резервной копии протокола дольше, нежели при полной модели восстановления.
  4. Нет возможности восстановить данные на момент времени или на отметку в протоколе в случае объемных операций.
- Заключение:
  Модель восстановления с неполным протоколированием используется для производственных баз данных в тех случаях, когда периодически происходят крупномасштабные или объемные bulk-операции.
Простая модель восстановления — В простой модели восстановления протокол транзакций усекается, если появляется точка восстановления. Но это не означает, что вообще не существует протоколирования, содержимое протокола используется во время создания контрольной точки, где все транзакции протокола подтверждены или для них выполнен откат.
- Преимущества:
  1. Производительность всех объемных операций очень высокая.
  2. Низкие требования к объему памяти протокола.
- Недостатки:
  1. Данные возможно восстановить только на момент последнего резервного копирования, а значит недопустимы восстановления на конкретный момент времени или на отметку в протоколе. Все изменения с последнего резервного копирования должны быть восстановлены вручную.
- Заключение:
  Рекомендуется использовать простую модель восстановления для производственных баз, только в тех случаях, когда сервер баз данных не обладает достаточным объемом памяти или когда аппаратная часть сервера баз данных ниже рекомендуемой.

4. Методы резервного копирования

MS SQL Server предоставляет 4 различных метода резервного копирования:

Полное копирование базы данных (Full) — При полном резервном копировании создается резервная копия всей базы данных целиком, она включает в себя схему всех таблиц, соответствующие файловые структуры, а также содержит все данные из этой базы на момент завершения резервного копирования. Это осуществляется благодаря тому, что полное копирование захватывает состояние базы данных на момент начала копирования. А затем, если копирование выполняется динамически, система записывает любые действия, которые имеют место в процессе создания копии.
- Преимущества:
  Быстрая скорость восстановление базы данных.
- Недостатки:
  Полное резервное копирование требует больше времени и требует больше пространства для хранения, чем другие методы копирования.
- Заключение:
  Для небольших баз данных, которые можно скопировать быстро, лучше всего применять полное резервное копирование. Но для больших баз требуется кроме полных резервных копий, создавать также и дифференцированные (разностные) копии баз данных.
Дифференцированное (разностное) резервное копирование (Differential) — В этом случае создается копия только частей баз данных, которые менялись с момента последнего полного копирования баз данных. Эта полная резервная копия называется основой для разностной копии. Как и в случае полного резервного копирования, любые действия, имеющие место во время создания копии, также копируются.
- Преимущества:
  Этот тип резервного копирования минимизирует время, требуемое для копирования, т. к. количество копируемых данных значительно меньше, чем при полном копировании.
- Недостатки:
  Для восстановления необходимо загрузить сначала полную копию баз данных, а затем разностную, что занимает больше времени. И, соответственно, нет смысла применять разностное копирование без полного.
- Заключение:
  Используется на больших базах данных в связке с полным резервным копированием.
Резервное копирование протокола транзакций (Transaction log) — Данный вид копирования применяется при полной модели восстановления (или при неполном протоколировании) баз данных, и учитывает только изменения, записанные в протокол транзакций. Поэтому такая форма резервного копирования не основывается на физических страницах баз данных, а только на логических операциях.
- Преимущества:
  1. Самая быстрая скорость создания копии.
  2. В отличии от дифференцированных резервных копий, где возможно восстановить базу данных только на момент последнего копирования, позволяет восстановить базу данных на конкретный момент времени.
  3. Правильное «закрытие» протокола транзакций перед началом новой порции действий с этим протоколом. Одна из наиболее общих ошибок системы возникает, когда переполняется протокол транзакций. Если память, используемая для протокола транзакций, заполняется на 100%, то система должна остановить все выполняющие транзакции, пока память не будет освобождена. Эта проблема может быть устранена только при частом выполнении резервного копирования протокола транзакций: каждый раз происходит «закрытие» порции существующего протокола и сохранение на другом внешнем устройстве. Эта порция протокола становится повторно используемой, следовательно, система восстанавливает дисковое пространство.
- Недостатки:
  Более долгий процесс восстановления, чем при дифференцированном резервном копировании, где требуется полная копия базы данных и последняя разностная копия, в данном случае потребуется полная копия и все существующие копии протоколов транзакций.
- Заключение:
  Рекомендуется применять на производственных базах данных в связке с полным резервным копированием.
Резервное копирование файлов или файловых групп — Данный метод позволяет копировать указанные файлы баз данных вместо копирования всей базы данных. Отдельные файлы могут быть восстановлены из копии, позволяя выполнить восстановление после сбоя, который повлиял лишь на небольшое подмножество файлов баз данных.
- Заключение:
  Копирование файлов базы данных рекомендуется выполнять только когда база данных является очень большой, и нет достаточно времени для полного копирования базы данных.

5. Какие базы данных и как часто копировать?

База данных master является наиболее важной базой данных системы, потому что она содержит информацию обо всех базах данных в этой системе. Поэтому резервное копирование базы данных master должно происходить на регулярной основе. Кроме того, рекомендуется создавать копию каждый раз, когда выполняются действия, приводящие к модификации базы данных master. Вот некоторые из них:
- Выполнение операторов и хранимых процедур;
- Создание, изменение и удаление базы данных;
- Изменения протокола транзакций.
Следует выполнять резервное копирование всех производственных баз данных на регулярной основе. Дополнительно, необходимо делать резервную копию после того как с базами данных были выполнены следующие изменения:
- После создания базы данных;
- После создания индексов;
- После создания протокола транзакций;
- После выполнения непротоколируемых операций (операции, которые не записываются в протокол транзакций).

6. Пример стратегии резервного копирования

Ниже приводится некоторый план резервного копирования, в реальной организации:

И некоторые характеристики связанные с выполнением резервного копирования базы данных DB1:

Аппаратная часть:

Процессор Opteron 8220 8×1.0 Ghz
ОЗУ 24 Гб
HDD 250 Гб RAID 1+0

Программное обеспечение:

Базы данных:

Общий объем баз данных: ~ 95 Гб
Объем базы данных master: ~ 5 Мб
Объем базы данных DB1: ~ 23 Гб
Модель восстановления базы данных DB1: Полная
Прирост базы данных DB1 в день: ~ 200 Мб

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

Время создания полной резервной копии: ~ 5 мин.
Время создания копии протокола транзакций: ~ 4 сек.
Размер полной резервной копии (с сжатием): ~ 1,6 Гб
Размер копии протокола транзакций: ~ 20 Мб

Необходимое дисковое пространство для плана резервного копирования DB1:

Хранение полных резервных копий (1 месяц): ~ 50 Гб
Хранение копий протокола транзакций (1 месяц): ~ 10 Гб
Хранение полных копий от 1-ого числа каждого месяца (1 год): ~ 20 Гб
Итого размер дискового пространства: ~ 80 Гб
Итого размер дискового пространства в % от размера базы: ~ 350 %

Время восстановления базы данных DB1:

Время восстановления полной резервной копии: ~ 5 мин.
Время восстановления копии протокола транзакций: ~ 5 сек.

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

Запись опубликована в рубрике Microsoft SQL Server 2008, Microsoft SQL Server 2012 с метками Backup, SQL, Безопасность. Добавьте в закладки постоянную ссылку.

Как восстановить базу данных SQL Server из резервной копии

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

с использованием команд T-SQL
с использованием SQL Server Management Studio
с использованием приложения SqlBackupAndFtp

Как восстановить базу данных SQL Server из резервной копии с помощью команд T-SQL

Команда

RESTORE DATABASE — это самый простой и универсальный способ восстановления резервных копий SQL Server, поскольку команды T-SQL работают везде, независимо от того, вводите ли вы их в SQL Server Management Studio, выполняете с помощью утилиты sqlcmd или запускаете из своей программы.Давайте рассмотрим, какие команды используются для восстановления трех типов резервных копий: полных, дифференциальных и резервных копий журнала транзакций.

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

Полные резервные копии содержат всю информацию, необходимую для восстановления вашей базы данных на момент времени, когда процесс резервного копирования был завершен. Резервная копия перезапишет вашу базу данных, если таковая существует, или создаст новую базу данных SQL Server. Пусть ваша полная резервная копия хранится в D: \ Adventureworks_full.bak, и вы хотите восстановить ее в базе данных Adventureworks.Вам необходимо выполнить следующие команды:

 ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.bak'

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

 ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.bak' С NORECOVERY

Восстановить дифференциальную резервную копию базы данных SQL Server

Дифференциальные резервные копии содержат изменения, которые произошли в базе данных с момента последнего полного резервного копирования.В последней разностной резервной копии накапливаются все изменения, поэтому для восстановления базы данных не нужны все предыдущие разностные резервные копии, а только последняя. Перед восстановлением дифференциальной резервной копии необходимо сначала восстановить последнюю полную резервную копию с параметром NORECOVERY, а затем последнюю дифференциальную резервную копию с параметром ВОССТАНОВЛЕНИЕ:

 ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.bak' С NORECOVERY
ИДТИ
ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ Adventureworks FROM DISK = 'D: \ AdventureWorks_diff.diff 'С ВОССТАНОВЛЕНИЕМ
GO

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

Резервные копии журнала транзакций содержат все транзакции, которые имели место между последним резервным копированием журнала транзакций (или первым полным резервным копированием) и моментом завершения процесса резервного копирования. Вы должны восстановить все резервные копии журналов транзакций, сделанные после последней дифференциальной резервной копии, в той же последовательности, в которой они были созданы. И, очевидно, резервные копии журналов восстанавливаются после того, как вы закончите с полным и дифференциальным резервным копированием (Подробнее о восстановлении на момент времени):

 ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ Adventureworks FROM DISK = 'D: \ Adventureworks_full.бак 'С NORECOVERY
ИДТИ
ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ Adventureworks С ДИСКА = 'D: \ AdventureWorks_diff.dif' С ПОМОЩЬЮ NORECOVERY
ИДТИ
ВОССТАНОВЛЕНИЕ ЖУРНАЛА Adventureworks С ДИСКА = 'D: \ Adventureworks_log1.trn' ПРИ ПОМОЩИ NORECOVERY
ИДТИ
ВОССТАНОВЛЕНИЕ ЖУРНАЛА Adventureworks FROM DISK = 'D: \ Adventureworks_log2.trn' С ВОССТАНОВЛЕНИЕМ
GO

Как восстановить базу данных из резервной копии с помощью SQL Server Managment Studio

Если у вас установлена SQL Server Management Studio, вы можете восстановить резервную копию базы данных, используя только ее интерфейс.Просто следуйте инструкциям:

1. Подключитесь к серверу SQL Server, щелкните правой кнопкой мыши каталог «Базы данных» и выберите «Восстановить базу данных».

2. Нажмите кнопку под разделом «Источник» рядом с «Устройство»
3. В «Выберите устройство резервного копирования» нажмите «Добавить»
4. Выберите файл или файлы резервной копии (.bak), которые вы собираетесь восстановить. , затем нажмите «ОК».
5. В окне «Восстановить базу данных» укажите имя базы данных, которую вы хотите восстановить, и нажмите «ОК», чтобы запустить

База данных SQL Server восстановлена.

Как восстановить базу данных SQL Server с помощью SqlBackupAndFtp

Если вы используете SqlBackupAndFtp для создания резервных копий SQL Server, вы можете восстановить их прямо из панели истории:

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

Здесь хорошо то, что вы можете выбрать любую резервную копию любого типа (полную, дифференциальную или журнальную), а все остальные необходимые резервные копии будут восстановлены автоматически.

Если вам нужно восстановить другие резервные копии, которые были созданы с помощью SqlBackupAndFtp, или стандартной команды T-SQL «CREATE BACKUP», или сценария SQL или файла .bacpac, то, выполнив следующие шаги, вы можете создать «задание восстановления», чтобы сделать это:

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

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

 {DatabaseName} {YYYY} {MM} {DD} {hh} {mm} [журнал | разница].[sql | bacpac | 7z | zip | bak]

sql server — Восстановление базы данных SQL Express из резервной копии файла

Переполнение стека

Около
Продукты
Для команд

Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании

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

phpMyAdmin — это программа, используемая для удаленного управления базами данных через веб-интерфейс. Это будет в хорошем пакете хостинга. Для получения информации о резервном копировании базы данных WordPress см. Резервное копирование базы данных.

Информация здесь была протестирована с использованием phpMyAdmin 4.0.5, работающего в Unix.

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

Восстановить процесс № Восстановить процесс

Используя phpMyAdmin, выполните следующие действия, чтобы восстановить базу данных MySQL / MariaDB.

Войдите в phpMyAdmin.
Щелкните «Базы данных» и выберите базу данных, в которую вы будете импортировать данные.
После этого вы увидите либо список таблиц, уже находящихся в этой базе данных, либо экран, на котором говорится, что таблиц не существует. Это зависит от ваших настроек.
Вверху экрана будет ряд вкладок.Щелкните вкладку Импорт .
На следующем экране будет расположение поля с текстовым файлом, а рядом с ним кнопка с именем Обзор .
Щелкните Обзор . Найдите файл резервной копии, хранящийся на вашем компьютере.
Убедитесь, что SQL выбран в раскрывающемся меню Формат .
Щелкните кнопку Go .

А теперь бери кофе. Это требует времени. В конце концов вы увидите экран успеха.

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

Наверх ↑

Процесс восстановления состоит из разархивирования архивного дампа базы данных и его импорта в базу данных MySQL / MariaDB.

Предполагая, что ваша резервная копия представляет собой файл .bz2 , созданный с использованием инструкций, аналогичных приведенным для резервного копирования вашей базы данных с помощью команд MySQL / MariaDB, следующие шаги помогут вам восстановить вашу базу данных:

Распакуйте файл .bz2 :

 user @ linux: ~ / files / blog> bzip2 -d blog.bak.sql.bz2

Примечание: Если резервная копия вашей базы данных была файлом .tar.gz с именем blog.bak.sql.tar.gz , тогда

 tar -zxvf blog.bak.sql.tar.gz

— это команда, которую следует использовать вместо указанной выше.

Поместите резервную копию SQL обратно в MySQL / MariaDB:

 user @ linux: ~ / files / blog> mysql -h mysqlhostserver -u mysqlusername -p databasename  Введите пароль: (введите свой пароль mysql) 
 пользователь @ linux: ~ / files / blog>

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

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

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

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

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

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

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

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

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

Резервное копирование MS SQL Server 2008, 2008 R2, 2012 и 2014

Полное резервное копирование баз данных MS SQL Server 2008, 2008 R2, 2012 и 2014

Дифференциальное резервное копирование баз данных MS SQL Server 2008, 2008 R2, 2012 и 2014

Резервное копирование журнала транзакций MS SQL 2008, 2008 R2, 2012 и 2014

Настройка резервного копирования MS SQL и конфигурирование БД

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

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

Восстановление MS SQL на момент времени

LSN

Сценарии восстановления MS SQL

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

Восстановление MS SQL на локальный диск

Восстановление базы данных MS SQL «master»

База данных MS SQL в состоянии восстановления

Автоматизированное восстановление баз данных MS SQL из бэкапов

Задача

Общий порядок действий

Создание XML-плана восстановления

Восстановление на тестовом сервере

Как восстановить базу данных Microsoft SQL из бэкапа

1. Как восстановить базу данных Microsoft SQL из бэкапа с помощью панели управления хостингом Plesk?

2. Как восстановить базу данных Microsoft SQL из бэкапа, обратившись в службу технической поддержки?

Восстановление базы данных из резервной копии — Azure SQL Database & SQL Managed Instance

В этой статье

Время восстановленияRecovery time

Восстановление на момент времениPoint-in-time restore

Восстановление до точки во времени с помощью портал AzurePoint-in-time restore by using Azure portal

База данных SQLSQL Database

Управляемый экземпляр SQLSQL Managed Instance

Восстановление удаленной базы данныхDeleted database restore

Восстановление базы данных удалено с помощью портал AzureDeleted database restore by using the Azure portal

База данных SQLSQL Database

Краткое руководство. Восстановление резервных копий (SSMS) — Azure SQL Managed Instance

В этой статье

Предварительные требованияPrerequisites

Восстановление из файла резервной копииRestore from a backup file

Дальнейшие действияNext steps

Копирование и восстановление баз данных в Microsoft SQL Server 2012 / 2008

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

1. Причины потери данных

2. Типы резервного копирования

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

4. Методы резервного копирования

5. Какие базы данных и как часто копировать?

6. Пример стратегии резервного копирования

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

Как восстановить базу данных SQL Server из резервной копии

Как восстановить базу данных SQL Server из резервной копии с помощью команд T-SQL

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

Восстановить дифференциальную резервную копию базы данных SQL Server

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

Как восстановить базу данных из резервной копии с помощью SQL Server Managment Studio

Как восстановить базу данных SQL Server с помощью SqlBackupAndFtp

sql server — Восстановление базы данных SQL Express из резервной копии файла

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

Восстановить процесс № Восстановить процесс

Добавить комментарий Отменить ответ

2. Как восстановить базу данных Microsoft SQL из бэкапа, обратившись в службу технической
поддержки?