Резервирование sql. SQL. Настройка резервного копирования

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

1. Используйте разностные копии БД, если создание полной копии БД занимает большой промежуток времени
2. Периодически делайте полную копию БД, чтобы уменьшить объемы создаваемых разностных копий.
3. После создания полной копии БД, все предыдущие разностные копии теряют свою актуальность.

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

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

Пример SQL для создания резервной разностной копии БД с проверкой копии по завершению (отличается от полного копирования флагом DIFFERENTIAL вместо него нужно использовать NOFORMAT ).

Declare @pathBackup as varchar(55) set @pathBackup = N"C:\Backup\[Имя файла БД]_" + REPLACE(convert(varchar,GETDATE(), 104),".","_") + ".bak" BACKUP DATABASE [Имя базы данных] TO DISK = @pathBackup WITH DIFFERENTIAL, NOFORMAT, INIT, NAME = N"Полная База данных Резервное копирование", SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM GO declare @backupSetId as int declare @pathBackup as varchar(55) set @pathBackup = N"C:\Backup\[Имя файла БД]_" + REPLACE(convert(varchar,GETDATE(), 104),".","_") + ".bak" select @backupSetId = position from msdb..backupset where database_name=N"[Имя базы данных]" and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N"[Имя базы данных]") if @backupSetId is null begin raiserror(N"Ошибка верификации. Сведения о резервном копировании для базы данных "[Имя базы данных]" не найдены.", 16, 1) end RESTORE VERIFYONLY FROM DISK = @pathBackup WITH FILE = @backupSetId, NOUNLOAD, NOREWIND GO

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

Помимо основной базы и связанных с ней файлов, я настоятельно рекомендую делать копии и системных баз данных. Начнем с того, что рассмотрим какие базы существуют в MS SQL. Их всего 5:

Я выбрал резервировать только 2 системные БД:

1. msdb – потому что, там хранятся настроенные задачи и другие
2. master – хранятся все произведенные настройки SQL Server.

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

4. План бекапирования

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

Мы будем делать следующие резервные копии:

• Полная копия основной БД, чаще чем раз в неделю нет необходимости
• Разностная копия основной БД, каждый день
• Копии журнала транзакций основной БД, каждый час
• Копия системной БД master, раз в неделю
• Копия системной БД msdb, раз в неделю

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

День недели	Время	Действия	Частота	Описание
Понедельник - Пятница	С 8-00 до 21-00	Резервные копии Журнала транзакций	Каждый час	После выполнения резервной копии БД идет сжатие и усечение журнала транзакций
Суббота - Воскресенье	С 8-00 до 18-00
Понедельник - Воскресенье	22-00	Разностная копия основной БД	1 раз в день	После успешного выполнения разностной копии удаляются все старые копии журнала транзакций
Суббота	12-00	Проверка БД	1 раз в день	Проверка БД Дело на целостность.
Суббота	18-00	Создание полной копии БД	1 раз в день	По завершению данной операции идет уведомление на почту. Если создание резервной копии прошло удачно, удаляется старая полная резервная копия все старые разностные копии все старые журналы транзакций
Понедельник - Воскресенье	23-30	Создание копии системной базы master	1 раз в день
Воскресенье	12-30	Создание копии системной базы msdb	1 раз в месяц	Хранится всегда только последний экземпляр БД

1. Используйте опцию BACKUP WITH CHECKSUM
   чтобы убедиться, что все прошло хорошо. Недостатком такого решения является то, что для больших баз данных проверка контрольной суммы может серьезно загрузить систему.
2. Не выполняйте резервное копирование файлов на тот же физический диск, на котором хранится база данных или протокол транзакций.
3. Если вы используете MS SQL 2008 или выше, рекомендую вам использовать сжатие резервных копий средствами SQL. Следующий код включит сжатие по умолчанию: USE master; GO EXEC sp_configure ‘backup compression default’, "1"; RECONFIGURE WITH OVERRIDE;
4. держите резервные копии по нескольку дней на случай, если одна из них будет повреждена – старая резервная копия лучше, чем никакой.
5. Используйте DBCC CHECKDB для проверки каждой базы данных перед копированием, это своевременно предупредит вас о надвигающихся проблемах. DBCC CHECKDB ("Имя базы данных") WITH NO_INFOMSGS, ALL_ERRORMSGS; Примечание: на практики мы использовали данную проверку, только перед выполнением полной резервной копии.
6. Выполняйте периодически обновление статистики и реорганизации индексов БД

Используем приложение

Несколько нюансов по приложению:

• Все тексты и запросы в коде вынесены в ресурсы, мне так было проще
• При вводе параметров соединения и других настроек, они сохраняются в файл. Для Express и Standart используются разные файлы (dbStandart, udExpress) в них хранится класс UserData
• Для выполнения некоторых операций могут потребоваться права администратора
• На данный момент не работает соединение с БД под доменной учетной записью
• Программа не обладает суперкрасивым интерфейсом

1. Настройка уведомления администратора

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

Для данной цели используется DatabaseMail MS SQL (для версии Standart и выше)
В своем приложение я сделал специальный раздел для автоматизации данной задачи

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

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

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

1. Меняются системные параметры MS SQL.
2. Создается DatabaseMail Profile
3. Активируется в SQL Agente профиль
4. Создается DatabaseMail Account
5. Добавляется DatabaseMail Account к Database Mail Profile
6. Создается DatabaseMail Operator

Более подробно описано в следующей статье и, частично, я брал отсюда . Естественно, данные действия можно выполнить с помощью SSMS .

2.Дополнительные уведомления для администратора

В программе предусмотрены 2 задачи, применяемые к БД:

1. проверка целостности БД. Для проверки базы данных использовалась стандартная процедура DBCC CHECKDB .
2. информирование о свободном месте в файловых группах.
3. Вторая задача была реализована с помощью запроса к системной таблице dbo.sysfiles
4. Вот пример данного запроса, который выполнялся к базе:

Select NAME = left(a.NAME,15), a.FILEID, = convert(decimal(12,2),round(a.size/128.000,2)), = convert(decimal(12,2),round(fileproperty(a.name,"SpaceUsed")/128.000,2)), = convert(decimal(12,2),round((a.size-fileproperty(a.name,"SpaceUsed"))/128.000,2)) , FILENAME = a.FILENAME From dbo.sysfiles a
Ответ с сервера приходит на почту администратора в виде html разметки. Данный синтаксис возможен благодаря следующей стандартной функции MS SQL FOR XML .

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

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

3.Решение проблем при настройке DatabaseMail

В MS SQL 2008 я столкнулся с проблемой при настройке SQL Server Agent. Симптомы следующие, после настройки невозможно запустить SQL Agent. В основном это решается с помощью установки update на SQL сервер.

Если данные обновления не помогают, необходимо скачать fix. Его можно найти на данном сайте конечную ссылку не могу указать сейчас, для того что бы дойти до пакета фикса, нужно будет ответить на ряд вопросов.
Если есть проблемы с модулем DatabaseMail. После настройки данного модуля с помощью приложения, необходимо зайти в SQL Agent и просмотреть журнал событий. Если там будут ошибки «невозможно подключиться к почтовому ящику». Значит есть проблема, даже если через проверку отправляется письмо.

Исправляется это следующими манипуляциями:

1. Management Studio - SQL Server Agent - Properties.
2. Alert System
3. Уберите галочку с Enable mail profile
4. Нажмите OК
5. Зайдите снова и поставьте галочку
6. Перезагрузите SQL Server Agent.

Проверьте учетную запись для SQL Agent service. Если это доменная учетная запись измените ее на системную или наоборот. Все должно заработать.

4.Настраиваем резервное копирование с помощью приложения для SQL Standart:

Выбираем версию Standart. Настраиваем уведомления. (см. раздел, настройки уведомления):

Соединяемся с БД, заполняя данные для соединения и указываем БД, для которой будет применяться Job:

Выбираем настройку резервного копирования:

Указываем пути для сохранения копий БД. Если указанные папки не существует, то программа попытается их создать (нужны соответствующие права).

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

5.Настраиваем резервное копирование с помощью приложения для SQL Express:

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

Для этого запускаем приложение. Выбираем пункт MS SQL Express:

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

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

Единственный минус данного подхода в том, что приходится храниться в открытом виде пароль для соединения с БД.

6.Удаление задач из БД.

Если необходимо удалить все задачи из БД (например, захотели изменить пути сохранения БД). Для этого используем соответствующий пункт в меню программы. Из SQL Agent будут удалены все задачи с определенным начальным префиксом (в моем случае King):

7.Удаление копий БД

В некоторых задачах, настроено удаление старых копий БД. Для этого я использую процедуру master.dbo.xp_delete_file. Пример использования: Удалит все файлы с расширением bak из указанной папки, дата создания которых превышает 14 дней.
EXECUTE master.dbo.xp_delete_file 0,"E:\backups",N"bak",dateadd(d,-14,getdate()),0;
И вот еще один более подробный пример и информация о том, какие параметры принимает данная функция .

Как восстанавливать резервные копии

Из-за нехватки времени модуль восстановления еще не реализован, возможно в будущем я его добавлю, а пока просто кратко опишу как можно будет восстановить базу.

С помощью SQL скрипта. Для восстановления базы данных используется команда RESTORE .

Если необходимо восстановить просто базу из полной копии, то достаточно выполнить следующий скрипт:
RESTORE DATABASE [Имя базы данных] FROM DISK = "Z:\SQLServerBackups\back.bak" WITH REPLACE
В случае, если необходимо восстановить последовательно сначала полную копию, разностные копии и журналы транзакций, тогда необходимо написать следующий SQL скрипт.

RESTORE DATABASE TEST_DB –восстанавливаем полную копию FROM test_db_full WITH NORECOVERY; GO RESTORE DATABASE TEST_DB –восстанавливаем разностную копию FROM test_db_diff WITH FILE = 1, NORECOVERY; GO RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №1 FROM test_db_tran_1 WITH FILE = 1, WITH NORECOVERY; GO RESTORE LOG TEST_DB –восстанавливаем журнал транзакций №2 FROM test_db_tran_2 WITH FILE = 1, WITH NORECOVERY; GO RESTORE DATABASE TEST_DB WITH RECOVERY; GO
Для восстановления БД можно использовать так же и SSMS .

Теги: Добавить метки

Обновлено: 23.06.2017 Опубликовано: 22.06.2017

Есть несколько способов создания резервной копии MS SQL. Для разовых операций прекрасно подойдет графический инструмент SQL Management Studio. Для автоматизации — Powershell или cmd. Данные операции применяются к любым базам, как для 1С, так и любых других приложений.

С помощью графического интерфейса

Открываем MS SQL Management Studio. Кликаем правой кнопкой мыши по базе, для которой хотим сделать резервную копию - Задачи - Создать резервную копию :

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

После завершения процесса мы увидим сообщение «Резервное копирование базы... успешно завершено».

С помощью командной строки (cmd)

Выполняется при помощи команды sqlcmd.

Синтаксис:

sqlcmd -S -U -P Q "BACKUP DATABASE [] TO DISK = N""

Пример готового скрипта

@echo off
set dd=%DATE:~0,2%
set mm=%DATE:~3,2%
set yyyy=%DATE:~6,4%
set curdate=%dd%-%mm%-%yyyy%
set username=sa
set password=my_pass

Set db=work1

Set db=work2
sqlcmd -S localhost -U %username% -P %password% -Q "BACKUP DATABASE [%db%] TO DISK = N"D:\Backup\MSSQL\%db%_%curdate%.bak" WITH NOFORMAT, NOINIT, NAME = N"%db%-full", SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10"

* в данном примере мы подключаемся к локальному SQL серверу под учетной записью sa с паролем my_pass и делаем резервную копию баз work1 и work2 . Резервные копии размещаем по пути D:\Backup\MSSQL . Имя файлов резервных копий work1_<текущая дата>.bak и work2_<текущая дата>.bak

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

