Каталог расширений

Популярные теги

3gp       avi       fb2       jpg       mp3       pdf      

Главная » Разное » Как восстановить bak файл sql

Как восстановить bak файл sql


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

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

 

 

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

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

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…

Восстановление базы 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С и проверяем работоспособность.

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

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

Подключитесь к MS SQL Server c помощью программы SQL Server Management Studio.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

  1. Расшарить папку F:\MS SQL\Backup  на Srv01 так чтобы она была доступна на London.
  2. С помощью QMB копировать бэкапы в общую сетевую папку, которая доступна на London.

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

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


Итак, нам потребуется проделать следующие шаги:
  1. Настроить общую сетевую папку
  2. Установить утилиту QMB
  3. Настроить уведомления и зарегистрировать в программе два SQL Server: Srv01 и London.
  4. Создать в программе две новых задачи:
    • Создание XML плана восстановления на сетевом диске
    • Восстановление по XML плану с сетевого диска
  5. Создать в программе два сценария:
    • Сценарий, на рабочем сервере 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 файл плана восстановления. Нажмем кнопку «Добавить». Откроется форма выбора задачи. Кликнем кнопку «Добавить новую задачу». Откроется форма новой задачи.
На форме нужно:
  1. Изменить тип задачи на «Создание XML плана восстановления»
  2. Создать новое подключение к общей папке. В моем случае это папка \\Server\Backup на файловом сервере.
    Примечание: Для сети без домена имя пользователя необходимо указывать в формате: Компьютер\Пользователь
  3. Выбрать базы данных которые войдут в XML план восстановления. В моем случае это три базы — Account2013, Account2014, Account2015.
  4. Указать имя задачи — Создание 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]
Спасибо за внимание!

Как восстановить базу 1С SQL из резервной копии

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

Перед тем, как начать это, требуется убедиться что выполнили следующие предварительные условия:

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

Разрешения

Если восстанавливаемая база данных не существует, пользователь должен иметь разрешения create database, чтобы иметь возможность выполнить восстановление. Если база данных существует, разрешение выполнения по умолчанию назначаются членам sysadmin и dbcreator фиксированным ролям сервера и владельцу базы данных (dbo).

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

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

Чтобы восстановить базу данных, выполните следующие действия:

  1. После подключения к соответствующему экземпляру СУБД MS SQL требуется щелкнуть имя сервера, чтобы развернуть дерево серверов в обозревателе объектов.
  2. Разверните Базы данных. В зависимости от базы данных, выберите пользовательскую базу данных или разверните Системные базы данных и выберите системную базу данных.
  3. Щелкните ПКМ базу данных, выберите «Задачи» > «Восстановить» > «База данных», чтобы открыть диалоговое окно «Восстановить базу данных».
  4. В разделе «Источник» страницы «Общие» укажите источник и расположение наборов резервных копий для восстановления, выбрав «Устройство» > «Добавить», а затем найдите файл резервной копии:
Путь к файлу резервной копии

Рисунок 1 - Путь к файлу резервной копии

  1. В разделе «Назначение» страницы «Общие» поле «База данных» автоматически заполняется именем базы данных, введите новое имя в этом поле.
  2. В разделе «План восстановления» на странице «Общие» оставьте значение по умолчанию «До последней сохраненной резервной копии» или нажмите «Временная шкала», чтобы открыть диалоговое окно «Временная шкала резервного копирования», где вы можете вручную выбрать момент времени, чтобы остановить действие восстановления.
  3. В разделе Резервные копии для восстановления сетки выберите резервные копии для восстановления. Эта сетка отображает резервные копии, доступные для указанного местоположения. По умолчанию предлагается план восстановления.
  4. Чтобы просмотреть или выбрать дополнительные параметры, на панели «Параметры восстановления» на странице «Параметры» можно выбрать любой из следующих параметров, если это соответствует вашей ситуации:
Окно об успешном завершении

Рисунок 2 - Окно об успешном завершении

С опциями (не обязательно):

  • Перезаписать существующую базу данных (with replace)
  • Сохранить настройки репликации (with keep_replication)
  • Ограничить доступ к восстанавливаемой базе данных (with restricted_user)

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

  • restore with recovery - это поведение по умолчанию, которое оставляет базу данных готовой к использованию, откатывая незавершенные транзакции
    • Дополнительные журналы транзакций не могут быть восстановлены
    • Выберите эту опцию, если вы сейчас восстанавливаете все необходимые резервные копии
  • restore with norecovery оставляет базу данных неработоспособной и не откатывает незафиксированные транзакции
    • Дополнительные журналы транзакций могут быть восстановлены
    • База данных не может быть использована, пока она не будет восстановлена
  • restore with standby оставляет базу данных в режтме только для чтения
    • Он отменяет незавершенные транзакции, но сохраняет действия отмены в резервном файле, чтобы можно было восстановить эффекты восстановления

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

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

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

Нажимаем ОК, после этого выполнится восстановление базы данных и увидим информационное окно об успешном завершении.

Всё что вы стеснялись спросить о бэкапах Microsoft SQL Server / Хабр

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

