Mike Hinds (5/16/2013)
2) The weekly full backup is part of a multi-step maintenance job that also performs DBCC CHECKDB, index rebuilds, etc. It first performs a "Final" Log Backup, then changes to SIMPLE, performs the maintenance, then changes back to FULL immediately before the Full backup step.
To be blunt, that's not a good idea.
Do you test restores? If not, let's say that the full backup after the maintenance is damaged and you don't notice it. 2 days later the database drive fails and you need to restore. Easy enough, full backup, latest diff, all logs since then, except the full backup is damaged and won't restore.
So, go back to the previous full backup, restore the diff, restore all logs. Great, but the last log that will restore is the one right before the switch to simple recovery model. You've just lost 2 days of data.
If you want minimal logging for the index rebuilds, consider bulk-logged recovery rather than simple. Yes, the log backups over that period will be huge, but at least you'll have an intact log chain and multiple options for restoring if there's some disaster
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability