+7 495 230 03 03 8 800 222 50 03
DevOps

Резервное копирование 1С на MSSQL

Резервное копирование баз 1С происходит стандартными планами обслуживания СУБД MSSQL. Система позволяет делать надежные полные, а также дифференциальные копии баз данных. Процесс резервного копирования проходит незаметно для клиента и может выполняться в рабочее время без остановки работы пользователей в 1С.

В нашем случае план предназначен для обслуживания баз данных с моделью восстановления SIMPLE.

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

Субпланы резервного копирования

Daily_Full – Ежедневно в 23:00, кроме воскресенья. Полная резервная копия баз.

Daily_diff – С понедельника по пятницу дважды в день, в 12.00 и 18:00. Дифференциальная копия баз.

Daily_log – Каждое воскресенье в 21:00. Полная резервная копия баз.

Weekly – Каждый первый день месяца в 23.00. Полная резервная копия баз.

Создание и настройка нового плана обслуживания

  • В Microsoft SQL Server Management Studio создаем новый план обслуживания. Управление – ПКМ на план обслуживания – Создать план обслуживания. И называем его Backup.
  • Входим в ВложенныйПлан_1 двойным кликом ЛКМ, корректируем его название, после чего входим в расписание и редактируем его.
    Пример расписания вложенного плана Day_full

    Рисунок 1 — Пример расписания вложенного плана Day_full

  • Раскрываем панель элементов и перетаскиваем в наш вложенный план Задачу “Резервное копирование баз данных” и “Очистка после обслуживания”.
    добавление задач во вложенный план

    Рисунок 2 — Добавление задач во вложенный план

  • Входим в Задачу “Резервное копирование баз данных” (два раза ЛКМ по задаче) и настраиваем ее.

Общее. Тип резервной копии: Полное. Базы данных: Все пользовательские базы данных (не master, model, msdb, tempdb).

Целевой объект. Создать файл резервной копии для каждой базы данных. Создать вложенный каталог для каждой базы данных – ставим чекбокс. Папка: Указываем путь до хранения резервных копий (Day_full). Расширение файла резервной копии: bak.

Параметры. Сжимать резервные копии: Сжимать резервные копии.

Входим в Задачу “Очистка после обслуживания” (два раза ЛКМ по задаче) и настраиваем ее. Удалить из папки файлы с определенным расширением. Папка: Указываем путь до хранения резервных копий (Day_full). Расширение файла: bak. Включить вложенные папки первого уровня – ставим чекбокс. Удалить все файлы старше чем: в нашем случае это будет 7 дней.

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

Связь между задачами

Рисунок 3 — Связь между задачами

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

  • Нажимаем Добавление вложенного плана -> задаем имя и описание вложенного плана -> заходим в календарь -> настраиваем расписание вложенного плана.
    Связь между задачами

    Рисунок 4 — Настройка вложенного плана Week

    Связь между задачами

    Рисунок 5 — Настройка вложенного плана Month

Настройка задач во вложенных планах Day_diff, Week, Month

  • Настройки для задачи “Резервное копирование базы данных” во вложенном плане Day_diff аналогичны таковым в Day_full, за исключением типа резервной копии: Разностное.
  • Настройки для задачи “Резервное копирование базы данных” во вложенном плане Week и Month аналогичны таковым в Day_full.

После настройки всех вложенных планов сохраняем План обслуживания. Нажимаем ПКМ на План обслуживания Backup -> ЛКМ на сохранить выбранные элементы.

Дата публикации: 26 декабря 2022
Не нашли ответа на свой вопрос?

Смотрите также