Могу ли я развернуть бэкап на версии SQL Server, отличной от той, на которой был сделан бэкап? Какие проблемы могут возникнуть?

Вы можете восстановить бэкап на другой версии SQL Server, но только в том случае, если версия SQL Server, на которой вы разворачиваете бэкап, более новая чем та, на которой вы его сделали. Другими словами, вы можете развернуть бэкап, сделанный SQL Server 2000 на SQL Server 2005, SQL Server 2005 на SQL Server 2008 R2 или с SQL Server 2008 на SQL Server 2012, но никогда не сможете сделать этого в обратном направлении. Каждая версия SQL Server вносит свои изменения в базу данных и файлы, хранящие её. Компания Microsoft не будет «возвращаться в прошлое» и переписывать предыдущие версии SQL Server для поддержки этих изменений. Если же вам действительно нужно перейти на более старую версию SQL Server, вам нужно будет заскриптовать схему и сами данные (например, вот статья, посвящённая подобному переходу)

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

RESTORE HEADERONLY FROM DISK = 'd:\bu\mm.bak';

В результате вы увидите Major, Minor и Build-версии того экземпляра SQL Server, на котором был сделан бэкап (как показано на скриншоте снизу). Это позволит вам определить подходящую версию SQL Server для восстановления этого бэкапа.

При восстановлении БД на более новую версию SQL Server, может оказаться, что в ней присутствует что-то несовместимое с этой версией SQL Server. Наиболее безопасным подходом к переходу на новую версию SQL Server будет запуск Microsoft Upgrade Advisor (бесплатная утилита доступная для каждой версии SQL Server) на базе, которую требуется переносить, убедиться, что она готова, а затем сделать бэкап и восстановить её на новом экземпляре (но только в этом порядке, а не сначала попытаться перенести бэкап, а затем запустить помощника).

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

ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;

Различные числа обозначают различные версии SQL Server: 90 для SQL Server 2005, 100 для SQL Server 2008 и 2008 R2 и 110 для SQL Server 2012 (более подробно о версиях SQL Server можно прочитать здесь — прим. переводчика).

Стоит добавить, что не все «переходы» возможны. SQL Server позволят «прыгнуть вперёд» только на две версии. Например, вы не можете развернуть бэкап, сделанный SQL Server 2000, на SQL Server 2012. Сначала вам нужно будет развернуть его на SQL Server 2008, установить соответствующий уровень совместимости, создать новый бэкап, а его, затем, развернуть на SQL Server 2012.

Могу ли я использовать операцию восстановления для создания копии базы даных? Что может пойти не так?

Да, вы можете это сделать. Если вы разворачиваете бэкап на другом сервере, то нужно убедиться в том, что на новом сервере у вас присутствуют те же самые логические диски, что и на «старом» сервере, либо вручную прописать правильные пути для файлов базы данных, используя опцию WITH MOVE команды RESTORE DATABASE:
RESTORE DATABASE NewDBName FROM DISK = 'c:\bu\mm.bak' WITH MOVE 'OldDB' TO 'c:\data\new_mm.mdf', MOVE 'OldDB_Log' TO 'c:\data\new_mm_log.ldf';

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

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

Когда вы восстанавливаете БД на новом сервере, вы можете столкнуться с проблемой «Orphaned Users» (пользователей, утративших связь с учётной записью, согласно переводу на msdn – прим. переводчика), если пользователь базы данных связан с учётной записью, не представленной на новом сервере. Вам нужно будет исправить эту ошибку.

Можно ли присоединять как базу данных файл MDF, если у меня нет файла журнала транзакций?

Единственный вариант, когда это допустимо – если журнал транзакций был утерян уже после того как работа базы данных была корректно завершена. В любом случае – это не очень хорошая идея. При присоединении БД, файл журнала транзакций, так же как и файл данных, нужен для проведения процесса восстановления БД (здесь под восстановлением БД понимается не операция RESTORE DATABASE, а recovery – процесс, происходящий при каждом запуске SQL Server, при котором SQL Server «проходит» по журналу транзакций и приводит файлы данных в согласованное состояние – прим. переводчика). Тем не менее, в некоторых случаях возможно присоединение файла данных без файла журнала транзакций, но эта возможность предназначена только для тех случаев, когда файл журнала транзакций был повреждён или потерян в результате проблем с оборудованием и при отсутствии резервных копий. Конечно, база данных не может существовать без журнала транзакций, и при присоединении БД без файла журнала транзакций, SQL Server просто пересоздаст его.

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

Копирование файлов данных и файлов журнала транзакций допустимо только после выполнения операции отсоединения (detach), либо после того как процесс SQL Server был корректно завершён – это обеспечит корректное завершение всех транзакций. Копирование/перемещение файлов баз данных на другой сервер является более быстрым способом переноса БД на другой сервер, чем создание/разворачивание резервной копии, но не так безопасно (в том случае, если вы перемещаете непосредственно файлы БД, не имея копий). Так же, нужно помнить о том, что вы можете выполнить присоединение БД только на такой же или более новой версии SQL Server.

