Доброе утро,помогите разобраться с с такой ситуацией, каждую ночь делается разностное копирование БД, ежечасно с 9-21:00 бекап ЖР. Наутро в 9:00 создается первый бекап ЖР в 1,5-2 раза превышающий размер БД=2 ГБ.С 10-21:00 каждый созданный бекап ЖР не превышает 130-250 МБ. Вопрос в чем заключается причина такого резкого роста бекапа ЖР утром после ночного бекапа БД и каким образом можно устранить эту проблему?

смешалиь люди кони...
причина роста журнала транзакций (при полной модели восстановления) скорее всего в том что ночью выполняются какие то регламентные процедуры. Смотри логи.

Обычно ставят простую модель восстановления и проблем с логами sql не возникает.

ВЫполняются регламентные операции до резервного копирования,думаю что после этих операций и копирования наутро ЖР разрастается и бекапит все начиная с 21:00 до 9:00. Как сделать так чтобы утренний бекап ЖР не был таким огромным и не создавал бекап с 21:00 до 9:00, так как ночью никто не работает, в задании указано что бекап ЖР совершается с 9-21:00

При простой модели восстановления ведь нельзя использовать бекап БД и ЖР или это не так?

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

(5)Каким образом можно перестроить стратегию резервного копирования,что можете посоветовать?

>>не был таким огромным и не создавал бекап с 21:00 до 9:00
в 21 - усечение логов, полный бэкап - и дальше как обычно бэкапы лога транзакций например

цепочка длинной в день получится

общий объем бэкапа журнала все равно будет =объему бэкапа в 09.00

(6) Никаким. У Вас она нормальная. И не слушайте (2)

(6)
Насколько важны содержащиеся данные?
Часто ли вносятся изменения в бд (какова частота)
Какой промежуток времени критичен при потери данных (час, день и тд)

Данные в БД очень важны,изменения вносятся часто с периодичностью 10-20 мин.,Восстановить данные за последний час работы.

(12) чего, три документа в час заносят?

(12) Ну тогда стратегия верная.
Тогда как вариант изменить регламентные процедуры, или изменить расписание.
1. Фул бэкап запускается у вас после выполнения регламентных процедур
к примеру в 01.00.
2.Далее идут бэкапы журналов, идут они до начала регламентных процедур к примеру 21.00 (или когда они у вас начинаются)
3.Далее после окончания регламентных процедур делается отдельное задание на усечение и сжатие лога(truncate_only и что то подобное),цепочка прерывается.
Затем стартует фул бэкап из п.1 в 01.00  и начинаетт новую цепочку бэкапов.
Но на самом деле все это нафиг не надо, обычно парятся не над размером бэкапа, а над размером файла бд.

(12) У нас регламентные процедуры идут раньше бекапа БД, бекап ЖР идет самым последним в ежедневном задании.Из вышеперечисленного мы не делаем усечение журнала после бекапа и соответственно повторный бекап после усечения журнала.Исправим расписание и порядок процедур как вы советуете

(12)Можно ли создать дополнительное задание шринк БД или надо писать BACKUP LOG db_name WITH TRUNCATE_ONLY в задании бекап ЖР?

(16) Нужно отдельное задание Execute T-SQL Statement Task в нем да пишите
BACKUP LOG db_name WITH TRUNCATE_ONLY
GO
DBCC SHRINKFILE(имя_файла_журнала_транзакций)
GO
Запускаете после выполнения регламентных процедур и перед фул бэкапом.

спасибо за совет

Регламентные задания по переиндексации и т.д. идут с 00.00 по 02.00. Значит нужно запускать урезку журнала транзакций BACKUP LOG db_name WITH TRUNCATE_ONLY до них, чтобы логи переиндексации не сели в журнал. Но в обычный день запускается разностное резервное копирование. Будет ли эта разностная резервная копия нормальной и будет ли у нее связка с полной резервной копии, сделанной в предыдущее воскресенье, или обязательно нужно после урезки делать полный бекап, а не разностный?