После изучения множества информации с разных источников, решил описать процесс настройки резервного копирования БД MS SQL Server для полной модели восстановления, какую модель использовать решать Вам, но от себя добавлю, что если в вашей БД большой поток информации (например создаются десятки, сотни или тысячи документов в 1 час), то потеря информации за день работы будет просто неприемлемой, в таком случае только полная модель обеспечит сохранность ваших данных. Данна статья предназначена для начинающих системных администраторов и содержит по моему мнению минимальный набор действий для резервного копирования БД 1С. УстановкаНастройка самого SQL сервера и развертывание БД на нём в не рамках данной статьи.
Все настройки будем производить с помощью SQL Management Studio. Для начала нужно создать Устройство резервного копирования, можно и не создавать, но на мой взгляд это гораздо удобнее и правельнее. в оснастке SQL Management Studio -> Объекты сервера-> Устройства резервного копирования. Нужно указать имя устройства и файл в котором будут храниться резервные копии (лучше с расширением BAK), в дальнейшем можно посмотреть содержимое носителя, там будут перечислены все резервные копии.
Теперь можно приступать к настройки Плана обслуживания (Maintenance Plan). План Обслуживания можно создать сразу для всех БД, но удобнее для каждой БД создать свой план обслуживания.
В нашем Плане обслуживания будет три подплана: 1 — резервное копирование БД (Полное); 2 — резервное копирование БД (Разностное); 3 — Резервное копирование Журнала транзакций. У каждого подплана есть свое расписание выполнения. Раписание каждый настраивает по своим усмотрениям, в моём же случае полное копирование делается раз в неделю в воскресенье, Разностное копирование каждый день кроме воскресенья, ЖТ — журнал транзакций каждый час. При такой модели резервирования можно восстановить искомую БД на любую дату и час, причем экономим пространство на жёстком диске т.к. полное резервирование выполняется фактически раз в неделю, а в течении недели только изменения.
Настройка дневного расписания. Недельное отличается только установленной галочкой «Воскресенье» и снятыми с «понедельника» по «Субботу»
Расписание для ЖТ. Красным выделено время сохранения в течении дня, имеет смысл например, если пользователи работают с БД в определённый период, если режим работы 24х7, то оставляем по уполчанию.
На рисунке ниже, изображен редактор недельного подплана, он состоит из задач, которые выполняются в заданной последовательности. Последовательность задается вручную, причем зелёные стрелки означают, что следущая задача будет выполнена только при успешном выполнении предыдущей, а синяя, что задача выполнится при любом завершении предыдущей задачи. В редактор подплана обслуживания, задачи можно добавить из «Панель элементов», которая находится в левом верхнем углу, когда редактор открыт.
Задачи. В каждую задачу нужно зайти и выбрать БД, для которой она будет выполняться и ряд других настроеек (если есть). Рассмотрим, какие задачи содержит недельный подплан нашего плана обслуживания.
1. «Проверка целостности БД» (Check Database Integrity Task). Следующая задача будет выполняться, только если БД не содержит ошибок. (Замем резервировать БД с ошибками?)
2. «Восстановить индекс» (Rebuild Index Task). Восстановить (Перестроить) индекс необходимо каждый день, т.к. при работе с индексами они сильно фрагментируются и при фрагментации более 25% SQL начинает заметно «тормозить». Эта операция довольно ресурсоёмка, поэтому её можно делать хотябы раз в неделю, а в дневном подплане заменить её менее ресурсоёмкую задачу «Реорганизация индекса».
3. «Обновить статистику» (Update Statistics Task). Для оптимизации… Кстати эту задачу можно выполнять несколько раз в течении дня, если ваша БД сильно нагружена.
4. После обновления статистики ОБЯЗАТЕЛЬНО нужно очистить процедурный кэш. Для этого перетаскиваем в редактор задачу «Выполнение инструкции T-SQL» и в поле «инструкция T-SQL:» написать процедуру DBCC FREEPROCCACHE. Но нужно учесть, что эта процедура очищает кэш у ВСЕХ БД, а мы обновили статистику по одной! Как очистить процедурный кэш для определённой БД, читаем здесь. Вкратце: DBCC FLUSHPROCINDB(ID_БД)
5. «Резервное копирование БД» (Back Up Database Task). В этой задаче указываем какую БД мы резервируем, тип резервной копии (Для недельного подплана — Полное, для дневного — Разностное, для часового — Журнал транзакций.) Ставим переключатель в положение «Создать резервную копию баз данных в одном или нескольких файлах» и добавляем ранее созданное устройство резервного копирования. В таком случае ВСЕ копии сохраняются в один файл, который указали при создании устройства резервного копирования, если переключатель оставить в «Создать файл резервной копии для каждой базы данных», то на каждое резервное копирование будет создаваться отдельный файл и на Полное и на Разностное и на ЖТ, что очень неудобно при восстановлении, зато удобно при хранении. Не забываем укзать что нужно сжимать резервные копии!
6. «Очистка Журнала» Очищает записи, создаваемые при выполнении задач. Также можно включить задачу «Очистка после обслуживания» и настроить её для удаления текстовых логов или устаревших резервных копий.
Подплан для резервирования ЖТ, состоит из одной задачи «Резервное копирование базы данных».ЖТ для меня удобнее сохранять не в Устройство резервного копирования, а в отдельный файл, что необходимо указать в настройке задачи.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Спасибо за статью. В приципе у нас есть админ, который делает бэкапы, но эти знания не лишние
спасибо, пишите еще)
Спасибо за статью!
Вопрос: а возможно ли как-то настроить планы обслуживания в MS SQL Server Express ?
(3)kvert, Не разу не работал с MS SQL Server Express, но в описании вроде есть графическая среда Management Studio Express, вот в ней и надо посмотреть. Ну и всегда можно написать запрос или скрипт на backup и запускать его по расписанию стандартными средствами ОС.
Спасибо большое за предоставленную статью, главное, что всё наглядно представлено
Хорошая статья для новичков!
Отлично! Я себе тоже настроил.
а можно запускать этот план обслуживания при работе пользователей, когда они проводят много документов? и когда меняется конфигурация?
(8) Astrakhan_man, конкретно этот — нельзя, он содержит задачу ребилда индексов. В остальном можно (т.е. резервная копия будет транзакционно целостна), но любые операции отнимают какие-то ресурсы.
(8) Astrakhan_man, Дневной и Trn можно, недельный — нет. При Настройке расписания нужно это учесть. В Sql этот план отобразиться в «Agent -> Задания» по вложенным планам: WEEKLY, Dayly от туда же их можно запускать вручную.
А зачем обновлять статистику, если делается Rebuild index?
При таком плане растет журнал транзакций. Надо бы и его шинковать?
Какие нюансы есть при настройке резервного копирования распределенной базы данных?
А зачем грохать процедурный кэш, если апдейт статистики всё равно инвалидит все скомпилированные планы запросов и процедуры и они будут перекомпилированы при первом обращении к ним?
(12) Famza, во-первых, шринкование журнала транзакций при полной модели восстановления и архивирования лишено абсолютно всякого смысла, если ты себе не враг. Читай внимательно теорию. Шринк — это операция удаления из журнала зафиксированных транзакций, что нарушит последовательность ведения непрерывной цепочки транзакций в бекапах, соответственно про восстановиться ты сможешь только на момент создания последнего исправного полного либо разностного архива.
Во-вторых, любителям шринкования нужно вспомнить — что происходит, когда используемое место в журнале транзакций достигает 75%.
а как менять уже созданное задание? все перековырял, не пойму как добавить еще пару баз для архивирования, максимум можно расписание поменять и все.
а все нашел, управление-планы обслуживания-резервное копирование, находим нужную задачу, щелкаем на картинку, в контекстном меню изменить.
«но на мой взгляд это гораздо удобнее и правельнее.» на мой взгляд это вообще не удобно и неправильно. Вообще ничё не видно, по сути неуправляемая система бэкапирования. Например я вручную подчищаю, проверяю вообще наличие копий и т.д. Всё делаю визуально. Более того, я подозреваю что в описанной схеме файлы разностных копий могут уже через два три дня быть больше полного бэкапа.Если хранить в одном файле то я не знаю это можно ли отследить. Неделя это очень много. Я делаю каждый день полный, через два часа разностный и через каждые пять минут логи. Потеря данных может быть максимум за 5 минут работы, в статье за час.(скрин своего плана прикрепил). Час это много.
«что очень неудобно при восстановлении, зато удобно при хранении.» И в чём же здесь неудобство. Вот лежать себе файлики и лежат, никому не мешают.
«(Замем резервировать БД с ошибками?)» Эээээ…. Представляю себе следующую картину. В результате ошибки на пункте Проверка целостности копия не была сделана. В конце дня падает база. В своё оправдание вы говорите начальству, что базу нельзя восстановить т.к. нет смысла делать копию после пункта Проверка целостности в случае ошибки. Может всётаки будем делать всегда, невзирая ни на что?
(15) GreenDragon,
«Шринк — это операция удаления из журнала зафиксированных транзакций, что нарушит последовательность ведения непрерывной цепочки транзакций в бекапах, соответственно про восстановиться ты сможешь только на момент создания последнего исправного полного либо разностного архива.» Эээээ… а вы на полной модели восстановления пробовали это сделать? Принцип целостности данных для скуля святое. Не шринканете пока не забэкапите. Как вы говорите? «Читай внимательно теорию.»
(18) leonidkorolev, На вкус и цвет, как говорится… Никто вам не запрещает делать trn каждые 5, 10, минут, да хоть каждую минуту, конкретно у нас 1 час не критично, у кого либо может и 5 секунд критично будет, статья не об этом, а служит примером настройки. Про хранение аналогично, вот именно мне, мешает КУЧА файлов, но опять же на вкус и цвет… Разностные копии могут быть за несколько дней больше одной полной, но не больше, чем на каждый день делать полные! Про «»(Замем резервировать БД с ошибками?)» Эээээ….», возможно здесь вы правы, резервировать нужно.
(20) «Разностные копии могут быть за несколько дней больше одной полной, но не больше, чем на каждый день делать полные!» Откуда такая уверенность да и ещё с восклицательным знаком? Я же спросил, вы можете вообще посмотреть объем ваших разностных копий? Вы видите что у вас копируется вообще и какого объёма? Оптимальна ли схема бэкапирования? Отчего зависит вообще объем разностных копий? Я всё это вижу (см. скрин выше), а вы как, на авось? Элементарное перепроведение документов бухом раздует дифференциальный бэкап до терабайтов. И чё делать? Удалять весь бэкап, всю историю бэкапов?
(21) leonidkorolev, Почему на авось? Что мешает посмотреть содержимое «Устройство резервного копирования»? Ну и на диске он выглядит как один файл с вполне конкретным значением. А Trn у меня сейчас в разных файлах в одной папке. При восстановлении SQL знает что и где лежит.
Собственно вопрос: а как удалить Резервные Наборы Данных с истекшим сроком годности???
Сделано все приблизительно как описано в статье, и вырос мой файл BACKUP.DAT уже до 66 Гб……
Прикольно конечно что я могу восстановить БД до состояния «4 месяца назад в 1,45 ночи» но дикс не резиновый то….
(23) Deroswent, ну вот ещё один минус копирования в один файл. Оставьте этот раздутый файл и переделывайте схему бэкапирования.
(24) leonidkorolev, вот я и стаю на пороге этого. Но никак не могу сообразить как удалять ненужные мне файлы. Допустим, каждый бекап делается в отдельный файл.
Как удалить файлы старще 14 дней к примеру?
(23) Deroswent, Если будете сохранять в отдельные файлы, то в план обслуживания добавьте Задачу «Очистка после обслуживания» и настройте на удаление резервных копий. Я же переношу раз в 3 мес. этот один большой бэкап на сервер-архив. После срабатывания задания опять создается файл бэкапа с новым архивом.
Скажите, а как настраивается количество бекапов? Ну то есть, чтобы был не всегда только последний полный бекап, а к примеру, несколько бекапов, Каждый из которых можно было бы восстановить?
(27) По умолчанию так и будет, а вообще в плане обслуживания (недельном или дневном) в настройках задачи «Резервное копирование БД», есть настройка что делать, если набор записей не пустой, по умолчанию стоит «Присоединить», т.е. к существующим бэкапам добавиться новый. Можно поставить «Заменить», тогда каждый раз у Вас будет последний бэкап.
Друзья, посоветуйте.
Если по плану обслуживания по какой нить причине не было сделано бекапирование, как сделать чтобы пришло оповещение на почту об этом.
Необходима жесткая проверка средствами SQL. Ну скажем после работы плана обслуживания запускается проверка существует ли в каталоге с бекапами файлы резервных копий. Интересует вариант исключительно средствами самого SQL возможность такая.
(29) Гость, В редактировании плана обслуживание к задаче «Резервное копирование» нужно добавить задачу «Уведомление оператора» и связать их «красной» стрелочкой (добавляете обычную и по правому клику в контекстном мены выбираете «Ошибка»).P.S. нужно добавить в Агенте сервера оператора и настроить e-Mail и/или команду net send
Может кто то из присутствующих показать План обслуживания!
1-Настройка «Обслуживание БД 1с» Регламентные операции ежедневное
2-Настройка «Резервное копирование БД и лога» ежедневное
Как все это совместить с 1 БД возможно и просто, а вот если БД 15 шт.
Сейчас все крутится на PostgreSQL, но надо перенести все БД в MSQL 2012!
(31) для обслуживания баз в план добавляется операция, в свойствах операции выбираете для каких баз она должна выполняться. Плюс указываете последовательность выполнения.
Не подскажете что нужно сделать что бы очистить!
Резервное копирование лога каждые 10 мин!
В настройках плана указал срок набора резервного копирования 1 день!
Копирование настроено на «Устройство резервного копирования»
Диски 1-2-3-4-5
Вопрос как можно очистить??
на курсах администрирования есть отдельное занятие посвященное именно вашему вопросу
Спасибо, очень полезная статья.
Реально ни чего лишнего.
А как же Дефрагментация индексов?
Для того, чтобы делать полные резервные копии базы — должна быть или очень большая база, или мало места для резервного копирования, или стальные нервы админа. Делаю полную копию рабочих баз каждую ночь, в рабочее время каждый час разностная копия (простая модель восстановления, интервал в 1ч согласован), полная модель в случае с 1С 8 может вызывать вопросы, хотя она, конечно, намного лучше.
Очень большая это какой размер? У нас 3 базы и каждая больше 100Gb и это на самом деле не много. Полный бекап такой базы примерно 10Gb, сильно накладно и не обосновано делать каждую ночь в таком случае полный бекап. Какие вопросы может вызвать полная модель в случае 1С? Речь идет об резервном копирования средствами СУБД, и целостность БД обеспечивается именно ей, и без разницы, что за БД подключена 1С или что-то еще. В методической поддержки для разработчиков и администраторов 1С сказано, что при клиент-серверном размещении БД, резервное копирование обеспечивать самой СУБД.
спасибо большое,простым языком,с картинками,очень доступно.как будто читаю детскую книжку с иллюстрациями)
Спасибо.
Доброе, у кого еть скрипт, ежедневного восстановление базы на втором сервере из бекапа? как это лучше реализовать? SQL серверы разных версий 2012 и 2019
(41) Здравствуйте, как вариант:
1. Зайти в Management studio;
2. Кликаем Правой кнопки мыши по нужной ИБ -> Задачи->Восстановить-> База данных. В открывшемся мастере настроить так как должно у вас всегда выполняться восстановление и нажать вверху радом с кнопкой «Скрипты» чёрную стрелочку вниз, чтобы открылся список вариантов, выбираем «Буфер обмена»;
3. Создать план обслуживания в с одним заданием «Выполнение инструкции T-SQL», вставить из буфера полученный скрипт. Настроить расписание.