Skip to main content

Timeline for How do I resume log shipping?

Current License: CC BY-SA 3.0

7 events
when toggle format what by license comment
Jul 10, 2014 at 8:57 comment added NibblyPig I've figured it out, you are correct. I restored the database in NORECOVERY and log shipping could resume. When it was broken, the source server would run the job and report no errors and that everything was fine, but delving into the job on the target server being shipped to, it showed there was an error restoring it. It was a bit hidden!
Jul 10, 2014 at 8:56 vote accept NibblyPig
Jul 9, 2014 at 20:34 comment added mrdenny Because I don't know how well the logshipping that comes with SQL Server is going to handle the database being deleted and manually restored into no-recovery. It might work just fine, or it might give you all sorts of problems as older logs can't be applied. Either way at the very least you'll need to backup the production database and restore it to your secondary server.
Jul 9, 2014 at 8:10 comment added NibblyPig Why does starting the restore process over involve removing log shipping, then going in and typing all the details in again, eg. schedule, paths to files, target database etc.?
Jul 8, 2014 at 16:24 comment added mrdenny When a failover happens you wouldn't need to do that, but this wasn't a failover event. When you failover the LSN chains aren't broken so the two databases are still in sync. When you brought the backup databases online you broke the LSN chain so you have to start the restore process over.
Jul 8, 2014 at 16:20 comment added NibblyPig That could be a pain in the arse if I have to remove and re-add every single log shipping task on the server whenever there's a failover. Log shipping originally worked without any databases on the secondary, it created them. Perhaps I just need to write a big script to remove all the tasks and recreate them or something... in this day and age:S
Jul 8, 2014 at 16:17 history answered mrdenny CC BY-SA 3.0