Обсуждение материала

  • Аноним

    А зачем так сложно? Если есть деньги на MS SQL – то найдутся деньги на Veeam. Veeam умеет делать бэкап всей машины, и в придачу пишет лог транзакций – точки восстановления можно делать чуть ли не каждую минуту.

    • https://efsol.ru/ EFSOL

      Иван, Veeam отличное решение, но вот на счет средств на его закупку – спорное утверждение. И именно для тех, кому хватило денег только на MS SQL и написана данная инструкция, могу вас уверить, что таких пользователей достаточно много!

    • Аноним

      а обслуживать базы вим умеет?)

  • Аноним

    После перевода баз в simple recovery model вы теряете возможность восстановления по журналу транзакций, которую предоставляет full. Случись что в интервале между переводом в simple и созданием резервной копии – вы потеряете день. Такие рецепты – подробные, с картинками, без описания того, почему делается именно это – попросту опасны.

    • https://efsol.ru/ EFSOL

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

  • Аноним

    Инструкция какой-то сумбур. Новичку приходится 1000 раз перечитывать, чтобы понять ход мыслей автора.
    Например “Теперь необходимо добавить в субплан задачи очистки”. В какой субплан? Откуда можно понять, что мы создали отдельный план обслуживания CleanUp (только по скриншоту?) и видимо так же нужно создать отдельный план Backup? Или мы все это делаем в одном плане обслуживания? Лучше видео сделайте, понятней будет.

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

    • https://efsol.ru/ EFSOL

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

  • Аноним

    В инструкции Резервное копирование 1С на MSSQL пункты 10 и 13.8 разве не делают одну и ту же операцию. В чем смысл такого дублирования?

    • https://efsol.ru/ EFSOL

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

  • Ruslan Kupriyanov

    А для чего постоянно перекидвать базу из Full в simple и обратно что будет если этого не делать?

    • https://efsol.ru/ EFSOL

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

  • Аноним

    Переписали инструкцию? Есть смысл делать по ней сейчас?

    • https://efsol.ru/ EFSOL

      Добавили информацию по субпланам и уточнение в п.4. Так то инструкция рабочая и была.

  • Аноним

    Вообще не понятно, в кокой момент мы создаем Maintenance plan, в какой субплан; очень неинформативные скриншоты… Простой админ не осилил настроить бекап по вашей инструкции, пришлось самому раскуривать.

    • https://efsol.ru/ EFSOL

      Сначала Maintenance (п.3), затем субпланы. Да, инструкция устарела. Напишем новую.

  • Николай Тестов

    Здравствуйте. Подскажите (может я не прав) в суб. плане Daily_diff – Вы пишете 2 раза в день. Насколько мне известно (может я не прав конечно) но Разностные (Differential) можно делать только после полного бекапа. А как делать 2 раза после 1 бекапа?

    • https://efsol.ru/ EFSOL

      делается фул-бэкап, на основе него 2 инкрементных

      • Николай Тестов

        Ради эксперимента настроил 1в1 как в инструкции. Сделал все бекапы. Логи каждую минуту.

        Запустил Daily_Diff – сделал 1 бекап. Запустил второй раз через 5 минут:

        Не удается выполнить разностное резервное копирование для базы данных “test”, так как не существует ее текущей резервной копии. Произведите полное резервное копирование базы данных, выполнив инструкцию BACKUP DATABASE без параметра WITH DIFFERENTIAL.

      • Аноним

        Второй инкрементный всегда делается на основе первого инкрементного, который на основе полной.
        Дифф делается всегда на основе последней полной.

  • Аноним

    А если в П.2 все-таки не отключать автоматическое обновление индексов что-то плохое будет кроме избыточности?

    • https://efsol.ru/ EFSOL

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

  • Аноним

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

  • Аноним

    Статья вредная. Во первых делать каждый сутки полный бэкап, это зачем? Во-вторых вы нормальную статью напишите для начала, на половину комментариев пишите – исправим, дополним, извините. А новички бьются и не могут ничего настроить. В третьих, сейчас SQL работает у всех Always on и ваша инструкция как будет работать? Вы хоть сами пробовали? Не советую никому следовать этой инструкции. Давно проверенный подход – в субботу утром полную, потом разностную и логи. Все. Никакой больше самодеятельности

    • https://efsol.ru/ EFSOL

      Статья будет в этом месяце обновлена еще раз.

    • Eugene Jurasz

      А что плохого делать полный бэкап раз в сутки? Все зависит от БД, конечно, от ее размера. Но мы даже базу размеров 1 ТБ делаем полный бэкап каждый день, просто банально такие бэкапы легче потом перекидывать на холодное хранение.

Содержание

Заказать звонок

Оставьте свои данные для того, чтобы специалист с вами связался.

*нажимая на кнопку, Вы даете согласие на обработку персональных данных
Быстрое внедрение включает:
На сервере установлено следующее ПО (доступно при подключении по протоколу RDP):
Также настроено:
Перед внедрением клиент предоставляет информацию о пользователях (логины и пароли). После завершения работ, клиенту высылается инструкция и ярлык для подключения.
Индивидуальное внедрение по ТЗ клиента обсуждается отдельно.