Одной из растпространённых схем резервирования является отписывание в предварительно созданную полную копию записей журнала транзакций. Для этих целей используется оператор BACKUP LOG. При таком подходе, в копию попадают записи журнала транзакций от момента, когда была создана полная копия или отписывались транзакции последний раз и до конца текущего журнала. При этом от журнала будет отсечена неактивная его часть вплоть до начала активного фрагмента, т.е. до того места, откуда начинаются активные в этот момент транзакции и далее, до конца журнала. Поскольку, после отписывания журнала в копию происходит очистка завершённых транзакций, таким способом можно удерживать размер журнала в разумных пределах (он не будет "распухать" у вас до следующей полной копии). Кроме того, соблюдается хронология выполнения операций, т.е. можно их восстанавливать в обратном порядке, как они выполнялись, а не последнее значение (разностная копия).
Возможен случай, когда в промежутке между очередным резервным копированием журнала (по описанной выше схеме) у Вас будет повреждена база данных или даже утеряна полностью. Не отчаивайтесь, выход есть. Правда, для этого нужно, что бы "выжил" файл, содержащий журнал транзакций. Поскольку в журнале останутся записи после Вашего последнего резервного копирования, Вы можете применить оператор BACKUP LOG с параметром NO_TRUNCATE, после чего всё содержимое журнала транзакций попадёт в Вашу резервную копию, даже если сама база уже не доступна. Разумеется, усечения журнала транзакций не происходит и у Вас появляется возможность восстановить данные на момент сбоя. Вы восстанавливаете базу из имеющейся копии, а потом восстанавливаете транзакции из журнала, которые Вы скопировали с параметром NO_TRUNCATE. Забыл ещё одно непременное условие: кроме журнала, у Вас должны обязательно выжить .mdf файл этой базы, где хранятся системные таблицы и база master.
Параметр TRUNCATE_ONLY или NO_LOG в увязке с BACKUP LOG может помочь Вам просто очистить журнал. Надеюсь, Вы сделаете сразу после этого резервную копию. При этом активная часть журнала остаётся не тронутой. Такая операция может понадобиться, если журнал разросся до такой степени, что заполнил всё свободное дисковое пространство и пользователи не могут больше вносить изменения. Я же, искренне надеюсь, что Вам доведётся прибегать к подобной операции только в тестовых условиях, когда потеря данных не критична. Есть в таком подходе и один приятный момент: дело в том, что выполненная после очистки журнала полная копия получится меньше, чем обычная (за счёт отсутствия в ней не активных записей журнала). Этот трюк можно проделать, если Ваша база чуть – чуть не помещается на устройство резервирования. Кроме того, операция усечения журнала не регистрируется. Эффекта автоматического усечения журнала, после каждого запуска контрольной точки, можно получить установкой в TRUE параметра базы данных truncate log on check point. Завершённые транзакции будут удаляться из журнала, что не даст ему сильно расти. Правда, в таком режиме работы базы Вы на сможете отписывать транзакции в резервную копию, а следовательно, восстановлению подлежит только то, что было до этого резервировано.
Дополнительно, изучите нижеследующие материалы:
http://www.sql.ru/articles/mssql/01062802ShrinkingTransactionLogSQLServer2K.shtml
http://www.sql.ru/articles/mssql/01070602SQL2KRecoveryModels.shtml
http://www.sql.ru/articles/mssql/01070901QuicklyShrinkingTransactionLog.shtml
http://www.sql.ru/articles/mssql/01070903TruncatingTransactionLog.shtml
http://www.sql.ru/articles/mssql/01072301CausesOfSQLTransactionLogFillingUp.shtml
http://www.sql.ru/articles/mssql/01072302TransactionLogStillFull.shtml
http://www.sql.ru/subscribe/70028/06.shtml#7