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

А также: бэкап 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) и начните с начала.

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 с помощью которой можно выбрать момент времени, на который мы хотим восстановить базу.

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

Давайте рассмотрим нежелательную ситуацию. А именно: по какой-то причине вышла из строя БД. Что есть у нас? Полная копия, диференциальная копия на вчера, но на сегодня тоже есть данные, неужели нужно было делать диф.копирование каждый час? - Нет! Есть Журнал транзакций .
Журнал транзакций - журнал, в который записываются все транзакции и все изменения базы данных, выполняемые каждой транзакцией. Т.е. любое действие с БД пошагово запысается в журнал. Каждая запись отмечается СУБД на предмет завершённости транзакции, выполнена или нет. С его помощью, можно восстановить состояние БД не только после сбоя, а и при непредвиденных действиях с данными. Откатить до определённого времени. Как и с БД, с журналом транзакций нужно проводить резервное копирование, полное, дифференциальное, инкрементное. Для восстановления части журнала транзакций после сбоя в промежутке между созданием резервных копий, нужно выполнить резервирование заключительного фрагмента журнала, который, по-сути, является точкой финализации резервного копирования. Выполняется после сбоя, как точка обратного отсчёта.
Итак, для восстановления БД после сбоя нам нужны - актуальная полная копия БД, дифференциальная копия БД и копия журнала транзакций.

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

1. Простая модель (Simple) - используется только полное резервирование. Нет диф. резервирования, как и резервирования журнала транзакций. Полные копии нужно создавать как можно чаще. Актуально для БД, используемых "только для чтения".
2. Модель полного восстановления (Full) - наиболее применяемая модель, при которой доступны все функции резервного копирования данных и их восстановление. Поддерживает восстановление отдельных страниц данных. Происходит полное протоколирование транзакций сохраниние журнала транзакций.
3. Модель с неполным протоколированием (Bulk-Logged) - предназначена, как дополнение к полной модели полного восстановления. Не поддерживает протоколирование большинство массовых операций, соответственно - не поддерживает восстановление БД до определённого момента времени.

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

• С помощью встроенного планировщика задач MS SQL
• С помощью языка Transact-SQL
• С помощью sqlcmd и Планировщика задач ОС
• Вручную (что нас не устраивает, ибо тру админ должен постоянно бездельничать)

Рассмотрим первый вариант, как наиболее юзабельный. Для этого используется Windows Server 2008 R2 Enterprise и MS SQL Server 2008 Eng.

Итак, допустим, что у нас есть БД TECH:

Переходим к инструменту создания Джобы:

Трём правую клавишу мышака и вызываем Мастера Джобу:
Выбираем галочку "Отдельное выполнение каждого задания", мы ведь выполняем только одно действие

Мастер без тюрбана, но ведь не в размере тюрбане главное)) Выбираем тип желания, в нашем случае - полное резервирование:

Мастер Джоба, как оказалось, чуточку немного еврей, поэтому переспрашивает ещё раз:

"Параметры дополнительные выбрать стоит, о юнный паддаван!":
здесь выбираем БД, срок хранения резервной копии, адрес (лента или диск), путь сохранения и главное - планировщик заданий!

"Не стоит о базе данных забывать при выборе своём. Сконцентрируй силу и выбери БД":

"Слишком быстро ты спешишь задание создать, нажать на кнопку стоит, что внизу с названием Shedule - Define".
Собсно, планировщик заданий, где выбираем тип (повторение, единожды и т.д.), день, время, тип старта:

Вот и всё, создали. Мастер Джоба крут и зелен. Смотрим в Maintance Plans состояние:

Для параноиков, не бойтесь в этом признаться зеркалу, стоит заглянуть в душу SQL Server Agent - Job Activity Monitor, Мастер Джоба подробно покажет всё:

Теперь, при удовлетворении заданных условий, должен создаться полный бэкап БД. По такому же принципу, создаётся диф.резервирование и резервирование журнала транзакций (эти подпункты разположены ниже "Полное резервирование" в списке выбора заданий).
Крутите уши MSSQL-ю, как Вам удобно, не отвертите

В следующей статье - создание с помощью Transact-SQL и пара примеров.

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

Структура клиент-серверного режима: преимущества и недостатки

Этот режим появился в восьмой версии платформы 1С и представляет собой систему из трех компонентов:

1. Клиентская часть. Через неё происходит обращение пользователя к информации, её получение и ввод;
2. Кластер серверов. Главное новшество и основной компонент системы. Именно он обеспечивает связь между пользователем и базой данных. На него же ложиться основная нагрузка по обработке данных;
3. Сервер для хранения базы данных. Здесь хранятся таблицы и индексы с введенной информацией.

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

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

Какие СУБД подходят для 1С

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

• Продукция фирмы IBM (IBM DB2);
• Сервер от фирмы Microsoft (Microsoft SQL Server);
• СУБД от Oracle (Oracle Database);
• Бесплатный продукт PostgreSQL.

Три первых СУБД имеют бесплатные версии, но со значительными ограничениям в использовании.

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

Microsoft SQL Server

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

1. Непосредственно таблицы с данными;
2. Лог-файл, содержащий транзакции, происходившие в базе.

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

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

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

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

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

Агент, который отсутствует, в бесплатной версии Microsoft SQL Server, и скриншоты откуда здесь выложены так же помогает настроить расписание резервного копирования.

PostgreSQL

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

Через оболочку можно выполнить выгрузку двух видов:

1. В виде SQL выражений;
2. В виде полного бэкапа базы.

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

1. Щелкаете переключатель в положение PLAIN;
2. Если надо, чтобы данные были в виде INSERT выражений, ставите соответствующую галочку «Команды Insert»;
3. Выбираете, что конкретно нужно сохранить. Если все галочки слева не стоят, то сохраниться все;
4. Нажимаете Ок и ждете.

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

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

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 .

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