В данной статье будет рассказано как вручную сделать полную резервную копию базы данных в с помощью программы «Среда Microsoft SQL Server Management Studio».
1. Создание резервной копии
На самом деле все довольно просто. Запускаем оснастку «» («Пуск » — «Все программы » — «SQL Server 2008 R2 » — «Среда Microsoft SQL Server Management Studio ») и вводим данные для авторизации.
После чего в Обозревателе объектов раскрываем вкладку «Базы данных » и кликнем правой кнопкой мыши по той базе данных, для которой необходимо сделать резервную копию. В появившемся контекстном меню выберем «Задачи » (Tasks ) — «Создать резервную копию » (Back Up… ) .
Запустится окно «Резервная копия базы данных » (Back Up Data Base ) . Убедимся, что стоит «Полная » (Full ), при необходимости зададим имя и описание, а также укажем назначение резервной копии. По умолчанию выбран путь на жестком диске компьютера в папку Backup основного расположения баз SQL-сервера. Для того чтобы изменить место размещения копии, сначала нажмем «Удалить » (Remove ), чтобы удалить существующее назначение, а затем «Добавить » (Add …) для добавления нового.
Здесь зададим расположение и имя файла резервной копии и нажмем «ОК » . Таких мест назначений можно задать несколько. В этом случае резервная копия будет разбита на равные части, каждая часть в указанном файле.
Когда все настройки установлены, нажимаем «ОК » и дожидаемся завершения задачи. Если все сделано правильно, в указанной директории мы найдем файл резервной копии базы данных SQL.
2. Восстановление базы данных из резервной копии
Восстановление происходит по аналогичной схеме. В «Среде Microsoft SQL Server Management Studio » выбираем базу из которой сделана резервная копия , кликаем по ней правой кнопкой мыши, в контекстном меню выбираем «Задачи » (Tasks ) — «Восстановить » (Restore ) — «База данных… » (Database… ).
Откроется окно «Восстановление базы данных » (Restore Database ). Здесь, в качестве источника укажем «С устройства » (From device ) и выберем файл резервной копии (созданных в пункте 1).
Установим флаг «Восстановить » (Restore ) напротив выбранной резервной копии. При необходимости, на вкладке «Параметры » (Options ), можно указать дополнительные параметры восстановления, о значении которых можно прочитать .
После того, как все настройки сделаны, жмем «ОК » и дожидаемся сообщения об успешном восстановлении базы данных.
3. Восстановление резервной копии в другую базу данных (копирование данных)
Если же необходимо загрузить данные в базу данных, отличную от той из которой была сделана резервная копия , то при загрузке помимо действий, описанных в пункте 2, необходимо на вкладке «Параметры » (Options) задать имена файлов этой базы данных и установить флаг «Перезаписывать существующую базу данных » (WITH REPLACE).
Помогла ли Вам данная статья?
Данная статья посвящена решениям для восстановления MS SQL. Постараемся рассмотреть основные моменты и важные детали, которые необходимо учесть, при планировании и выборе решения для восстановления базы данных MS SQL.
В рамках планирования аварийного восстановления MS SQL особый интерес представляют два параметра: допустимое время восстановления (recovery time objective - RTO) и допустимая точка восстановления (recovery point objective - RPO).
RPO иными словами, это период времени с момента последнего резервного копирования до момента инцидента, за который будет потерян не критичный объём данных (информации). RTO - это допустимое время, за которое необходимо восстановить работоспособность сервиса/системы с момента инцидента. Оба параметра имеют переменное значение и зависят от требований к той или иной системе. Поэтому для выполнения, установленных RPO и RTO необходимо иметь соответствующий план резервного копирования. На примере, проведём анализ возможных аварийных инцидентов и попробуем выделить точки отказа нашего SQL сервера и способы их решения:
- аппаратный сбой, физический выход сервера из строя: диски, CPU, системная плата, блок питания и т.д.
- программный сбой: операционная система, база данных
Для каждого обозначенного инцидента есть целый комплекс мер, позволяющий избежать последствия инцидента.
HIGH AVAILABILITY MS SQL
При высоких требованиях к RPO и RTO (секунды/минуты) единственным решением для обеспечения отказоустойчивости MS SQL является организация технологии высокой доступности сервера (High Availability):
- Встроенными средствами MS SQL и ОС Windows Server мы можем достичь высокой доступности (High Availability) за счет реализации отказоустойчивого кластера Windows Server Failover Cluster (WSFC) в том числе и с применением технологии AlwaysOn. Отказоустойчивый кластер состоит как минимум из двух узлов/серверов. При сбое активного сервера, происходит аварийное переключение на другой доступный сервер, он становится активным. При этом все службы, которые размещались на сервере автоматически или вручную переносятся на другой доступный узел.
- В случаи, с виртуальной машиной MS SQL высокую доступность можно обеспечить c помощь средств виртуализации VMware HA-cluster или Hyper-V High Availability. В этом случае при выходе из строя физического сервера, позволяет автоматически запустить виртуальную машину на другом сервере кластера.
Оба способа могут быть реализованы как по отдельности, так и совместно, если в этом есть необходимость. Кластеризация в большей степени рассчитана для оперативного устранения аппаратного сбоя.
Преимущества High Availability MS SQL:
- мгновенное переключение с ноды на ноду, без простоя
- без зависимости от физических серверов
- позволяет проводить обслуживание серверов без перерыва в работе с базой данных
Недостатки High Availability MS SQL:
- реализации требует дополнительной инфраструктуры и ресурсов
- высокая стоимость решения по лицензиям и оборудованию
- более сложное и высоквалифицированное обслуживание
BACKUP MS SQL
В случаях, когда требования к RTO и RPO не высокие и потребность в High Availability (кластеризации) отсутствует, для обеспечения отказоустойчивости баз данных MS SQL на физическом или виртуальном сервере необходимым условием является наличие резервной копии. Для этого можно задействовать встроенные функции SQL Server или использовать отдельные специализированные системы, поддерживающие различные способы резервного копирования MS SQL, например:
Данные системы помогут избежать как аппаратных, так и программных сбоев в работе сервера базы данных.
После расчета значений RTO и RPO можно перейти к планированию конфигурации SQL сервера. Для достижения этих значений мы можем использовать как технологии высокой доступности, перечисленные выше, так и backup баз данных.
Регламент backup MS SQL
- Резервные копии должны находиться на разных физических носителях с исходными файлами базы данных
- Используйте тестовый сервер (песочница) для проверки процедуры восстановления резервных копий
- Выполняйте ежедневное
- Делайте как можно чаще. Они занимают гораздо меньший объем в хранилище и еще больше сокращают риск потери данных
- Как можно чаще выполняйте резервное копирование журналов транзакций. Журналы транзакций содержат все последние действия, произошедшие в базе данных. Журналы можно использовать для восстановления базы данных на определенный момент времени, и это является самым большим преимуществом. Резервные копии журнала транзакций могут выполняться во время работы системы. Если частота новых данных, создаваемых в вашей базе данных, очень высока, то можно делать резервные копии журнала транзакций каждые 10 минут, в то время как для других баз данных, которые менее активны, такое резервное копирование может выполняться каждые 30 или 60 минут
- Делайте резервное копирование системных баз данных MS SQL: server, master , model и msdb . Эти базы данных абсолютно необходимы, так как содержат конфигурацию системы, а также информацию о задании SQL Server, которую необходимо будет восстановить в случае полного восстановления системы
НАСТРОЙКА РЕЗЕРВНОГО КОПИРОВАНИЯ MS SQL С ПОМОЩЬЮ BACKUP EXEC
Backup Exec предлагает три метода резервного копирования MS SQL: Full, Differential и Full Copy-only. Метод Full выполняет полное резервное копирование всей базы данных, а Differential выполняет резервное копирование только измененых блоков в базе данных с момента последнего полного резервного копирования. Метод Full Copy-only идентичен полному резервному копированию, но только он не влияет на последующие задания дифференциального резервного копирования.
Рассмотрим каждый случай более подробно для этого создадим в системе новое задание для резервного копирования основной и системных баз данных.
Затем, в настройках параметров (опции) выбрать тип задания (сначала настроить Full потом Differential backup).
В Backup Exec есть очень важная и полезная функция «Проверка целостности базы до и после выполнения резервного копирования» (Consistency check before/after backup), имеется на выбор четыре варианта:
- не проводить проверку
- полная проверка, без учёта индексов
- полная проверка с учётом индексов
- только физическая проверка
Для настройки differential backup необходимо (аналогично job full backup) сначала добавить новое задание Job Differential, а затем на вкладке Microsoft SQL выбрать один из методов резервного копирования.
В данном списке в первую очередь интересует «Differential - Backup up database changes since the last full» (создание дифференциальной резервной копии на основании полной). Так же возможен вариант создания дифференциальной резервной копии (на уровне блоков) с последующей конвертацией в виртуальную машину «Differential (block-level) - Backup up database changes since the last full – use with convert to virtual machine job» .
Еще одним важным параметром является «Log - Back up and truncate transaction log» для резервного копирования журнала транзакций MS SQL.
Мы рассмотрели основные моменты резервного копирования MS SQL. Обращаем внимание, что резервное копирование является частью общего плана аварийного восстановления (DRP), поэтому, перед планированием резервного копирования, необходимо провести полный анализ систем и инфраструктуры, для обеспечения RPO и RTO. А если есть возможность выполнить планирование DRP при разработке системы, это поможет исключить многие проблемы и, возможно, удешевит эксплуатацию системы.
Используемая в статье информация взята из официальных источников.
sqlcmd -S DECLSERVER\SQLGTD -E -Q «declare @s varchar(255) set @s=’E:\backup\GTD_’ + convert(varchar(1), datepart(dw, getdate())) + ‘.bak’ backup database GTD to disk = @s with init, noformat, skip, nounload»
sqlcmd позволяет вводить инструкции Transact-SQL, системные процедуры и файлы скриптов из командной строки в редактор запросов в режиме SQLCMD,
- -S - задает имя сервера, server[\instance_name] ;
- DECLSERVER\SQLGTD - имя сервера/имя экземпляра, на котором крутится база;
- -E - использует для соединения с SQL server вместо имени пользователя и пароля доверительное соединение;
- -Q «cmdlinequery « - при запуске программы sqlcmd выполняет запрос, но выход из программы по завершении его выполнения не производится. Может быть выполнено несколько запросов, разделенных точкой с запятой. Заключайте запрос в кавычки, как показано выше;
- declare - объявляем переменную s ,имя переменной всегда начинается с @, поэтому @s . В нашем случае @s - это папка (диск) хранения бэкапов;
- varchar(n) - задает тип переменной @s как строковый с длинной строки n, в примере 255 символов;
- set - задает значение переменной @s ,в примере это папка backup на диске E (E:\backup\ ), далее задается имя бэкап файла, где набор функций convert(varchar(1), datepart(dw, getdate())) возвращает в текстовом формате с длиной в 1 символ текущий день недели (понедельник – 1 , вторник – 2 , и т.д.) и добавляется расширение bak . На выходе получим файл с именем GTD_НомерДняНедели.bak ;
- backup - создает бэкап;
- database - указывает на создание бэкапа всей базы;
- GTD - в нашем примере имя базы на SQL-сервере;
- to disk - указывает на тип устройства резервного хранения, файл жесткого диска, и указана переменная @s , которой присвоено путь и имя создаваемого файла;
- with init, noformat, skip, nounload - указывает на то, что необходимо произвести перезапись данных по кругу с переопределением заголовков, что позволит нам иметь 7 файлов бэкапа на каждый день недели, перезаписываемые по кругу.
При необходимости можно использовать и другие функции, например сжатие, см. справку по запросам и функциям Transact-SQL.
Шаг 2. Меняем расширение текстового файла на.cmd
В итоге получаем файл backupGTD.cmd . Запускать созданный командный файл необходимо с той машины, где установлена БД MS SQL.
Шаг 3. Автоматизируем данный процесс
Рассмотрим данный шаг на примере MS Windows Server 2008: Диспетчер сервера -> Конфигурация -> Планировщик заданий -> Библиотека планировщика заданий.
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)
Для просмотра данной информации необходимо раскрыть соответствующую группировку в отчете.
Помогла ли Вам данная статья?
После изучения множества информации с разных источников, решил описать процесс настройки резервного копирования БД MS SQL Server для полной модели восстановления, какую модель использовать решать Вам, но от себя добавлю, что если в вашей БД большой поток информации (например создаются десятки, сотни или тысячи документов в 1 час), то потеря информации за день работы будет просто неприемлемой, в таком случае только полная модель обеспечит сохранность ваших данных. Данна статья предназначена для начинающих системных администраторов и содержит по моему мнению минимальный набор действий для резервного копирования БД 1С. Установка\Настройка самого SQL сервера и развертывание БД на нём в не рамках данной статьи.
Все настройки будем производить с помощью SQL Management Studio. Для начала нужно создать Устройство резервного копирования, можно и не создавать, но на мой взгляд это гораздо удобнее и правельнее. в оснастке SQL Management Studio -> Объекты сервера-> Устройства резервного копирования. Нужно указать имя устройства и файл в котором будут храниться резервные копии (лучше с расширением BAK), в дальнейшем можно посмотреть содержимое носителя, там будут перечислены все резервные копии.
Теперь можно приступать к настройки Плана обслуживания (Maintenance Plan). План Обслуживания можно создать сразу для всех БД, но удобнее для каждой БД создать свой план обслуживания.
В нашем Плане обслуживания будет три подплана: 1 - резервное копирование БД (Полное); 2 - резервное копирование БД (Разностное); 3 - Резервное копирование Журнала транзакций. У каждого подплана есть свое расписание выполнения. Раписание каждый настраивает по своим усмотрениям, в моём же случае полное копирование делается раз в неделю в воскресенье, Разностное копирование каждый день кроме воскресенья, ЖТ - журнал транзакций каждый час. При такой модели резервирования можно восстановить искомую БД на любую дату и час, причем экономим пространство на жёстком диске т.к. полное резервирование выполняется фактически раз в неделю, а в течении недели только изменения.
Настройка дневного расписания. Недельное отличается только установленной галочкой "Воскресенье" и снятыми с "понедельника" по "Субботу"
Расписание для ЖТ. Красным выделено время сохранения в течении дня, имеет смысл например, если пользователи работают с БД в определённый период, если режим работы 24х7, то оставляем по уполчанию.
На рисунке ниже, изображен редактор недельного подплана, он состоит из задач, которые выполняются в заданной последовательности. Последовательность задается вручную, причем зелёные стрелки означают, что следущая задача будет выполнена только при успешном выполнении предыдущей, а синяя, что задача выполнится при любом завершении предыдущей задачи. В редактор подплана обслуживания, задачи можно добавить из "Панель элементов", которая находится в левом верхнем углу, когда редактор открыт.
Задачи. В каждую задачу нужно зайти и выбрать БД, для которой она будет выполняться и ряд других настроеек (если есть). Рассмотрим, какие задачи содержит недельный подплан нашего плана обслуживания.
1. "Проверка целостности БД" (Check Database Integrity Task). Следующая задача будет выполняться, только если БД не содержит ошибок. (Замем резервировать БД с ошибками?)
2. "Восстановить индекс" (Rebuild Index Task). Восстановить (Перестроить) индекс необходимо каждый день, т.к. при работе с индексами они сильно фрагментируются и при фрагментации более 25% SQL начинает заметно "тормозить". Эта операция довольно ресурсоёмка, поэтому её можно делать хотябы раз в неделю, а в дневном подплане заменить её менее ресурсоёмкую задачу "Реорганизация индекса".
3. "Обновить статистику" (Update Statistics Task). Для оптимизации... Кстати эту задачу можно выполнять несколько раз в течении дня, если ваша БД сильно нагружена.
4. После обновления статистики ОБЯЗАТЕЛЬНО нужно очистить процедурный кэш. Для этого перетаскиваем в редактор задачу "Выполнение инструкции T-SQL" и в поле "инструкция T-SQL:" написать процедуру DBCC FREEPROCCACHE . Но нужно учесть, что эта процедура очищает кэш у ВСЕХ БД, а мы обновили статистику по одной! Как очистить процедурный кэш для определённой БД, читаем . Вкратце: DBCC FLUSHPROCINDB(ID_БД)
5. "Резервное копирование БД" (Back Up Database Task). В этой задаче указываем какую БД мы резервируем, тип резервной копии (Для недельного подплана - Полное, для дневного - Разностное, для часового - Журнал транзакций.) Ставим переключатель в положение "Создать резервную копию баз данных в одном или нескольких файлах" и добавляем ранее созданное устройство резервного копирования. В таком случае ВСЕ копии сохраняются в один файл, который указали при создании устройства резервного копирования, если переключатель оставить в "Создать файл резервной копии для каждой базы данных", то на каждое резервное копирование будет создаваться отдельный файл и на Полное и на Разностное и на ЖТ, что очень неудобно при восстановлении, зато удобно при хранении. Не забываем укзать что нужно сжимать резервные копии!
6. "Очистка Журнала" Очищает записи, создаваемые при выполнении задач. Также можно включить задачу "Очистка после обслуживания" и настроить её для удаления текстовых логов или устаревших резервных копий.
Подплан для резервирования ЖТ, состоит из одной задачи "Резервное копирование базы данных".ЖТ для меня удобнее сохранять не в Устройство резервного копирования, а в отдельный файл, что необходимо указать в настройке задачи.
