Резервное копирование баз 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 двойным кликом ЛКМ, корректируем его название, после чего входим в расписание и редактируем его.
Рисунок 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 -> ЛКМ на сохранить выбранные элементы.
Статья вредная. Во первых делать каждый сутки полный бэкап, это зачем? Во-вторых вы нормальную статью напишите для начала, на половину комментариев пишите – исправим, дополним, извините. А новички бьются и не могут ничего настроить. В третьих, сейчас SQL работает у всех Always on и ваша инструкция как будет работать? Вы хоть сами пробовали? Не советую никому следовать этой инструкции. Давно проверенный подход – в субботу утром полную, потом разностную и логи. Все. Никакой больше самодеятельности
Статья будет в этом месяце обновлена еще раз.
А что плохого делать полный бэкап раз в сутки? Все зависит от БД, конечно, от ее размера. Но мы даже базу размеров 1 ТБ делаем полный бэкап каждый день, просто банально такие бэкапы легче потом перекидывать на холодное хранение.
Подскажите пожалуйста, как бороться с проблемой реорганизации индекса для баз на платформе 22 и выше? На ИТС есть описание процесса (включение страничных блокировок), но ведь нельзя блокировки сначала для всего включать, а потом выключать.
А если в П.2 все-таки не отключать автоматическое обновление индексов что-то плохое будет кроме избыточности?
Нет, ничего плохого не будет. Это только с целью оптимизации.
Мы отключаем автоматическое обновление индексов только потому что делаем для этого отдельное задание, которое будет выполнятся по нужному нам расписанию.
Здравствуйте. Подскажите (может я не прав) в суб. плане Daily_diff – Вы пишете 2 раза в день. Насколько мне известно (может я не прав конечно) но Разностные (Differential) можно делать только после полного бекапа. А как делать 2 раза после 1 бекапа?
делается фул-бэкап, на основе него 2 инкрементных
Ради эксперимента настроил 1в1 как в инструкции. Сделал все бекапы. Логи каждую минуту.
Запустил Daily_Diff – сделал 1 бекап. Запустил второй раз через 5 минут:
Не удается выполнить разностное резервное копирование для базы данных “test”, так как не существует ее текущей резервной копии. Произведите полное резервное копирование базы данных, выполнив инструкцию BACKUP DATABASE без параметра WITH DIFFERENTIAL.
Второй инкрементный всегда делается на основе первого инкрементного, который на основе полной.
Дифф делается всегда на основе последней полной.
Вообще не понятно, в кокой момент мы создаем Maintenance plan, в какой субплан; очень неинформативные скриншоты… Простой админ не осилил настроить бекап по вашей инструкции, пришлось самому раскуривать.
Сначала Maintenance (п.3), затем субпланы. Да, инструкция устарела. Напишем новую.
Переписали инструкцию? Есть смысл делать по ней сейчас?
Добавили информацию по субпланам и уточнение в п.4. Так то инструкция рабочая и была.
А для чего постоянно перекидвать базу из Full в simple и обратно что будет если этого не делать?
Добрый день. Этот материал будет дописан, зайдите чуть позже, мы скоро разместим актуальную версию.
В инструкции Резервное копирование 1С на MSSQL пункты 10 и 13.8 разве не делают одну и ту же операцию. В чем смысл такого дублирования?
Добрый день. Этот материал будет дописан, зайдите чуть позже, мы скоро разместим актуальную версию.
Инструкция какой-то сумбур. Новичку приходится 1000 раз перечитывать, чтобы понять ход мыслей автора.
Например “Теперь необходимо добавить в субплан задачи очистки”. В какой субплан? Откуда можно понять, что мы создали отдельный план обслуживания CleanUp (только по скриншоту?) и видимо так же нужно создать отдельный план Backup? Или мы все это делаем в одном плане обслуживания? Лучше видео сделайте, понятней будет.
Так же в начале не хватает описания что мы в принципе будем делать. Т.е. какие действия поэтапно будет производить сервер.
Добрый день, Алексей, спасибо за Ваш отзыв, обязательно учтем при написании следующих инструкций. Действительно вопрос резервного копирования – не всегда прост и прозрачен, поэтому иногда лучше нетривиальную задачу поручить профессионалам.
После перевода баз в simple recovery model вы теряете возможность восстановления по журналу транзакций, которую предоставляет full. Случись что в интервале между переводом в simple и созданием резервной копии – вы потеряете день. Такие рецепты – подробные, с картинками, без описания того, почему делается именно это – попросту опасны.
Спасибо, Станислав, за Ваше внимание к нашей статье. Перед выполнением плана обслуживания выполняется полная резервная копия, которая собственно и закрывает цепочку логов, после чего проводится обслуживание с базой. Поэтому восстановление по журналу транзакций не потеряется. Так что в данной инструкции нет ничего опасного, если сделать как написано.
А зачем так сложно? Если есть деньги на MS SQL – то найдутся деньги на Veeam. Veeam умеет делать бэкап всей машины, и в придачу пишет лог транзакций – точки восстановления можно делать чуть ли не каждую минуту.
Иван, Veeam отличное решение, но вот на счет средств на его закупку – спорное утверждение. И именно для тех, кому хватило денег только на MS SQL и написана данная инструкция, могу вас уверить, что таких пользователей достаточно много!
а обслуживать базы вим умеет?)