Charles Kincaid (9/30/2009)
Vliet is correct. So are many of the other points raised. Yet there was one thing missed. Yet we have seen the following many times:(1) Set up a database in full recovery.
(2) Use it for a long time without ANY back up at all.
(3) Observe Log file size growth patterns during step 2.
(4) Take a full backup
(5) Continue to do 2 and 3 with no Log backup at all.
(6) Report on how long it takes to (a) reach the maximum Log file size in express, or (b) fill up your drive.
Then too look at the other articles elsewhere on COPY_ONLY. You will see the stories of people who do full backup on the weekend and Log backups daily. Wednesday some developer takes a full backup at 8AM and th automatic Log backup fires at 11PM. The developer took the backup file away, used it and deleted it. Friday at 3PM the RAID controller faulted. Once the RAID is back online you need a restore. Um. Why does this now fail to restore all the backups? Was there anything of importance done on Thursday? Let's hope not.
Microsoft introduced this for a reason. Yes even they get it right at times. 🙂 Even so you can tell that the engine folk and the tools folk don't talk to each other that much. Note that the 2005 SSMS does not know about COPY_ONLY. Supposed to be fixed in 2008.
Perhaps I am missing something. You should be able to restore it to 11PM on Thursday when the last log backup was taken, presuming of course you still have an unbroken chain of log backups back to the last full backup that you do have available.
Although I normally used Red Gate SQL Backup as an intermediate tool, I have actually been through a scenario somewhat similar to this and had no problem effecting the restore.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/