Настройка плана резервного копирования баз 1с на ms sql server
В разных ситуациях может потребоваться восстановление базы данных 1С из резервной копии. В этой статье опишим действия, которые необходимы для восстановления.
Перед тем, как начать это, требуется убедиться что выполнили следующие предварительные условия:
- иметь достаточные права на СУБД
- действительный файл резервной копии база дынных существует для базы данных
- действительные файлы журнала транзакции существуют для базы данных
Разрешения
Если восстанавливаемая база данных не существует, пользователь должен иметь разрешения create database , чтобы иметь возможность выполнить восстановление. Если база данных существует, разрешение выполнения по умолчанию назначаются членам sysadmin и dbcreator фиксированным ролям сервера и владельцу базы данных (dbo).
Разрешения восстановления предоставляются ролям, в которых информация о членстве всегда доступна на сервере. Поскольку членство в фиксированной роли базы данных можно проверить только тогда, когда база данных доступна и не повреждена (что не всегда имеется при выполнении восстановления, пользователи db_owner фиксированной роли базы данных не имеют разрешения на восстановлении.
Восстановление базы данных
Чтобы восстановить базу данных, выполните следующие действия:
- После подключения к соответствующему экземпляру СУБД MS SQL требуется щелкнуть имя сервера, чтобы развернуть дерево серверов в обозревателе объектов.
- Разверните Базы данных. В зависимости от базы данных, выберите пользовательскую базу данных или разверните Системные базы данных и выберите системную базу данных.
- Щелкните ПКМ базу данных, выберите «Задачи» >«Восстановить» >«База данных», чтобы открыть диалоговое окно «Восстановить базу данных».
- В разделе «Источник» страницы «Общие» укажите источник и расположение наборов резервных копий для восстановления, выбрав «Устройство» >«Добавить», а затем найдите файл резервной копии:
Рисунок 1 - Путь к файлу резервной копии
- В разделе «Назначение» страницы «Общие» поле «База данных» автоматически заполняется именем базы данных, введите новое имя в этом поле.
- В разделе «План восстановления» на странице «Общие» оставьте значение по умолчанию «До последней сохраненной резервной копии» или нажмите «Временная шкала», чтобы открыть диалоговое окно «Временная шкала резервного копирования», где вы можете вручную выбрать момент времени, чтобы остановить действие восстановления.
- В разделе Резервные копии для восстановления сетки выберите резервные копии для восстановления. Эта сетка отображает резервные копии, доступные для указанного местоположения. По умолчанию предлагается план восстановления.
- Чтобы просмотреть или выбрать дополнительные параметры, на панели «Параметры восстановления» на странице «Параметры» можно выбрать любой из следующих параметров, если это соответствует вашей ситуации:
Рисунок 2 - Окно об успешном завершении
С опциями (не обязательно):
- Перезаписать существующую базу данных ( with replace )
- Сохранить настройки репликации ( with keep_replication )
- Ограничить доступ к восстанавливаемой базе данных ( with restricted_user )
Выберите опцию для поля Состояние восстановления, которое определяет состояние базы данных после операции восстановления:
- restore with recovery - это поведение по умолчанию, которое оставляет базу данных готовой к использованию, откатывая незавершенные транзакции
- Дополнительные журналы транзакций не могут быть восстановлены
- Выберите эту опцию, если вы сейчас восстанавливаете все необходимые резервные копии
- Дополнительные журналы транзакций могут быть восстановлены
- База данных не может быть использована, пока она не будет восстановлена
- Он отменяет незавершенные транзакции, но сохраняет действия отмены в резервном файле, чтобы можно было восстановить эффекты восстановления
Сделайте резервную копию заключительного фрагмента журнала перед тем, как выбрать восстановление, если необходимо для выбранного вами момента времени.
Операции восстановления могут завершится неудачно, если есть активные подключения данных, поэтому желательно установить флажок Закрыть существующие соединения с базой данных назначения, чтобы убедиться, что все активные подключения между Management Studio и базой данных закрыты (этот флажок устанавливает базу данных в однопользовательский режим перед выполнением операций восстановления и устанавливает базу данных в однопользовательский режим после завершения).
Выберите Отображать запрос перед восстановлением каждой резервной копии, если вы хотите получать запросы между каждой операцией восстановления.
Нажимаем ОК, после этого выполнится восстановление базы данных и увидим информационное окно об успешном завершении.
Теперь можно приступать к настройки Плана обслуживания (Maintenance Plan). План Обслуживания можно создать сразу для всех БД, но удобнее для каждой БД создать свой план обслуживания.
В нашем Плане обслуживания будет три подплана: 1 - резервное копирование БД (Полное); 2 - резервное копирование БД (Разностное); 3 - Резервное копирование Журнала транзакций. У каждого подплана есть свое расписание выполнения. Раписание каждый настраивает по своим усмотрениям, в моём же случае полное копирование делается раз в неделю в воскресенье, Разностное копирование каждый день кроме воскресенья, ЖТ - журнал транзакций каждый час. При такой модели резервирования можно восстановить искомую БД на любую дату и час, причем экономим пространство на жёстком диске т.к. полное резервирование выполняется фактически раз в неделю, а в течении недели только изменения.
Настройка дневного расписания. Недельное отличается только установленной галочкой "Воскресенье" и снятыми с "понедельника" по "Субботу"
Расписание для ЖТ. Красным выделено время сохранения в течении дня, имеет смысл например, если пользователи работают с БД в определённый период, если режим работы 24х7, то оставляем по уполчанию.
На рисунке ниже, изображен редактор недельного подплана, он состоит из задач, которые выполняются в заданной последовательности. Последовательность задается вручную, причем зелёные стрелки означают, что следущая задача будет выполнена только при успешном выполнении предыдущей, а синяя, что задача выполнится при любом завершении предыдущей задачи. В редактор подплана обслуживания, задачи можно добавить из "Панель элементов", которая находится в левом верхнем углу, когда редактор открыт.
Задачи. В каждую задачу нужно зайти и выбрать БД, для которой она будет выполняться и ряд других настроеек (если есть). Рассмотрим, какие задачи содержит недельный подплан нашего плана обслуживания.
1. "Проверка целостности БД" (Check Database Integrity Task). Следующая задача будет выполняться, только если БД не содержит ошибок. (Замем резервировать БД с ошибками?)
2. "Восстановить индекс" (Rebuild Index Task). Восстановить (Перестроить) индекс необходимо каждый день, т.к. при работе с индексами они сильно фрагментируются и при фрагментации более 25% SQL начинает заметно "тормозить". Эта операция довольно ресурсоёмка, поэтому её можно делать хотябы раз в неделю, а в дневном подплане заменить её менее ресурсоёмкую задачу "Реорганизация индекса".
3. "Обновить статистику" (Update Statistics Task). Для оптимизации. Кстати эту задачу можно выполнять несколько раз в течении дня, если ваша БД сильно нагружена.
4. После обновления статистики ОБЯЗАТЕЛЬНО нужно очистить процедурный кэш. Для этого перетаскиваем в редактор задачу "Выполнение инструкции T-SQL" и в поле "инструкция T-SQL:" написать процедуру DBCC FREEPROCCACHE. Но нужно учесть, что эта процедура очищает кэш у ВСЕХ БД, а мы обновили статистику по одной! Как очистить процедурный кэш для определённой БД, читаем
5. "Резервное копирование БД" (Back Up Database Task). В этой задаче указываем какую БД мы резервируем, тип резервной копии (Для недельного подплана - Полное, для дневного - Разностное, для часового - Журнал транзакций.) Ставим переключатель в положение "Создать резервную копию баз данных в одном или нескольких файлах" и добавляем ранее созданное устройство резервного копирования. В таком случае ВСЕ копии сохраняются в один файл, который указали при создании устройства резервного копирования, если переключатель оставить в "Создать файл резервной копии для каждой базы данных", то на каждое резервное копирование будет создаваться отдельный файл и на Полное и на Разностное и на ЖТ, что очень неудобно при восстановлении, зато удобно при хранении. Не забываем укзать что нужно сжимать резервные копии!
6. "Очистка Журнала" Очищает записи, создаваемые при выполнении задач. Также можно включить задачу "Очистка после обслуживания" и настроить её для удаления текстовых логов или устаревших резервных копий.
Подплан для резервирования ЖТ, состоит из одной задачи "Резервное копирование базы данных". ЖТ для меня удобнее сохранять не в Устройство резервного копирования, а в отдельный файл, что необходимо указать в настройке задачи.
Настройка резервного копирования (резервирования) баз данных на "бюджетной" версии 1С Предприятие под MS SQL Server. Используется пример MS SQL Server 2008 R2 под Windows. Для малых и средних предприятий, исключая производственные и торговые, так как тестирование на них не проводилось.
Настройка резервного копирования (резервирования) баз данных 1С Предприятие на MS SQL Server .
В данной статье используется MS SQL Server 2008 R 2 под Windows.
Хочу сразу сказать, что статья посвящена настройке самого бюджетного варианта размещения 1С для среднестатистической фирмы с не более чем 10-ю рабочими местами, использующей только Бухгалерию Предприятия и ЗУП. Подойдет ли это для торгового предприятия – не проверял.
Можно разместить 1С сервер на PostgreSQL и Linux . Это будет дешевле за счет меньшей стоимости лицензий 1С и «бесплатности» SQL -ной части. Но так ли это на самом деле? Для обслуживания серверной части необходим специалист в штате или постановка на обслуживание в одной из фирм-франчайзи 1С. Совсем не бюджетный вариант.
Обычно в каждой малой или средней фирме всегда есть хотя бы один системный администратор, он же «железячник», хорошо разбирающейся в «окнах». Всегда есть Windows сервер и можно выделить место или машину для 1С. Почему бы не использовать MS SQL Server? Он очень хорошо дружит с Windows. Кто бы спорил. Дорого. Так ли это?
В линейке SQL Server у Microsoft существует выпуск под названием « Express ». Это и есть наш бюджетный вариант. Microsoft о нем говорит следующее: « Бесплатная база данных начального уровня, которая идеально подходит для обучения и создания приложений для обработки данных на настольных компьютерах и небольших серверах (размером до 10 ГБ) ». На 4 ядра процессора, буфер 1410 Мб, объем памяти на базу 352 Мб, максимальный размер базы 10 Гб. А для нашей фирмы надо больше? Нет.
Естественно, бесплатный сыр – только в мышеловке. Поэтому придется устраивать «пляски с бубном у костра», но один раз. Поплясали - и пускай работает.
1.Особенности резервирования MS SQL Server Express.
Начальный уровень SQL сервера в плане администрирования нашей задачи означает, что в нем используется простая модель восстановления данных. Т.е. нельзя сделать резервную копию журналов транзакций базы данных, нельзя реализовать доставку журналов, забудем о зеркалировании баз данных и хитрых восстановлений на определенный момент времени. Нет SQL Server Agent, и кроме нас самих нам никто не поможет.
Если надо восстановить базу данных, то только полностью из резервной копии на момент ее создания. Но у нас есть маленькая лазейка: разностная резервная копия.
2.Стратегия резервирования.
Для нашего случая (малая или средняя не торговая фирма) стратегия будет такая:
- полная резервная копия 1 раз в день. Этого достаточно. Лучше делать во внерабочее время – ночью или утром.
- несколько разностных копий в рабочее время с периодичностью 1 – 3 часа. Разностные копии сохраняют только изменения внесенные в 1С после создания полной резервной копии. Поэтому они существенно меньше и их создание занимает меньше времени. Если нужно откатиться на несколько времени – делаем восстановление из полного и накатываем разностный по ближайшему времени до возникновения ошибки. От этого времени до момента ошибки – руками в 1С. А что делать? Бюджетная модель. На практике восстанавливать приходится очень редко и периодичность разностных копий в 3 часа вполне достаточна.
- сохранение всех резервных копий не только на основной носитель, но и на резервный файловый сервер. Обычно на сервере, где крутится 1С, не так много свободного места. Поэтому время удержания (количество хранящихся резервных копий по дням) может быть невелико. Увеличить время удержания и обезопасить себя от сбоев основного сервера можно выделив место на стороннем файловом сервере и передавать туда копии бэкапов после их создания на основном сервере.
Будем использовать штатные возможности SQL Server и Windows. Подойдем к решению задачи комплексно. Максимум начальной работы и минимум на поддержание, проверки и прописывание новых без данных.
3. Как это сделать. Часть на SQL Server.
Для этого создаем в системной базе данных Master определяющую процесс табличку adm_reserved_db_names. Вот скрипт ее создания:
CREATE TABLE [dbo].[adm_reserved_db_names](
[id] [int] IDENTITY(1,1) NOT NULL,
[name_rsrv_db] [varchar](50) NOT NULL,
[flag_rsrv] [int] NOT NULL,
[flag_diff] [int] NOT NULL
Id – номер по порядку, далее имя базы данных (совпадает с Database Name), флаг создания полной резервной копии и флаг создания разностной резервной копии. Флаги – целые числа. Удобно ставить и менять. 0 – делать, 1 – не делать. Понятно, что если не делаем полную копию, то разностная пойдет от последней сделанной полной или выдаст ошибку.
В результате заполненная рабочая таблица adm _ reserved _ db _ names будет выгляеть так:
Некая T-SQL процедура должна периодически просматривать эту табличку и действовать в соответствии указаниями в ней. Процедура, вернее, две процедуры для полной резервной копии и разностной резервной копии, опять же в базе данных Master, выглядят так.
Полное резервирование adm _ BackUp _ Bases :
CREATE PROCEDURE [dbo] . [adm_BackUp_Bases]
declare @pathbkp varchar ( 100 )
declare @extbcp varchar ( 5 )
declare @dltfromdate varchar ( 19 )
declare @file varchar ( 200 )
declare @filename varchar ( 50 ), @logfile varchar ( 50 )
declare @dt varchar ( 15 )
declare @rdnc int
declare CurDBName cursor for
select name_rsrv_db from master . dbo . adm_reserved_db_names
where flag_rsrv = 0 order by 1 ;
set @pathbkp = 'C:\SQL_Data\BackUp\'
set @extbcp = 'bak'
select @dltfromdate = convert ( varchar ( 19 ), dateadd ( DAY ,- @rdnc , getdate ()), 126 ); --'2011-11-23T11:14:48'
select @dt = cast ( datepart ( yyyy , getdate ()) as varchar ( 4 ))
when len ( cast ( datepart ( mm , getdate ()) as varchar ( 2 )))= 1
then '0' + cast ( datepart ( mm , getdate ()) as varchar ( 2 ))
else cast ( datepart ( mm , getdate ()) as varchar ( 2 ))
when len ( cast ( datepart ( dd , getdate ()) as varchar ( 2 )))= 1
then '0' + cast ( datepart ( dd , getdate ()) as varchar ( 2 ))
else cast ( datepart ( dd , getdate ()) as varchar ( 2 ))
when len ( cast ( datepart ( hh , getdate ()) as varchar ( 2 )))= 1
then '0' + cast ( datepart ( hh , getdate ()) as varchar ( 2 ))
else cast ( datepart ( hh , getdate ()) as varchar ( 2 ))
when len ( cast ( datepart ( mi , getdate ()) as varchar ( 2 )))= 1
then '0' + cast ( datepart ( mi , getdate ()) as varchar ( 2 ))
else cast ( datepart ( mi , getdate ()) as varchar ( 2 ))
fetch next from CurDBName into @filename ;
while @@FETCH_STATUS = 0
select @file = @pathbkp + @filename + '_backup_' + @dt + '.' + @extbcp ;
BACKUP DATABASE @filename TO DISK = @file WITH NOFORMAT , NOINIT ;
EXECUTE master . dbo . xp_delete_file 0 , @pathbkp , @extbcp , @dltfromdate
fetch next from CurDBName into @filename ;
Определяем курсор CurDBName для перебора таблицы, переменной @ pathbkp определяем путь хранения резервных копий, @ extbcp - расширение резервного файла, @ dt - дата-идентификатор файла, @ rdnc - удержание в сутках. Запускаем курсор, считываем имя базы данных, формируем имя резервного файла, делаем backup средствами T-SQL и удаляем устаревшие резервные файлы. И так – до конца таблицы. Получаем файлы с такой нотацией:
Причем количество символов в названии должно быть равно у всех баз данных. Зачем – объясню позднее.
Разностное резервирование adm_BackUp_Bases_Diff:
CREATE PROCEDURE [dbo] . [adm_BackUp_Bases_Diff]
declare @pathbkp varchar ( 100 )
declare @extbcp varchar ( 5 )
declare @dltfromdate varchar ( 19 )
declare @file varchar ( 200 )
declare @filename varchar ( 50 ), @logfile varchar ( 50 )
declare @dt varchar ( 15 )
declare @rdnc int
declare CurDBName cursor for
select name_rsrv_db from master . dbo . adm_reserved_db_names
where flag_diff = 0 order by 1 ;
set @pathbkp = 'C:\SQL_Data\BackUp\'
set @extbcp = 'bak'
fetch next from CurDBName into @filename ;
while @@FETCH_STATUS = 0
select @file = @pathbkp + 'DFF_' + @filename + '.' + @extbcp ;
BACKUP DATABASE @filename TO DISK = @file WITH DIFFERENTIAL , NOFORMAT , NOINIT ;
fetch next from CurDBName into @filename ;
Аналогично предыдущей. Поскольку копии делаются в период между двумя полными копиями, то нет необходимости в отображении даты и не нужно каждый раз удалять устаревшие данные, так как дифференциальные копии будем убирать перед новым полным бэкапом. Нотация получается подобной:
DFF _ XX _ ACC . bak
Все разностные копии SQL сервером кладутся в один файл и он, с течением времени, увеличивает свой размер.
4. Как это сделать. Часть на Windows.
В примере использован Windows Server 2008 R2 Standard.
Так как в MS SQL Server Express отсутствует SQL Agent, то никакое задание на стороне SQL сервера мы выполнить не можем. Но можно управлять им из командной строки операционной системы.
Для этого нужно создать папку для размещения управляющих файлов, лучше ближе к корню файловой системы. В нашем случае их будет две пары: для полного резервирования и для разностного резервирования.
Полное резервирование sql-инструкция BackUp_DB.sql:
Здесь дается команда выполнить процедуру на SQL сервере в системной базе данных Master.
Полное резервирование командный файл BackUp1C.cmd:
sqlcmd -S ServerName\Instance -U User -P Passvord -i C:\ BackUp_Tools\BackUp_DB.sql
del \\ ServerName \BackUp\DFF_*.bak
robocopy "\\ServerName\BackUp" "\\DisasterServerName\BackUp" *.bak /R:0 /MAXAGE:1
Sqlcmd - служебная программа, которая позволяет вводить инструкции T-SQL, системные процедуры и файлы скриптов в командной строке. Она предустанавливается с MS SQL сервером или ее можно скачать с сайта Microsoft. ServerName – имя сервера где размещена 1С, Instance – имя экземпляра MS SQL Server где крутится 1С, User и Passvord – имя и пароль пользователя с правами администратора (sa). Пароль в открытом доступе очень плохо. Но в нашем бюджетном варианте от этого никуда не денешься. Лучше всего создать в MS SQL Server специального пользователя только для создания backup-ов и хорошо защитить операционную систему от проникновения извне.
Как я говорил выше, после создания полной резервной копии файлы разностных backup-ов теряют смысл, поэтому их удаляем.
DisasterServerName – имя резервного файлового сервера, где размещается архив полных резервных копий. Копируем их после удаления всего лишнего утилитой robocopy. Для нашего случая она подходит идеально. Задаем пути откуда брать и куда класть, шаблон имен файлов и время удержания. В нашем примере MAXAGE:1 – это файлы с текущей датой. Robocopy качаем из интернета и устанавливаем.
Разностное резервирование sql-инструкция BackUp_DB_Diff.sql:
Разностное резервирование командный файл BackUp1C_Diff.cmd:
sqlcmd -S ServerName\Instance -U User -P Passvord -i C:\ BackUp_Tools\BackUp_DB_Diff.sql
robocopy "\\ServerName\BackUp" "\\DisasterServerName\BackUp" DFF_*.bak /R:0 /MAXAGE:1
Дальше надо настроить выполнение заданий в операционной системе. Используем Task Sheduler. Для разностного резервирования можно использовать такой вариант периодичности:
Через каждые 3 часа начиная с 8 утра до 8 вечера.
5. Восстановление базы данных.
Восстановление базы после ошибок по просьбе бухгалтерии производится стандартными средствамиSQL Server. В SQL Server Management Studio подключаемся к экземпляру 1С, выбираем нужную базу данных, левой кнопкой мыши открываем меню, находим раздел Задания (Tasks), выбираем, находим раздел Восстановление (Restore), выбираем и в открывшемся меню выбираем пункт База данных (Database…). Появится такое окно:
Выгоняем всех пользователей из этой базы данных. Галочкой отмечаем полную и ту разностную копию, которая предшествовала по времени моменту возникновения ошибки. Нажимаем OK и ждем. После завершения задания база готова к работе.
6. Небольшой лайфхак для администратора.
В жизни 1С администратора и программиста возникают моменты, когда надо сделать свежий файловый архив базы данных. Например развернуть тестовую базу у себя на компьютере. Это всегда сопряжено с трудностями: либо выгонять всех пользователей, либо ждать когда они же разойдутся по домам. В случае базы данных на SQL сервере это сделать несколько проще.
Создаем на 1С сервере пустую тестовую базу данных. Переходим в SQL Server Management Studio.Аналогично как в п.п. 5 откроем окно восстановления нашей тестовой базы данных.
Будем использовать архив нужной Вам базы. Для этого выбираем ее из списка в разделе From database. Переходим в раздел задания параметров Options.
Ставим галочку перезаписывания тестовой базы данных (2), проверяем выбор статуса восстановления (3). Нажатием кнопок (4 и 5) заменяем наименование файла базы-иметента данных (файл *.mdf) на наименование Вашей тестовой базы данных из списка (4) и заменяем наименование файла журнала событий базы-иметента данных (файл *.ldf) на наименование журнала событий Вашей тестовой базы данных из списка (5). Нажимаем ОК и ждем. После завершения работы открываем тестовую базу 1С в режиме конфигуратора и, никому не мешая, делаем файловую копию.
Если нужны данные «на сейчас», тогда предварительно запускаем на Windows сервере командный файл BackUp1C_Diff.cmd и получаем свежую разностную копию.
Сегодня рассмотрим один из вариантов обслуживания баз 1С в СУБД MS SQL.
Содержание:
1. Немного теории по планам обслуживания
2. Постановка задачи по созданию планов обслуживания
3. Создание плана обслуживания (Полная копия)
4. Создание плана обслуживания (Разностная копия)
5. Создание плана обслуживания (Резервная копия журналов транзакций)
6. Мониторинг планов обслуживания1. Немного теории по планам обслуживания
Может многие со мой не согласятся, но для меня главной целью использования Планов обслуживания в MS SQL является создание резервных копий. Местные ITишники либо еще не делают резервные копии, либо уже делают, после печальных последствий отсутствия резервных копий. Да, не спорю, Планы обслуживания также нужны для оптимизации БД и выгрузки журналов транзакций, в последнем случаи, если не выполнять выгрузку журналов транзакций, у вас может вырасти база данных и занять все пространство на диске, 1С встанет колом и пользователи не смогут работать с базой, а вам придется выполнять шринк (Shrink) базы, это наверно самое страшное для ITишники после поломки базы и отсутствии резервных копий. Но об шринке (Shrink) поговорим в другой раз.
MS SQL Server поддерживает три модели восстановления:
1) Simple (Простая) — хранится только необходимый для жизни остаток журнала транзакций.
2) Full (Полная) — хранится весь журнал транзакций с момента последнего резервного копирования журнала транзакций.
3) Bulk logged (С неполным протоколированием) — часть операций записываются в очень компактном формате. В остальном идентична Full.Модель восстановления базы можно посмотреть, в свойствах базы данных, на вкладке Параметры. Там же ее можно поменять. На практике я использую Full (Полная).
MS SQL поддерживает три типа формирования резервных копий:
1) Full (Полная копия)
2) Differential (Дифференциальная копия, Разностная копия)
3) Log (Резервная копия журналов транзакций)
Не путайте понятия: полная модель восстановления и полная резервная копия — разные вещи.Рассмотрим подробно три типа формирования резервных копий.
1) Полная резервная копия
Позволяет восстановить состояние базы данных на некоторый момент времени. Состоит из копии файлов данных и журнала транзакций на момент завершения формирования резервной копии.2) Разностная резервная копия
Хранит данных, изменившиеся с момента последней Полной резервной копии. При восстановлении нужно сначала восстановить Полную резервную копию в режиме NORECOVERY, потом можно применить любую из последующих Разностных копий. За счет этого можно значительно снизить объём дискового пространства для хранения резервной копии. Обратите внимание: без предыдущей Полной резервной копии Разностная копия бесполезна. Каждая последующая Разностная копия будет хранить все данные, входящие в предыдущую Разностную резервную копию, сделанную после предыдущей Полной копии. Поэтому каждая следующая Разностная копия больше предыдущих, пока снова не сделать Полную копию. Соответственно для восстановления на какой-то момент времени достаточно последней Полной резервной копии и последней Разностной копии. Промежуточные копии для восстановления не нужны.3) Резервная копия журналов транзакций
Содержит копию журналов транзакций за некоторый период. Обычно с момента прошлой Резервной копии журналов транзакций до момента формирования текущей Резервной копии журналов транзакций. За счет этого Резервные копии журналов транзакций позволяют (с учетом Полной и Разностной копий) восстановить базу данных на любой момент времени. Резервная копия журналов транзакций высвобождает место в файле журнала транзакций, что позволяет ITишники избавиться от шринка базы данных.Обратите внимание: набор Резервных копий журналов транзакций по сути бесполезен, если он не является непрерывной цепочкой, причем момент начала последнего успешного Полного или Разностного резервного копирования должен быть внутри периода этой цепочки.
2. Постановка задачи по созданию планов обслуживанияВ организации N работают по шестидневке с 8:00 до 17:00. Обед с 12:00 до 13:00.
Имеется в MS SQL база данных с именем Moodle.
Что нужно сделать:
1) Проверить модель восстановления базы данных, должна быть Полная.
2) Создать план обслуживания, который будет создавать Полную резервную копию базы данных каждое воскресение в 17:00. Очищать хранилище от устаревших резервных копий старше 15 дней.
3) Создать план обслуживания, который будет создавать Разностную копию базы данных каждый день в 21:00 кроме воскресения.
4) Создать план обслуживания, который будет создавать Резервную копию журналов транзакций два раза в день, в 12:00 и в 17:00, кроме воскресения.
3. Создание плана обслуживания (Полная копия)Запускаем SQL Server Management Studio, в Обозревателе объектов проходим по ветке Управление - Планы обслуживания.
Правой кнопкой по пункту Планы обслуживания и в контекстном меню выбираем Создать план обслуживания. Указываем имя, к примеру: Moodle. В открывшемся конструкторе будем создавать вложенные планы обслуживания. щелкните два раза по строке ВложенныйПлан _1
Задайте Имя, Описание и обязательно настройте Расписание выполнения вложенного плана обслуживания: еженедельно в воскресение 17:00:00
Используя Панель элементов создадим первый вложенный план. Достаточно нужный элемент в панели ухватить, перенести на рабочую область и там бросить. Для открытия мастера настройки элемента достаточно два раза щелкнуть по элементу.
Ниже на рисунке представлен результат настройки, который должен у нас получится, но все по порядку.
Размещаем задачу "Проверка целостности базы данных", двойным щелчком мыши открываем диалог настройки задачи, в первую очередь в свойстве Базы данных отмечаем нужную базу, а остальное настраиваем как показано на рисунке. При желании можно посмотреть T-SQL код полученной задачи.Размещаем следующую задачу "Перестроение индекса" она у нас будет выполнятся только после успешно выполненной предыдущей задачи. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.
Для связи двух задач щелкните по первой задаче "Проверка целостности базы данных" у этой задачи появится стрелка, щелкните по ней и не отпуская соедините со второй задачей "Перестроение индекса". Для изменения значения условия выполнение следующей задачи, щелкните два раза по линии и в открывшемся диалоговом окне выполните необходимые настройки.
Размещаем задачу "Обновление статистики" которая будет выполнятся после завершения предыдущей. Настраиваем эту задачу как на рисунке, не забываем выбрать базу данных.
DECLARE @intDBID INTEGER SET @intDBID = (SELECT dbid FROM master.dbo.sysdatabases WHERE name = 'Moodle')
Инструкция DBCC FREEPROCCACHE используется для аккуратной очистки кэша планов. Освобождение кэша планов приводит, например, к тому, что хранимая процедура повторно компилируется, а не используется из кэша.
Размещаем следующую задачу "Резервное копирование базы данных" она у нас будет выполнятся полную резервную копию базы данных. Размещать резервные копии желательно на СХД, если нет, то на другом физическом диске, но ни в коем случае на том же диске где сама база данных, иначе теряется весь смысл резервных копий. Настраиваем как показано на рисунке, не забываем указать конкретную базу данных.
Размещаем следующую задачу "Очистка журнала" она у нас будет выполнятся очистку журналов. Настраиваем как показано на рисунке.
Размещаем следующую задачу "Очистка после обслуживания" она у нас будет выполнятся удаление старых файлов резервных копий, так как свойстве Расширение файла указана маска *.*, то удаляются будут все файлы, и полной резервной копии, и разностной, и журнала транзакций. Настраиваем как показано на рисунке.
Обратите внимание, две последние задачи выполняются после выполнения задачи "Резервное копирование базы данных" и самое главное, задачу "Очистка после обслуживания" нужно выполнять только после успешно выполненной задачи "Резервное копирование базы данных". Что бы не получилось, что у вас уже который раз не создаются резервные копии, а вы задачей "Очистка после обслуживания" удаляете последние актуальные копии.
Добавим вложенный план обслуживания, на рисунке ниже красной рамкой выделена данная кнопка и показан результат схемы обслуживания, который должен получится, но все по порядку.
Размещаем две задачи "Проверка целостности базы данных" и "Резервное копирование базы данных", обратите внимание последняя задача выполняется только после успешного завершения предыдущей. Иначе какой смысл делать резервную копию если она не корректна.
На рисунках представлены настройки задачи "Резервное копирование базы данных". Обратите внимание на Тип резервной копии, должен стаять Разностное. И не забудьте указать конкретную базу данных.
На рисунке представлен результат плана обслуживания на 12:00, на 17:00 отличатся ничем не будет, только временем выполнения.
Разместим одну задачу "Резервное копирование базы данных". Обратите внимание на Тип резервной копии, должен стаять Журнал тарнзакций. И не забудьте указать конкретную базу данных.
Откройте Мониторинг активности заданий, в этом мониторинге можно увидеть какие задачи, когда выполнялись, когда следующее выполнение и успешно ли они выполнялись.
Для запуска определенного плана, достаточно в контекстном меню выбрать пункт Запустить задание на шаге.
Сегодня рассмотрели минимальные азы создания планов обслуживания в MS SQL по созданию трех типов резервных копий баз данных: Full (Полная копия), Differential (Дифференциальная копия, Разностная копия) и Log (Резервная копия журналов транзакций).
В предыдущей главе мы разработали график резервного копирования. Эта глава посвящена практической реализации наших планов.
Автоматический запуск SQL Server Agent
Для автоматического создания резервных копий нам потребуется SQL Server Agent. Обычно он стартует вместе с SQL Server при запуске операционной системы. Проверьте, в каком состоянии он находится у Вас. Для этого запустите программу Service Manager
и в поле "Services" выберите "SQL Server Agent"
Если SQL Server Agent не запущен, запустите его. Обязательно установите галочку "Auto-start service when OS starts". Это избавит Вас от необходимости запускать агента после каждой перезагрузки компьютера.
Выбор модели восстановления данных
Откройте в Enterprise Manager свойства вашей базы данных, перейдите на закладку "Options":
SQL Server предлагает 3 модели восстановления данных:
- Simple. База данных может быть восстановлена на момент последней архивной копии, однако, Вы не сможете восстановить базу данных на момент сбоя;
- Full. База данных может быть восстановлена на момент сбоя независимо от вида операций, которые выполнялись с базой данных в момент сбоя;
- Bulk-Logged. База данных может быть восстановлена на момент сбоя в случае, если с базой данных не выполнялись массовые операции (bulk copy operations):
- SELECT INTO;
- CREATE INDEX;
- Операции с полями типа text и image;
- Операции массовой загрузки (Bulk load operations (bcp and BULK INSERT))
Более подробную информацию о моделях восстановления данных Вы можете найти в Books Online (BOL) по строке поиска "Selecting a Recovery Model" или "Simplify backup and recovery procedures".
Настройка резервного копирования базы данных
Вот мы и добрались до самого интересного…
Сейчас мы настроим автоматическое создание полных резервных копий Вашей базы данных.
Запустите Enterprise Manager, откройте папку "Management", поставьте курсор на "Database Maintenance Plans" и из контекстного меню выберите пункт "New Maintenance Plan…":
Нажмите на кнопку "Далее" в окне приветствия и перейдите к окну выбора баз данных для архивирования:
Пометьте галочкой Вашу базу данных и нажмите кнопку "Далее". Пропустите окна "Update Data Optimization Information" и "Database Integrity Check". Перед Вами появится окно "Specify the Database Backup Plan":
Back up the database as part of the maintenance plan - база данных целиком будет заархивирована при выполнении плана обслуживания.
Verify the integrity of the backup when complete - проверить, что полученный архив читается командой RESTORE VERIFYONLY.
Согласно разработанному плану полная копия базы данных должна делаться во все дни недели за исключением воскресенья в 01:00. После настройки параметров нажмите "ОК". Перейдите к следующему окну "Specify Backup Disk Directory":
Здесь Вы можете указать, в какой каталог следует помещать сделанные архивные копии и какое расширение будет у файлов архивных копий.
Если Вы будете архивировать несколько баз данных, имеет смысл поставить галочку "Create a subdirectory for each database". В этом случае для каждой архивируемой базы данных будет создан свой подкаталог, в которой и будут помещаться архивные копии.
На всякий случай можно установить галочку "Remove files older than", чтобы удалять файлы, старше установленных параметров.
Перейдите к следующему окну "Specify the Transaction Log Backup Plan":
Поскольку мы не планируем выполнять резервное копирование файла транзакций вместе с полным копированием базы данных, сбросьте галочку "Back up the transaction log as part of the maintenance plan".
В следующих двух окнах оставьте значения по умолчанию. В последнем окне укажите название плана обслуживания:
На этом создание плана обслуживания завершено. Перейдите в раздел Jobs, и в правой панели Enterprise Manager Вы увидите новое задание:
Оно создано на основе плана обслуживания "Base1C Full Backup". Давайте запустим его и убедимся, что полная копия базы данных делается без ошибок. Щелкните правой кнопкой мыши на названии задания и выберите в контекстном меню пункт "Start Job":
После завершения работы у меня создался файл с именем "Base1C_db_200711290147.bak"
Base1C - это имя архивируемой базы данных;
db - признак того, что это копия базы данных (не файла транзакций);
20071129 - дата создания архивной копии;
0147 - время создания архивной копии.На этом настройка автоматического создания полных копий базы данных завершена.
Настройка резервного копирования файла транзакций
Переходим ко второй части графика резервного копирования - автоматическому созданию архивов файла транзакций.
Для архивирования файла транзакций мы создадим отдельный план обслуживания. Его настройка почти такая же, как для полной копии базы данных. Отличие лишь в том, что в окне "Specify the Database Backup Plan" надо снять галочку "Back up the database as part of the maintenance plan":
а в окне "Specify the Transaction Log Backup Plan", наоборот, поставить галочку "Back up the transaction log as part of the maintenance plan"
и настроить график выполнения задания
В окне "Specify Transaction Log Backup Disk Directory" делаем настройки, аналогичные плану обслуживания для создания полной копии базы данных:
Расширение архивного файла оставляем по умолчанию - TRN. План обслуживания назовем "Base1C Log BackUp":
Создание плана обслуживания для резервного копирования файла транзакций завершено. Осталось только проверить его работоспособность:
После завершения работы у меня создался файл с именем "Base1C_tlog_200711290227.bak"
Base1C - это имя архивируемой базы данных;
tlog - признак того, что это копия файла транзакций;
20071129 - дата создания архивной копии;
0227 - время создания архивной копии.Что еще нужно знать про резервное копирование в SQL сервере
Мы закончили настройку SQL сервера для автоматического архивирования данных программы 1С. Но это еще не все, что Вам нужно знать. Прошу Вас запастись терпением еще на 5 минут. Приведенная ниже информация будет Вам полезна:
-
В разделе "Backing Up and Restoring System Databases" в BOL говорится:
- master
- msdb
- model (если она модифицирована)
- distribution (если сервер сконфигурирован как replication Distributor)"
"Когда SQL сервер завершает архивирование файла транзакций, он автоматически удаляет из него неактивную часть. Неактивная часть содержит информацию о полностью завершенных транзакциях, которые больше не используются в процессе восстановления. SQL сервер использует пространство, которое раньше занимала неактивная часть, для записи информации о новых транзакциях вместо того, чтобы увеличивать размер файла транзакций."
BACKUP LOG ИмяБазы WITH TRUNCATE_ONLY
- написать BAT-файлы, которые выполняют упаковку файлов и их перенос с сервера SQL на дополнительный компьютер;
- создать задания в планировщиках заданий SQL сервера и доп. компьютера.
В следующей главе мы рассмотрим процесс восстановления базы данных SQL из архивных копий.
Примечание: в статье отражено мое мнение по резервному копированию баз 1С. Оно может не совпадать с Вашим мнением и / или мнением других специалистов.
Читайте также: