tags:

views:

62

answers:

3

I have a production database where I run full DB backups every Sunday at 2AM and log backups every night at 3AM. The weekly full backups are around 100MB, while the log backups are around 1MB. But the log backup running immediately after the full backup (one hour after) is almost as big as the full backup (100 MB).

It's not a problem, but I'm curious as to why. Can anyone provide some insight?

A: 

one thing to check wouldbe if the wildcard/path of the log backup is picking up some archives, or if the large backup is generating enormous log files for some reason...

jspcal
A: 

Are you truncating or shrinking the log after the full backup?

Malachi
Neither, because that should not be necessary. Shrinking only deals with the log file size, not the content. Truncating would actually be destructive, since it would break the log chain and prevent recovery.
Aa
What recovery model are you using?
Malachi
Full, of course. Otherwise log backups does not make sense.
Aa
There is also bulk-logged, which requires log backups.Also, I'm not sure that log truncation is as destructive as you suggest. I'm fairly certain that it will not destroy any entries in the transaction log that are necessary for recovery (i.e. have not been backed up). http://msdn.microsoft.com/en-us/library/ms189085.aspx
Malachi
+1  A: 

Is the weekly full backup part of a maintenance plan and/or are you reorganizing/recreating indexes before the full backup? An index reorganization would explain the large logfile.

edosoft
Agreed - this shows up a lot in support calls. Index maintenance jobs cause a huge amount of log activity.
Brent Ozar