February 8, 2011 at 8:26 am
Is it possible to configure log shipping on the target standby server to use transaction log backups generated from an existing standard backup job?
The reason I ask is we already have jobs in place that backup transaction logs to an off server share. If it were possible to set up log shipping such that it uses these existing logs, the benefits would be two fold. For one, we wouldn't have to reinvent the wheel because these jobs are tried and tested and already running. Secondly, and more importantly, the current job uses a maintenance plan and uses the "Backup ALL DBs" option. This is pretty important to me because it requires no human intervention to start backing up a new database that has moved to production.
I'm concerned that if we start using log shipping, we will have to scrap this existing maintenance plan, and someone will have to remember to add it to the list of databases that need a transaction log backup upon a move to production.
No, it's not the end of the world if this is how it has to be, but I'm all for eliminating as many places to make an error as possible in our processes.
February 9, 2011 at 12:38 am
It means you need manual logshipping if I am not wrong but that invloves lots of scripting and lots of checks from yourside.
Bipan
February 9, 2011 at 12:50 am
It can be done. I had come across one such setup few years back.
M&M
February 9, 2011 at 12:51 am
If you implement log shipping you will need to remove the DB from the log backup job. You can write your own log shipping, but it will be a lot of work and you'll have all the monitoring to write manually, all the debugging to do, all the problems that MS found and fixed to fix yourself.
Not recommended.
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
February 9, 2011 at 8:03 am
I was afraid of that. I was hoping there was an option somewhere I haven't found where you could just point the standby server to a directory full of logs, and it could be smart enough to just grab them from there, restore them in order, and then move them out. Maybe some day 🙂
Okay, time to consider mirroring instead, then. Thanks all!
March 5, 2011 at 11:13 am
I would set up logshipping the Microsoft way. Point it at your exisiting transaction logs when asked where the secondary server can copy them from. Once complete disable the backup job that this process creates.
I've done this several times before and never had to change an existing backup routine.
March 8, 2011 at 6:45 pm
If you're prepared to move away from maintenance plans, you could write a custom log backup job that only backs up the logs for databases that aren't being log shipped (the log_shipping_monitor_primary table in msdb contains this info). That way, you don't have to remember to include or exclude databases from log backups...
January 18, 2013 at 5:21 am
I tried it the way MysteryJimbo described. But the copy job didn't copy the backups. If I copy them manually, the restore job didn't restore them. The jobs don't create any error messages, they just skip all the backup files.
I can restore them manually without problems.
Does it really work that way?
Do the file names matter?
How does the copy/restore jobs identify valid log backup files?
(SQL Server 2008 R2)
regards
Tobias
January 18, 2013 at 8:21 am
Rather than trying to make log shipping work with your existing log backup job, why don't you just switch your backups to a smarter backup solution. for example, the Standard Backup scripts I posted will automatically skip log shipping partners in the log backups.
Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply