Ms sql резервное копирование через скрипт. Как настроить ежедневное резервное копирование с помощью SQL Server Express? Решение проблем при настройке DatabaseMail

Обширный функционал Bacula Enterprise Edition, помимо прочего, позволяет быстро и просто создавать бэкапы БД под . Например, речь идет об инструменте, с помощью которого можно осуществлять резервное копирование 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, позволяющая создавать именованный канал между программами.
стандартные маски задают наборы строк с подстановочными знаками. Например, стандартная маска production* будет включать строки production1 и production2.
строка
целое число.
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 и конфигурирование БД

Восстановление базы 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 = Используется для того, чтобы указать, что запись в журнале транзакций, которая находится непосредственно перед флагом, и является точкой восстановления. Точкой восстановления может служить дата и время, номер LSN или имя флага mark_name.
Stop_at_mark. Условие WITH STOPATMARK =Используется для того, чтобы показать, что помеченная транзакция является точкой восстановления. STOPATMARK перемещается вперед к флагу и включает повтор помеченной транзакции. Точкой восстановления может служить дата и время, номер LSN или имя флага mark_name.
Stop_at=. Условие WITH STOPAT = используется для того, чтобы указать, что точкой восстановления является дата/время.
Restrict_user. Условие WITH RESTRICT_USER используется для ограничения доступа к восстановленной БД. По умолчанию используется значение no.

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

LSN

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
Выберите последний файл полного бэкапа “data.bak” (LSN: 10)
Выберите инкрементальный бэкап “log-10.trn”

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

Таблица 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 как показано на рисунке ниже.

А также: бэкап SQL, бэкап 1С.

Серверная 1С содержит данные в базе данных, которая находится на SQL сервере. Сегодня мы рассматриваем вариант MS SQL 2005/2008.

Чтобы данные не были потеряны в случае сгоревшего диска сервера или других форс-мажорных ситуаций – необходимо с самого начала делать бэкапы (backup).

Делать ручками каждый день Backup SQL базы 1С конечно никто не хочет. Для этого есть автоматические средства. Познакомимся с ними.

Настройка Backup SQL

Настройка Backup SQL для базы 1С ничем не отличается от настройки бэкапа для любой другой базы данных.

Для настройки запустите MS SQL Management Studio. Эта программа находится в группе программ MS SQL.

Добавление задания бэкапа SQL базы 1С

Задания автоматического бэкапа баз SQL находятся в ветке Management / Maintenance plans.

Чтобы добавить новое задание бэкапа щелкните на группу Maintenance plans правой кнопкой мыши и выберите New Maintenance Plan.

Введите название задания. Название имеет значение только для Вас. На всякий случай лучше использовать английские символы.

Настройка задания бэкапа SQL базы 1С

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

Список вариантов операций выведен слева внизу. Выберите Back Up Database Task двойной кнопкой мыши или просто перетащите вправо.

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

В окне настройки выберите нужные базы SQL 1С (можно сразу несколько или по одной).

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

Теперь настроим расписание backup. Расписание backup по-умолчанию добавилось само. Но Вы можете добавить несколько расписаний (например, одно – ежедневное, одно – еженедельное и т.п.). Нажмите кнопку настройки расписания backup.

На скриншоте пример ежедневного Backup SQL базы 1С в 3 ночи.

Чтобы расписание backup в списке было красиво-понятным, его можно изменить.

Сохранение задания бэкапа SQL базы 1С

Нажмите записать. Задание появится слева в списке.

Это важно! Проверьте правильность создания задания Backup SQL базы. Для этого нажмите на задании правой кнопкой и выберите Execute.

В результате должен появится файл бэкапа по указанному пути. Если что-то не так – удалите задание (Del) и начните с начала.

Несмотря на то, что в наших предыдущих материалах мы уже касались вопроса резервного копирования баз Microsoft SQL Server, читательский отклик показал необходимость создания полноценного материала с более глубокой проработкой теоретической части. Действительно, выполненные с упором на практические инструкции статьи позволяют быстро настроить резервное копирование, но не объясняют причины выбора тех или иных настроек. Постараемся исправить этот пробел.

Модели восстановления

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

Как известно, база данных MS SQL состоит из двух частей: собственно, базы данных и лога транзакций к ней. База данных содержит пользовательские и служебные данные на текущий момент времени, лог транзакций включает в себя историю всех изменений базы данных за определенный период, располагая логом транзакций мы можем откатить состояние базы на любой произвольный момент времени.

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

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

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

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

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

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

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

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

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

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

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

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

Журнал транзакций

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

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

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

Та часть журнала, которая содержит активные транзакции и используется для восстановления данных называется активной частью журнала. Она начинается с номера, который называется минимальным номером восстановления (MinLSN).

В простейшем случае MinLSN - это номер записи первой незавершенной транзакции. Если посмотреть на рисунок выше, то открыв синюю транзакцию мы получим MinLSN равную 321, после ее фиксации в записи 324, номер MinLSN изменится на 323, что будет соответствовать номеру зеленой, еще не зафиксированной, транзакции.

На практике все немного сложнее, например, данные закрытой синей транзакции могут быть еще не сброшены на диск и перемещение MinLSN на 323 сделает восстановление этой операции невозможной. Для того, чтобы избежать таких ситуации было введено понятие контрольной точки. Контрольная точка создается автоматически при наступлении следующих условий:

При явном выполнении инструкции CHECKPOINT. Контрольная точка срабатывает в текущей базе данных соединения.
При выполнении в базе данных операции с минимальной регистрацией, например, при выполнении операции массового копирования для базы данных, на которую распространяется модель восстановления с неполным протоколированием.
При добавлении или удалении файлов баз данных с использованием инструкции ALTER DATABASE.
При остановке экземпляра SQL Server с помощью инструкции SHUTDOWN или при остановке службы SQL Server (MSSQLSERVER). И в том, и в другом случае будет создана контрольная точка каждой базы данных в экземпляре SQL Server.
Если экземпляр SQL Server периодически создает в каждой базе данных автоматические контрольные точки для сокращения времени восстановления базы данных.
При создании резервной копии базы данных.
При выполнении действия, требующего отключения базы данных. Примерами могут служить присвоение параметру AUTO_CLOSE значения ON и закрытие последнего соединения пользователя с базой данных или изменение параметра базы данных, требующее перезапуска базы данных.

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

Усечение журнала транзакций

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

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

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

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

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

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

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

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

Простая модель восстановления

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

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

Полная модель восстановления

Рассмотрим аналогичную ситуацию, но с применением полной модели восстановления. Резервные копии у нас также делаются ежесуточно, по принципу полная + разностные, а также несколько раз в сутки копируется лог транзакций.

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

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

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

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

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

С другой стороны, если одна из копий лога транзакций будет повреждена, скажем, предпоследняя, то восстановить данные мы сможем только на момент последней резервной копии + период в неповрежденной цепочке копий журналов. Например, если журналы делались в 12, 14 и 16 часов и поврежден журнал, созданный в 14 часов, то располагая суточной копией мы сможем восстановить базу до момента окончания непрерывной цепочки, т.е. до 12 часов.

Теги:

Please enable JavaScript to view the

Рассмотрим, как организовать две наиболее часто встречающиеся задачи администрирования SQL Server’а:

Автоматическое резервное копирование баз данных;
Удаление старых резервные копии.

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

Откройте SQL Management Studio и подключитесь к требуемой базе данных. Убедитесь, что SQL Server Agent работает;
Разверните узел Management – Maintenance (для этого у Вас должна быть роль «SYSADMIN») – щелкните правой кнопкой и выберите «New Maintenance Plan»;
Введите имя нового плана обслуживания;
Щелкните по иконке календаря справа в единственной строке. В открывшемся окне сконфигурируйте время выполнения задания. Выберите такое время, когда база данных меньше загружена;
Из раздела Toolbox перетащите задачу Backup Database Task в основную область;
Дважды щелкните по Backup Database Task – откроется окно настроек задачи резервного копирования – задайте нужные настройки;
Щелкните ОК – теперь резервные копии будут создаваться в соответствии с запланированным временем;

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

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

Из панели Toolbox перетащите в основную область задачу Maintenance Cleanup Task;
Дважды щелкните по Maintenance Cleanup Task, чтобы открыть окно свойств. В нем Вы должны определить расположение резервных копий, их расширение и определить возраст файлов подлежащих удалению. Хорошей практикой является хранение бэкапов до одного месяца;
Жмите ОК и сохраняете план обслуживания;
Дальше можете либо дождаться следующего времени выполнения плана обслуживания, либо выполнить его вручную (правой кнопкой мыши по плану обслуживания в Object Explorer).

Script для динамического резервного копирования всех баз данных на сервере. Затем создайте пакетный файл в соответствии со статьей. Полезно создавать два командных файла: один для полного резервного копирования и один для резервного копирования. Затем создайте две задачи в планировщике заданий, один для полного и один для diff.