Моя БД лежит на SAN. Я слышал, что бэкапов SAN достаточно. Это правда?

Это может быть правдой. Главное чтобы ваша SAN (СХД, Сеть/Система Хранения Данных – прим. переводчика) поддерживала транзакции SQL Server. Если это так, тогда она будет знать о том, что в БД существуют транзакции и наличие этих транзакций может означать, что данные в файлах данных, могут быть не полными, поскольку процесс записи данных, изменённых в этих транзакциях, на жёсткий диск, может быть не завершён на момент создания резервной копии. Те бэкапы, которые делает сам SQL Server, естественно, учитывают эти моменты.

EMC Data Domain, например – это комбинация ПО и SAN, обеспечивающая поддержку транзакций, как и продукция других вендоров, но вам всё равно нужно проверить документацию вашего SAN. Обратите внимание на наличие фраз вроде «transaction consistency», или «transaction aware», или чего-то подобного. Если вы их не нашли, то я бы посоветовал вам проверить восстановление БД прежде чем вы решите, что бэкапов SAN вам достаточно для выполнения всех ваших требований к резервным копиям. Впрочем, даже после того, как вы убедились, что бэкапы SAN выполняются корректно, это вовсе не означает, что «родные» бэкапы SQL Server вам больше не нужны. Если вам нужна возможность восстановления вашей БД на момент времени, например, вам всё равно придётся делать бэкапы журнала транзакций средствами SQL Server.

Обычно, при создании бэкапа, SAN с поддержкой SQL Server, использует VDI-интерфейс SQL Server и «замораживает» БД на время создания резервной копии. Если вы запустите механизм создания такого бэкапа и посмотрите в журнал ошибок SQL Server, там вы увидите сообщения о том, что операции IO были заморожены.

Если вы полагаетесь на резервные копии создаваемые SAN, вам всё равно нужно проводить проверки целостности БД либо на «живых» БД, либо на копиях, восстановленных с бэкапа SAN. В противном случае, вы можете долгое время создавать бэкапы повреждённой БД и даже не знать об этом.

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

SQL Server не является обычным десктопным приложением. Он управляет своими файлами таким образом, чтобы обеспечить выполнение всех свойств ACID (Atomic, Consistency, Isolated, Durable – чуть более подробно — прим. переводчика). Вкратце, чтобы обеспечить успешное завершение транзакций, SQL Server старается никому не давать доступ к своим файлам и сам модифицирует их так, как ему нужно.

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

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

Намного безопаснее и проще использовать встроенный механизм SQL Server
для создания бэкапов. Такой бэкап будет являться полной копией вашей БД, и все свойства ACID будут выполнены.

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

Вы можете использовать что-нибудь вроде SQLCMD и выгрузить таблицы в простой текстовый файл, но потом, вместо того, чтобы просто одной командой восстановить БД, вам придётся выполнить целый ряд команд. Во-первых, вам нужно будет создать пустую БД. Затем, вам нужно будет создать и загрузить из файла каждую таблицу. Если какая-нибудь таблица содержит столбец IDENTITY, вам нужно будет выполнять SET IDENTITY_INSERT на каждой из этих таблиц. Так же, вам придётся тщательно определять порядок, в котором вы будете загружать данные в таблицы, чтобы обеспечивать целостность.

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

Конечно, вы вправе поступать таким образом. С другой стороны, вы можете просто выполнить команду BACKUP DATABASE, а потом, когда понадобится, восстановить этот бэкап.

Зачем платить деньги за утилиты, делающие бэкапы, если SQL Server сам умеет это делать?

Существует три основные причины для использования сторонних программ, создающих бэкапы: руководство, автоматизация и функциональность. Если вы начинающий администратор баз данных или вообще не администратор баз данных, но вынуждены обслуживать СУБД как дополнение к своей основной работе, вы можете и не знать о том как, где и почему нужно настраивать бэкапы в SQL Server. Хорошая утилита (вроде SQL Backup Pro) может предоставить вам как раз такой тип руководства, который вам нужен для того, чтобы обеспечить сохранность ваших БД с помощью резервных копий.

Бэкапы, создаваемые самим SQL Server, работают отлично, но вам нужно проделать немало работы для того, чтобы их настроить и ещё больше для того, чтобы их автоматизировать. Хорошая сторонняя утилита сделает процесс автоматизации очень простым. Более того, с её помощью вы сможете автоматизировать другие процессы связанные с бэкапами, такие как зеркалирование/доставка журналов и проверка целостности бэкапа.

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

Если бэкап лежит на сетевой шаре, может ли кто-то прочитать его?

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

Более того, из бэкапа можно достать схему БД или данные, даже не восстанавливая его. Если у вас есть утилита SQL Data Compare, то она, запущенная с ключом /Export сможет вытащить все данные из бэкапа в CSV-формате, сравнивая этот бэкап с пустой БД и не спрашивая никакого пароля. Так же, та же самая SQL Data Compare сможет создать для вас скрипт создающий схему БД.

Для того чтобы предотвратить несанкционированный доступ к бэкапу, вам придётся сделать несколько вещей. Во-первых, убедиться, что шара, на которой хранятся бэкапы, доступна ограниченному кругу лиц. Во-вторых, вы должны хранить только те бэкапы, которые вам действительно нужны. Наконец, если вы используете сторонние утилиты для создания резервных копий (типа SQL Backup Pro), вы можете зашифровать бэкап, так что если кто-то и получит доступ непосредственно к файлу, то прочитать оттуда ничего не сможет.

Без сторонних утилит, вы сможете этого добиться, используя Transparent Data Encryption (TDE).

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

А кто-нибудь может изменить содержимое резервной копии?

Возможности изменять содержимое файла резервной копии не предусмотрено. Поскольку бэкап это постраничная копия базы данных (в том виде в котором она существовала на момент создания бэкапа), восстановленная копия этой БД будет находиться в абсолютно том же состоянии, в котором оригинал был на момент создания бэкапа.
Когда SQL Server считывает каждую страницу, в ходе восстановления БД, он высчитывает её контрольную сумму, зависящую от её содержания, и сравнивает с тем значением, которое было прочитано с оригинальной страницы в момент создания бэкапа (подразумевается, что вы использовали параметр WITH CHECKSUM при создании резервной копии). Если кто-либо производил изменения в файле резервной копии, эти значения не совпадут и SQL Server отметит такую страницу как повреждённую.
Существует ли какой-либо флаг, установив который при создании бэкапа, я могу быть уверен, что всегда смогу из него восстановиться?

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

Во-первых, она проверяет заголовок бэкапа, чтобы убедиться, что в нём нет ошибок. Если заголовок повреждён, то вы не сможете восстановить БД из этого бэкапа.

RESTORE VERIFYONLY FROM DISK= '<Backup_location>'

Вторая проверка возможно только в том случае, если вы запускали процедуру создания резервной копии с параметром WITH CHECKSUM. Это означает, что в ходе создания резервной копии, SQL Server пересчитывает и сверяет контрольные суммы для всех прочитанных страниц. Если он наткнётся на страницу, для которой эти суммы не сойдутся, операция создания резервной копии завершится с ошибкой. Если проверка завершается успешно, BACKUP WITH CHECKSUM вычислит и запишет контрольную сумму созданной копии.

Соответственно, RESTORE VERIFYONLY может использоваться для пересчёта контрольной суммы и проверки того, что за время хранения резервная копия не была повреждена

RESTORE VERIFYONLY FROM DISK= '<Backup_location>' WITH CHECKSUM

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

Во-вторых, CHECKSUM не может обнаружить повреждения, произошедшие в памяти. Если страница данных была обновлена, находясь в памяти и затем произошло её повреждение прежде чем она была записана на диск (и, соответственно, в бэкап), тогда вычисление контрольной суммы не покажет никакой ошибки, а просто подтвердит, что в бэкап была записана та же страница, что и содержалась в БД в момент создания бэкапа. Т.е. если страница уже была повреждена в момент создания бэкапа, ошибка не может быть найдена с помощью контрольной суммы и восстановление из этого бэкапа может завершиться ошибкой.

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

Не содержит ли бэкап что-нибудь кроме данных? Может ли кто-нибудь прочесть пароли из него?

Бэкап содержит не только данные. Он содержит всю структуру базы данных. Она включается в себя все данные, процедуры, представления, функции и весь остальной код. Также, он содержит все настройки БД. Наконец, он содержит всю информацию о пользователях БД. Для обычной БД, каждый пользователь БД связан с учётной записью SQL Server. Пароли таких пользователей хранятся вместе с учётной записью, так что этих паролей в бэкапе не будет.

Однако, в автономных базах данных (contained databases — прим. переводчика) существует понятие USER WITH PASSWORD, поскольку сама идея автономных баз данных предполагает минимальную связь такой базы с сервером. В этом случае, пароль будет находиться в бэкапе, что может привести к попыткам достать его оттуда. Пароли хранятся не открытым текстом, они хэшируются, точно так же как пароли учётных записей (которые хранятся в системной базе данных master и, естественно, попадают в её бэкап).

Microsoft предлагает несколько best practices по безопасности автономных баз данных.

Зачем в бэкапе индексы, статистика и остальные штуки, которые легко пересоздать? Это же просто потеря времени?

А по-моему, потеря времени – это попытки разделить вещи таким образом и делать резервную копию только одной части. Во-первых, как это сделать? Например, как забэкапить данные, не делая, при этом, бэкапа кластерных индексов? Это невозможно, поскольку листовой уровень кластерного индекса – это страницы данных. Т.е., можно сказать, что кластерные индексы – это сами таблицы, поэтому кластерные индексы должны быть включены в бэкап. Конечно, возможно выделить некластерные индексы в отдельную файловую группу и не делать её бэкап, но потом, после восстановления того бэкапа, что у нас есть, нам всё равно нужно будет возвращать эту файловую группу к жизни и перестраивать все индексы. Так чего мы добьёмся?

Со статистикой так же возникнут проблемы. SQL Server бэкапит статистику вместе с базой данных (и она занимает очень мало места, поскольку, гистограмма, называющаяся статистикой, строится всего лишь по 200 строкам) и восстанавливает её вместе с БД. Однако, если после восстановления мы начнём пересоздавать индексы, поскольку не делали их резервной копии, нам придётся пересоздавать и статистику. Это так же потребует дополнительного времени, а база данных, тем временем, будет оставаться недоступной.

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

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

ОМГ! Я только что удалил таблицу! Я знаю, что это есть в журнале транзакций. Как мне её вернуть?

После того как транзакция была зафиксирована, SQL Server не сможет её откатить. Операции DELETE И TRUNCATE удаляют данные совершенно разными способами. Операция DELETE удаляет данные с помощью транзакций, удаляющих каждую строку. Операция TRUNCATE просто отмечает странницы данных, на которых лежали удаляемые данные, как не использующиеся. Но последствия ни одной из этих операций не могут быть устранены вручную при просмотре журнала транзакций. Вместо этого, вам нужно выполнить процесс, называющийся восстановлением на момент времени. Вы должны немедленно сделать бэкап журнала транзакций вашей БД для того, чтобы сохранить все изменения сделанные до того момента, как вы случайно удалили нужные данные из таблицы. Затем, вам нужно выполнить шаги, описанные в главе 6 этой книги для восстановления на момент времени (в MSDN тоже всё есть – прим. переводчика).

Другой вариант – использование сторонних утилит, типа SQL Backup Pro, которые могут выполнять восстановление отдельных объектов БД в режиме online из имеющихся резервных копий.

А если я просто хочу создать с помощью бэкапа скрипт для построения БД, без восстановления непосредственно бэкапа…?

Стандартных средств для создания такого скрипта в SQL Server не предусмотрено. Однако, утилиты, типа SQL Compare, могут сформировать его. Он легко создаётся с помощью GUI, но так же это возможно с использованием PowerShell:

& 'C:\Program Files (x86)\Red Gate\SQL Compare 8\SQLCompare.exe' /Backup1:C:\MyBackups\MyBackupFile.bak /MakeScripts:"C:\MyScripts\MyBackupScript"

Так же, вы можете обратить внимание на SQL Virtual Restore. Эта утилита позволяет вам примонтировать бэкап к вашему SQL Server так, как будто бы вы запускали процесс восстановления из этого бэкапа, но не требует использования всего того места, которое было бы необходимым при восстановлени. Примонтированный таким образом бэкап выглядит как самая обычная база данных и вы можете заскриптовать её любым удобным вам образом.

От переводчика:
Грант довольно активно пиарил утилиты своей компании на протяжении всей статьи, я постарался это немного сгладить. Названия остались, а если кому-то будут нужны ссылки – их достаточно легко найти в интернете (ну или спросить в личке у меня).
Как обычно, любые пожелания и исправления по переводу и стилистике приветствуются.

Сервер

sql - Как восстановить базу данных из файла .bak?

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где
.

SQL Backup Recovery для восстановления данных из файла резервной копии (.bak)

SysTools SQL Server BAK File Repair Tool - это профессиональный мастер для восстановления поврежденных .bak-файлов MS SQL Server 2019, 2017, 2016, 2014, 2012, 2008. Загрузите бесплатную пробную версию программного обеспечения Microsoft SQL Backup Recovery, которое поможет вы можете восстановить полную резервную копию базы данных и экспортировать ее прямо в базу данных Live SQL Server.

(Средний рейтинг: 4.0 на основе 727 отзывов)

  • Восстановление и предварительный просмотр Таблицы, представления, процедуры, триггеры, функции, столбцы
  • Поддерживает восстановление поврежденного файла резервной копии SQL без каких-либо изменений
  • Восстановление файлов MDF и NDF Сохранено в файле резервной копии SQL
  • Обеспечена поддержка восстановления дифференциальной резервной копии (.bak) файлы
  • Предоставьте возможность легко восстановить удаленные записи таблицы базы данных SQL
  • Опция Auto-Detect для определения версии файла SQL .bak
  • Восстановить удаленную таблицу, хранимую процедуру, функции, представления, триггеры, индексы, правила и т. Д.
  • 2 варианта экспорта: База данных SQL Server или сценарий, совместимый с SQL Server
    • Программа
  • показывает удаленные объекты базы данных SQL красным цветом
  • Также поддерживает восстановление хранимых процедур Unicode
  • Поддерживает тип данных XML в MS SQL Server 2019, 2017, 2016, 2014, 2012, 2008
  • Без ограничения размера файла: Протестировано с 1.4 ТБ файла SQL .bak
  • Поддерживает .bak-файл SQL Server 2019, 2017, 2016, 2014, 2012, 2008 и всех ниже версий

Бесплатная живая демонстрация - SysTools SQL Backup Recovery Полностью защищенная версия

.

Как восстановить резервную копию базы данных с помощью файла .bak в MS SQL Server 2012 - статьи TechNet - США (английский)

Файлы .bak - это резервные копии базы данных, которые мы можем восстановить из резервной копии базы данных с помощью SQL Server Management Studio.

