Данный план обслуживания является обязательным в случае, если у вас полная модель восстановления баз данных, что является фактическим стандартом для всех систем, находящихся в непрерывной многопользовательской работе. В общей цепочке планов обслуживания он является последним из обязательных, но это только подчёркивает его крайнюю важность.
Самое главное, для чего нужно выполнять регулярно этот план обслуживания, так это для того, чтобы предотвратить непрерывный рост файла журнала транзакций (файла с расширением .ldf).
Дело в том, что если в этом файле не осталось места, то у системы три выхода:
- увеличить размер файла журнала транзакций;
- начать запись поверх старых виртуальных логических файлов (Virtual Log Files или кратко VLF), размещающихся в виде сегментов в пределах существующего физического файла с расширением .ldf;
- остановить работу MS SQL Server
Если не настроить регулярное выполнение данного плана обслуживания, то процесс будет идти по первому сценарию, ибо MS SQL Server, если Recovery Model = FULL для базы данных, не имеет права перезаписывать старые VLF в соответствующем ей файле с расширением .ldf до тех пор, пока в нём не появилась пометка, что это разрешено. А это разрешение появляется лишь после успешного создания резервной копии журнала транзакций.
Если же резервные копии файла транзакций успешно, регулярно и своевременно создаются, и при этом файл журнала имеет изначально адекватный размер, то он может и вовсе никогда не расти. Именно это и является нашей целью!
Второй момент, который не менее важен, так это то, что имея резервные копии журнала транзакций базы данных, мы можем всегда восстановить данные на любой момент времени текущего дня. Например, имея ночную полную резервную копию базы данных 1C-Production-DB, которая находится на диске по пути “B:\MSSQL\Backup\1С-Production-DB\1С-Production-DB_backup_2026_04_22_044500_9262669.bak” и резервные копии журнала транзакций, осуществляемые в начале каждого рабочего часа, первая из которых находится по пути “B:\MSSQL\Backup\1С-Production-DB\1C-Production-DB_backup_2026_04_22_075901_3265250.trn” мы можем восстановить данные, скажем на 12:45 сегодняшнего дня без единой потери. Для этого нужно сначала восстановить ночное состояние при помощи следующей команды:
Restore Database 1C-Production-DB
From Disk = “B:\MSSQL\Backup\1С-Production-DB\1С-Production-DB_backup_2026_04_22_044500_9262669.bak”
With NoRecovery;
Затем нужно последовательно восстанавливать все резервные копии журнала транзакций, начиная с первой, что была в 7:59, включая ту, что была в 11-59 при помощи аналогичной команды:
Restore Log 1C-Production-DB
From Disk = “B:\MSSQL\Backup\1С-Production-DB\1C-Production-DB_backup_2026_04_22_075901_3265250.trn”
With NoRecovery;
Для той же, что была в 12-59, и которая фактически содержит данные за период с 12-00 до 13-00, нужно применить остановку в нужное время при помощи следующей команды:
Restore Log 1C-Production-DB
From Disk = “B:\MSSQL\Backup\1С-Production-DB\1C-Production-DB_backup_2026_04_22_125900_8509481.trn
With StopAt = ‘2026-04-22 12:45:00’,
Recovery;
Если нужно восстановить базу данных в другую, то есть создать копию базу данных, то это делается несколько сложнее. Об этом поговорим в отдельной статье, а здесь дальше обсудим, как создать этот, как вы уже убедились, крайне важный план обслуживания.
Итак, приступим. Аналогично тому, как мы делали для предыдущих планов, выбираем из меню SSMS “Management (Управление)” –> “Maintenance Plans (Планы обслуживания)”, пункт контекстного меню “Maintenance Plan Wizard (Мастер планов обслуживания)”.
В следующем окне нам нужно будет дать имя нашему плану, например “MaintenancePlan5”, которое будет отражать тот факт, что этот план должен будет выполняться пятым в нашей цепочке. Далее, как и ранее, даём описание (Description) плана, например “Back Up Transaction Logs”.
Затем, также как и для других планов, задаём расписание, назначив выполнение плана каждый рабочий час каждого дня, например, каждый час с 7-00 до 22-59 для пользовательских баз данных, работающих в полной модели восстановления.
Для умеренно нагруженных систем этого достаточно, но если у вас высоконагруженная система с более чем 100 пользователями, работающими одновременно, то интервал резервного копирования журнала транзакций нужно сокращать. В самых интенсивно используемых базах данных нужно делать Backup каждые 5 минут.
Расписание выполнения плана обслуживания, предназначенного для Выполнения резервного копирования журнала транзакций баз данных с умеренной интенсивностью использования
Очень важно отметить, что если у вас высоконагруженная база данных и вы приняли решение делать резервное копирование её журнала транзакций чаще, чем раз в час, то в случае необходимости восстановления базы данных у вас цепочка восстановления будет очень длинной, что крайне неудобно и повышает риск ошибки. Если в нашей схеме будет всего максимум 16 файлов с расширением .trn, то в случае, если вы решите делать Transaction Log Backup каждые 5 минут, их уже станет целых 192. Для того, чтобы избежать такой ситуации в этом случае разумно делать каждый час ещё и так называемые дифференциальные резервные копии “Backup Database (Differencial)”. Но в нашем случае это излишне.
Идём дальше. Понятно, что при выборе действия в окне “Select Maintenance Task (Выбор задач по обслуживанию)” ставим на этот раз птичку на флаге “Backup Database (Transaction Log)” или в русской версии: “Резервное копирование базы данных (журнал транзакций)”.
На вкладке “Общее” выбираем конкретные пользовательские базы данных, для которых нужно будет регулярно делать резервное копирование. Обычно это только базы данных, с которыми происходит ежедневная работа. Резервные копии файла журнала транзакций для системных баз данных делать не имеет смысла, так что их не помечаем.
Дальнейшие окна и вкладки, выводящиеся мастером создания плана аналогичны тем, что выходили при создании полной резервной копии и действия ваши по выбору необходимых опций тоже должны повторять действия, произведённые в случае Full Back Up. Отличие – расширение файлов здесь будет .trn, а не .bak. Менять его не нужно.
Единственное, на что тут обязательно нужно обратить ваше внимание так это на то, что в случае резервного копирования журнала транзакций опция “Copy only backup (Только резервное копирование)” совершенно бесполезна и даже вредна. Она тут присутствует в интерфейсе просто исторически. Никогда её не используйте, ибо в отличие от FULL Backup, такой файл резервной копии всё равно вклинивается в цепочку и будет нужен при необходимости восстановить базу.