-- // Copyright © Microsoft Corporation. All Rights Reserved. -- // This code released under the terms of the -- // Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.) USE GO /****** Object: StoredProcedure . ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ============================================= -- Author: Microsoft -- Create date: 2010-02-06 -- Description: Backup Databases for SQLExpress -- Parameter1: databaseName -- Parameter2: backupType F=full, D=differential, L=log -- Parameter3: backup file location -- ============================================= CREATE PROCEDURE . @databaseName sysname = null, @backupType CHAR(1), @backupLocation nvarchar(200) AS SET NOCOUNT ON; DECLARE @DBs TABLE (ID int IDENTITY PRIMARY KEY, DBNAME nvarchar(500)) -- Pick out only databases which are online in case ALL databases are chosen to be backed up -- If specific database is chosen to be backed up only pick that out from @DBs INSERT INTO @DBs (DBNAME) SELECT Name FROM master.sys.databases where state=0 AND name=@DatabaseName OR @DatabaseName IS NULL ORDER BY Name -- Filter out databases which do not need to backed up IF @backupType="F" BEGIN DELETE @DBs where DBNAME IN ("tempdb","Northwind","pubs","AdventureWorks") END ELSE IF @backupType="D" BEGIN DELETE @DBs where DBNAME IN ("tempdb","Northwind","pubs","master","AdventureWorks") END ELSE IF @backupType="L" BEGIN DELETE @DBs where DBNAME IN ("tempdb","Northwind","pubs","master","AdventureWorks") END ELSE BEGIN RETURN END -- Declare variables DECLARE @BackupName varchar(100) DECLARE @BackupFile varchar(100) DECLARE @DBNAME varchar(300) DECLARE @sqlCommand NVARCHAR(1000) DECLARE @dateTime NVARCHAR(20) DECLARE @Loop int -- Loop through the databases one by one SELECT @Loop = min(ID) FROM @DBs WHILE @Loop IS NOT NULL BEGIN -- Database Names have to be in format since some have - or _ in their name SET @DBNAME = "["+(SELECT DBNAME FROM @DBs WHERE ID = @Loop)+"]" -- Set the current date and time n yyyyhhmmss format SET @dateTime = REPLACE(CONVERT(VARCHAR, GETDATE(),101),"/","") + "_" + REPLACE(CONVERT(VARCHAR, GETDATE(),108),":","") -- Create backup filename in path\filename.extension format for full,diff and log backups IF @backupType = "F" SET @BackupFile = @backupLocation+REPLACE(REPLACE(@DBNAME, "[",""),"]","")+ "_FULL_"+ @dateTime+ ".BAK" ELSE IF @backupType = "D" SET @BackupFile = @backupLocation+REPLACE(REPLACE(@DBNAME, "[",""),"]","")+ "_DIFF_"+ @dateTime+ ".BAK" ELSE IF @backupType = "L" SET @BackupFile = @backupLocation+REPLACE(REPLACE(@DBNAME, "[",""),"]","")+ "_LOG_"+ @dateTime+ ".TRN" -- Provide the backup a name for storing in the media IF @backupType = "F" SET @BackupName = REPLACE(REPLACE(@DBNAME,"[",""),"]","") +" full backup for "+ @dateTime IF @backupType = "D" SET @BackupName = REPLACE(REPLACE(@DBNAME,"[",""),"]","") +" differential backup for "+ @dateTime IF @backupType = "L" SET @BackupName = REPLACE(REPLACE(@DBNAME,"[",""),"]","") +" log backup for "+ @dateTime -- Generate the dynamic SQL command to be executed IF @backupType = "F" BEGIN SET @sqlCommand = "BACKUP DATABASE " +@DBNAME+ " TO DISK = """+@BackupFile+ """ WITH INIT, NAME= """ +@BackupName+""", NOSKIP, NOFORMAT" END IF @backupType = "D" BEGIN SET @sqlCommand = "BACKUP DATABASE " +@DBNAME+ " TO DISK = """+@BackupFile+ """ WITH DIFFERENTIAL, INIT, NAME= """ +@BackupName+""", NOSKIP, NOFORMAT" END IF @backupType = "L" BEGIN SET @sqlCommand = "BACKUP LOG " +@DBNAME+ " TO DISK = """+@BackupFile+ """ WITH INIT, NAME= """ +@BackupName+""", NOSKIP, NOFORMAT" END -- Execute the generated SQL command EXEC(@sqlCommand) -- Goto the next database SELECT @Loop = min(ID) FROM @DBs where ID>@Loop END

И пакетный файл может выглядеть так:

Sqlcmd -S localhost\myDB -Q "EXEC sp_BackupDatabases @backupLocation="c:\Dropbox\backup\DB\", @backupType="F"" >> c:\Dropbox\backup\DB\full.log 2>&1

Sqlcmd -S localhost\myDB -Q "EXEC sp_BackupDatabases @backupLocation="c:\Dropbox\backup\DB\", @backupType="D"" >> c:\Dropbox\backup\DB\diff.log 2>&1

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