A. Откройте SQL Server Management Studio в обозревателе объектов. Щелкните правой кнопкой мыши узел «Базы данных» и выберите «Восстановить базу данных»

.

B. Диалоговое окно «Восстановить базу данных» будет отображаться на странице General page
1.Имя восстанавливаемой базы данных появится в списке В базу данных . Чтобы создать новый базу данных введите ее имя в поле списка.

2. Выберите «С устройства»

.

3. Нажмите кнопку, чтобы отобразить диалоговое окно «Указать резервную копию»

.

4. Нажмите «Добавить», чтобы просмотреть файл .bak из каталога, и нажмите «ОК».

.

Как распознать поврежденные файлы резервных копий SQL

Ключевой задачей администратора базы данных является поддержание работоспособности базы данных и ее доступности для пользователей. Мы привыкли делать регулярные резервные копии SQL в зависимости от критичности базы данных и модели восстановления. Мы определяем целевую точку восстановления (RPO) Целевое время восстановления (RTO) или систему базы данных, и мы должны иметь возможность восстановить базу данных в любом сценарии для удовлетворения требований.

В SQL Server доступны следующие типы резервного копирования.

  • Модель простого восстановления: Полное и дифференциальное резервное копирование
  • Модель с полным восстановлением: Полное, дифференциальное резервное копирование и резервное копирование журнала

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

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

Проверка резервных копий базы данных с помощью SQL Server Management Studio

Давайте посмотрим, как сделать полную резервную копию с помощью SSMS.Щелкните правой кнопкой мыши базу данных -> Резервные копии:

На первой странице мы определяем тип резервной копии SQL и расположение файла резервной копии:

На странице «Параметры мультимедиа» вы можете увидеть раздел «Надежность»:

У нас есть следующие варианты в разделе «Надежность».

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

    В процессе восстановления базы данных SQL Server повторно вычисляет значение КОНТРОЛЬНОЙ СУММЫ для каждой страницы и совпадает со значением КОНТРОЛЬНОЙ СУММЫ, записанным во время резервного копирования. Если оба значения похожи, это означает, что резервная копия базы данных действительна.

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

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

РЕЗЕРВНАЯ БАЗА ДАННЫХ [SQLShackDemo] НА ДИСК = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak '

WITH NOFORMAT, NOINIT, NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM

GO

После того, как вы выполнили резервное копирование, вы все равно можете проверить, состоит ли ранее созданная резервная копия из КОНТРОЛЬНОЙ СУММЫ.

SELECT database_name, backup_finish_date, has_backup_checksums FROM backupset

, где database_name = 'SQLShackDemo'

GO

На следующем снимке экрана мы видим, что резервный набор имеет значения 1 и 0.

  • Значение 1 для has_backup_checksum: Показывает резервное копирование базы данных, выполненное с помощью CHECKSUM
  • Значение 0 для has_backup_checksum: Показывает, что резервная копия базы данных не состояла из информации CHECKSUM

Мы можем включить флаг трассировки 3023, чтобы делать все резервные копии, используя КОНТРОЛЬНУЮ СУММУ. Если мы включим этот флаг трассировки на глобальном уровне, нам не нужно явно указывать эту опцию при создании резервной копии SQL.

Команда для включения флага трассировки на глобальном уровне.

DBCC Traceon (3023, -1)

В SQL Server 2014 или более поздней версии нам необходимо включить контрольную сумму резервной копии по умолчанию в параметрах конфигурации sp_configure. Выполните приведенный ниже запрос в SSMS.

Мастер USE;

GO

EXEC sp_configure 'показать расширенный параметр', '1';

Go

ПЕРЕКОНФИГУРИРОВАНИЕ с ПЕРЕОПРЕДЕЛЕНИЕМ;

Go

EXEC sp_configure;

В выходных данных команды sp_configure вы получите параметр «резервная контрольная сумма по умолчанию»:

У нас есть следующие варианты конфигурации.

  • 1: значение «1» показывает, что резервное копирование SQL с контрольной суммой включено на уровне экземпляра.
  • 0: Значение «0» показывает, что этот параметр не активен. Это конфигурация по умолчанию

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

EXEC sp_configure 'контрольная сумма резервной копии по умолчанию', '1';

Go

ПЕРЕКОНФИГУРИРОВАНИЕ с ПЕРЕОПРЕДЕЛЕНИЕМ;

Перейти

На следующем снимке экрана вы можете увидеть, что опция «контрольная сумма по умолчанию для резервного копирования» включена на уровне экземпляра с помощью команды sp_configure:

Проверка резервной копии SQL по завершении

У нас есть еще одна опция «Проверить резервную копию по завершении» в мастере резервного копирования SSMS.Он проверяет следующие параметры.

  • Он проверяет, доступен ли файл резервной копии SQL или нет
  • Он считывает информацию заголовка в резервном наборе SQL и проверяет информацию.

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

Вы получите следующую команду после того, как выполните сценарий с помощью окна действий сценария SSMS:

РЕЗЕРВНАЯ БАЗА ДАННЫХ [SQLShackDemo] НА ДИСК = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak 'WITH NOFORMAT, NOINIT,

NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10

GO

объявить @backupSetId как int

выберите @backupSetId = position from msdb..backupset, где database_name = N'SQLShackDemo 'и backup_set_id = (выберите max (backup_set_id) из msdb..backupset, где database_name = N'SQLShackDemo

) если значение @backupSetId равно нулю, начало ошибки (ошибка N'Verify.Информация о резервной копии для базы данных «SQLShackDemo» не найдена. », 16, 1) end

ВОССТАНОВЛЕНИЕ ПРОВЕРКИ ТОЛЬКО С ДИСКА = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak ' С ФАЙЛОМ = @backupSetId, NOUNLOAD, NOREWIND

GO

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

  1. Запрос на создание резервной копии базы данных: этот раздел включает команду резервного копирования базы данных.

    РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ [SQLShackDemo] НА ДИСК = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak 'WITH NOFORMAT, NOINIT,

    NAME = N'SQLShackDemo-Full Database Backup ', SKIP, NOREWIND, NOUNLOAD, STATS = 10

    GO

  2. Проверка резервной копии SQL с использованием «ТОЛЬКО ВОССТАНОВЛЕНИЕ ВЕРИФИКАЦИИ»: этот раздел включает команду для проверки резервной копии и сообщения об ошибке, если таковая имеется.

    объявить @backupSetId как int

    выбрать @backupSetId = position from msdb..backupset, где database_name = N'SQLShackDemo 'и backup_set_id = (выбрать max (backup_set_id) из msdb..backupset, где database_name = N'SQLShackDemo

    ') если @backupSetId имеет значение null begin raiserror (Ошибка N'Verify. Информация о резервной копии для базы данных "SQLShackDemo" не найдена. ', 16, 1) end

    ВОССТАНОВЛЕНИЕ ПРОВЕРКИ ТОЛЬКО С ДИСКА = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak 'С ФАЙЛОМ = @backupSetId, NOUNLOAD, NOREWIND

    GO

SQL Server делает резервную копию в формате Microsoft Tape Format (MTF). Если мы берем резервную копию базы данных только с опцией «проверить резервную копию по завершении», она выполняет только несколько проверок блоков набора резервных копий в MTF. Он не проверяет фактические блоки данных. Поэтому, согласно передовой практике, мы должны объединить оба варианта, как показано на следующем изображении, и выполнить резервное копирование:

Мы можем увидеть приведенный ниже сценарий с контрольной суммой в команде резервного копирования и RESTORE VERIFYONLY в команде проверки.

РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ [SQLShackDemo] НА ДИСК = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak 'WITH NOFORMAT, NOINIT, NAME = N'SQLShackDemo-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM

GO

объявить @backupSetId как int

select @backupSetId = position from msdb..backupset, где database_name = N'SQLShackDemo 'и backup_set_id = (backup_set) из msdb..backupset, где database_name = N'SQLShackDemo ')

, если @backupSetId имеет значение null begin raiserror (Ошибка N'Verify. Информация о резервной копии для базы данных «SQLShackDemo» не найдена.', 16, 1) end

ВОССТАНОВЛЕНИЕ ВЕРИФИ ТОЛЬКО С ДИСКА = N'C: \ Program Files \ Microsoft SQL Server \ MSSQL15.SQL2019 \ MSSQL \ Backup \ SQLShackDemo.bak 'WITH FILE = @backupSetId, NOUNLOAD, NOREWIND

GO

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

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

Работая старшим консультантом администратора баз данных для крупных заказчиков и получив сертификат MCSA SQL 2012, он любит делиться знаниями в различных блогах.
С ним можно связаться по адресу [email protected]

Посмотреть все сообщения Rajendra Gupta

Последние сообщения Rajendra Gupta (посмотреть все) .

Лучшие 3 инструмента для восстановления удаленного / поврежденного или утерянного файла BAK

Я только что потерял документ, который мне действительно нужен для презентации на следующей неделе. Я попытался проверить файл BAK на своем компьютере, но понял, что удалил его на прошлой неделе, потому что пытался освободить место на моем диске. Как мне восстановить bak файл?

Потеря важных файлов с вашего компьютера может раздражать, особенно если вы удалили bak-файл, который может помочь вам восстановить копию утерянных данных.На этой странице мы научим вас, как легко восстановить удаленные / поврежденные или потерянные файлы BAK.

Что следует знать о файле BAK

Файлы с расширением «.bak» не являются обычным явлением на вашем компьютере. Этот файл может показаться недоступным, или вам может быть интересно, что это за файл. Файл BAK - это, по сути, резервная копия файла, обычно известного с расширением ".bak". Различные приложения часто делают копию файла с добавлением .bak к имени файла исключительно в целях резервного копирования.

Можно ли удалить файл BAK?

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

Как восстановить удаленный / поврежденный или утерянный файл BAK?

1 Комплексное решение для восстановления - iMyFone AnyRecover

AnyRecover - это лучший инструмент для восстановления данных, который может восстанавливать удаленные или утерянные файлы с вашего жесткого диска и других съемных носителей, таких как внешние жесткие диски, USB-накопители, карты памяти и т. Д.Самое замечательное в этом инструменте то, что он может обнаруживать и восстанавливать любые файлы на вашем диске, включая файлы BAK, не затрагивая никакие файлы на вашем компьютере. Это отличный инструмент восстановления, который вы можете использовать для восстановления потерянного файла BAK, и его легко использовать.

1000000 + загрузок

Основные характеристики AnyRecover:

AnyRecover может восстанавливать потерянные или удаленные / поврежденные файлы на любом носителе, например на флэш-накопителе, внешнем и внутреннем жестком диске, картах памяти и т. Д.

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

Восстанавливает потерянные файлы без перезаписи других файлов, обеспечивая 100% безопасное восстановление данных.

Очень проста в использовании даже без каких-либо технических знаний.

Предлагает бесплатную пробную версию перед покупкой и 30-дневную гарантию возврата денег.

Загрузить сейчасЗагрузить сейчас

Как восстановить удаленный файл BAK с помощью AnyRecover?

Шаг 1: Запустите AnyRecover на своем компьютере и выберите место, где вы потеряли файл BAK.

Шаг 2: Нажмите кнопку «Пуск», AnyRecover начнет сканирование, по завершении отобразятся ваши удаленные файлы.

Шаг 3: Предварительный просмотр отображаемых файлов, затем выберите файл BAK, который нужно восстановить, и нажмите «Восстановить», чтобы восстановить файл BAK.

2 Восстановление удаленных / потерянных файлов BAK с помощью программы для восстановления удаленных / потерянных файлов Remo

Еще одно отличное программное обеспечение, которое вы можете использовать для восстановления удаленных / потерянных файлов BAK, - это программа для восстановления файлов Remo.Он может восстанавливать удаленные или утерянные данные с нескольких устройств хранения, таких как жесткие диски, флэш-накопители, SD-карта и другие. Это программное обеспечение может восстановить все ваши данные в Windows 10, 8, 7, Vista, XP, server 2003, 2008 и 2003.

Шаги по использованию

Шаг 1: Загрузите и установите программу восстановления файлов Remo на свой компьютер .

Шаг 2: Запустите программное обеспечение и выберите «Восстановить файлы» в главном интерфейсе.

Шаг 3: Выберите вариант «Восстановить удаленные файлы» или «Восстановить потерянные файлы».

Шаг 4: Теперь вы увидите все доступные диски, выберите диск, на котором нужно восстановить файл BAK, и нажмите «Далее».

Шаг 5: После сканирования вы можете просмотреть восстановленные файлы и сохранить.

Плюсы

Минусы

  • Он может восстановить тысячи удаленных файлов.

  • Очень удобный с пошаговыми инструкциями.

  • Очень хорошо восстанавливает файлы jpg.

  • Вы можете приостановить процесс восстановления, чтобы возобновить его позже.

  • При сканировании с большого диска может быть сложно найти конкретный файл.

  • Лучше всего работает только с дисками малого объема.

  • Требуется больше времени на сканирование.

3 Восстановление поврежденных файлов BAK с помощью Stellar Toolkit для MS SQL

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

    MS SQL установлен и запущен.

    Сервисы MS SQL запущены.

    Не забудьте сохранить восстановленные файлы BAK в форматах MSSQL (MDF) CSV, HTML и XLS.

Ниже приведены шаги для использования этого инструмента:

Шаг 1: Загрузите, установите и запустите Stellar Toolkit для MS SQL на вашем компьютере. Щелкните значок «Восстановление из резервной копии SQL».

Шаг 2: В доступном программном обеспечении щелкните файл выбора и укажите расположение и имя файла BAK, который вы хотите восстановить, если вы не знаете расположение и имя файла BAK, нажмите кнопку поиска папку и щелкните файл поиска, и отобразятся все расширения BAK.

Шаг 3: Выберите файл BAK, который необходимо восстановить, затем нажмите кнопку «Сканировать».

Шаг 4: Выберите «Резервный набор», затем выберите правильный резервный набор и нажмите «Далее».

Шаг 5: Перейдите на главную вкладку, затем нажмите кнопку «Сохранить», установите флажок для MS SQL, выберите путь назначения и «ОК».

Шаг 6: Выберите параметр для сохранения восстановленной базы данных SQL из резервной копии.Выберите «Новая база данных».

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

Шаг 8: Файл BAK сохранен.

Заключение

Восстановление потерянных или удаленных файлов BAK можно быстро выполнить, если без каких-либо проблем использовать один из вышеупомянутых инструментов восстановления, поэтому вам не придется беспокоиться о потере файлов резервных копий. Из всех упомянутых инструментов iMyFone AnyRecover оказался лучшим решением, поскольку он может восстанавливать любые потерянные файлы с любого носителя.Не стесняйтесь попробовать его бесплатно и немедленно верните потерянные данные.

Загрузить сейчасЗагрузить сейчас

.

Как восстановить .bak файл базы данных SQL Server 2012 на C #?

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

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