С помощью Powershell

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

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

Синтаксис:

Backup-SqlDatabase -ServerInstance <имя SQL сервера> -Database <имя базы> -BackupFile <путь к файлу с резервной копией>

Пример скрипта на powershell

$server = "SQL01"
$curdate = Get-Date -Format yyyyMMdd

import-module sqlps -DisableNameChecking

$db = work1
Backup-SqlDatabase -ServerInstance $server -Database $db -BackupFile $db_$curdate.bak

* где выполняется резервное копирования базы work1 на сервере SQL01

Также как и для cmd, данный скрипт можно поместить в планировщик для запуска по расписанию.

Срок действия резервного набора данных

Данная настройка позволяет указать, через какой промежуток времени резервную копию можно удалить (перезаписать). Важно понимать, что настройка не влияет на сам период восстановления — если срок истек, восстановиться из набора можно.

Задать параметр можно в основном окне при создании резервной копии:

Путь расположения резервных копий

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

Кликаем правой кнопкой мыши по корневому разделу SQL Server и выбираем свойства:

Переходим в раздел Параметры баз данных (1) - в подразделе «Места хранения, используемые базой данных по умолчанию» мы увидим путь до места размещения резервных копий (2), который можно поменять кнопкой справа (3):

Несмотря на то, что в наших предыдущих материалах мы уже касались вопроса резервного копирования баз 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

MS SQL Server 2000 несмотря на свой преклонный возраст продолжает активно использоваться на просторах нашей страны, во многом "благодаря" системе 1С:Предприятие 7.7, работающему только с этой версией SQL сервера. Второй по важности, после обеспечения бесперебойного функционирования, задачей для системного администратора является организация своевременного резервного копирования данных, этот вопрос мы и рассмотрим в настоящей статье.

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

Перейдем непосредственно к практике. Запускаем Enterprise Manager .

Разворачиваем дерево и выбираем сервер, для которого будем настраивать резервное копирование, в нашем случае это (local) (Windows NT) , щелкаем правой кнопкой мыши и выбираем Cвойства (Properties) , на первой закладке устанавливаем галочку Autostart SQL Server Agent .

Теперь, чтобы не перезагружать сервер, запустим SQL Server Agent вручную. Для этого разворачиваем папку Management и запускаем Agent правой кнопкой мыши, выбрав Start в выпадающем меню.

Переходим к пункту Database Maintenance (ниже в той же папке) и щелкнув ПКМ в свободной области справа выбираем New Maintenance Plan , запустится мастер. Сначала выберем базы, для которых будет действовать этот план (планов может быть несколько), можно выбрать все базы, только системные, только пользовательские или произвольно.

С расписанием особых сложностей возникнуть не должно, все предельно понятно. Мы настроили ежедневное копирование в 21:00 начиная с 31 Марта.

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

На закладке Specify the Transaction Log Backup Plan аналогичным образом настраиваем резервное копирование лога транзакций, задаем ему расписание и место хранения, если баз много советуем разнести резервное копирование баз и логов по времени. Копирование лога транзакций не является обязательным, однако его наличие позволяет откатить базу на произвольное время с момента создания предыдущей копии, что очень удобно, нужное время довольно быстро находится последовательным делением временного промежутка пополам.

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

Теперь разворачиваем SQL Server Agent и выбрав пункт Jobs убеждаемся в наличии там двух заданий. Запускаем их вручную (ПКМ - Start Job) и проверяем правильность выполнения. Все, можем спать спокойно, резервное копирование настроено.

Для восстановления базы из резервной копии щелкаем на нужной базе правой кнопкой мыши и выбираем Все задачи - Restore Database.

В открывшемся окне указываем дату и внизу выбираем необходимый архив. Если у нас есть копия лога транзакций, то доступна опция Point in time restore с помощью которой можно выбрать момент времени, на который мы хотим восстановить базу.

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

В данной статье будет рассказано как вручную сделать полную резервную копию базы данных в с помощью программы «Среда 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).

Помогла ли Вам данная статья?