March 31, 2018 at 9:51 am
Hi,
Can any one help me with an answer pls.
I have my normal housekeeping fullbackup and transaction log backup ,running under agent job.
Now I have a requirement to make one Db under log shipping.So My question,
1)Does my existing full backup affect the log shipping? My answer is NO..is that correct?
2)Does my existing transaction log backup(which is not part of Log shipping.Log Shipping process created its own trans log backup job), will affect my log shipping, since it truncates the log? My answer is Yes and I should disable the existing log backup job.
Is my understanding is correct?
thanks
Davis.
April 2, 2018 at 7:52 am
sdavis754 - Saturday, March 31, 2018 9:51 AMHi,
Can any one help me with an answer pls.
I have my normal housekeeping fullbackup and transaction log backup ,running under agent job.Now I have a requirement to make one Db under log shipping.So My question,
1)Does my existing full backup affect the log shipping? My answer is NO..is that correct?
2)Does my existing transaction log backup(which is not part of Log shipping.Log Shipping process created its own trans log backup job), will affect my log shipping, since it truncates the log? My answer is Yes and I should disable the existing log backup job.Is my understanding is correct?
thanks
Davis.
Your understanding is correct.
Just let the log shipping backups job for the database manage the transaction log so that the log chain is maintained. Full backups do not affect the log chain needed for log shipping.
Sue
April 3, 2018 at 7:32 am
Another option that might work for you would be to add the WITH COPY_ONLY option to your BACKUP LOG command. This will then leave the transaction log intact after the backup is completed so it wouldn't interfere with the log shipping. However, this does mean you are effectively doubling up on your log backups, but the advantage is that you don't need to change your existing backup routines.
Martin
April 3, 2018 at 8:45 am
webtekkie - Tuesday, April 3, 2018 7:32 AMAnother option that might work for you would be to add the WITH COPY_ONLY option to your BACKUP LOG command. This will then leave the transaction log intact after the backup is completed so it wouldn't interfere with the log shipping. However, this does mean you are effectively doubling up on your log backups, but the advantage is that you don't need to change your existing backup routines.Martin
The copy only would have to be on the existing routine so you would need to go change it.
If you go hacking the log shipping to do COPY_ONLY backups, the "original" routine will issue a truncation and break the LSN chain and thus break log shipping
April 3, 2018 at 9:01 am
anthony.green - Tuesday, April 3, 2018 8:45 AMwebtekkie - Tuesday, April 3, 2018 7:32 AMAnother option that might work for you would be to add the WITH COPY_ONLY option to your BACKUP LOG command. This will then leave the transaction log intact after the backup is completed so it wouldn't interfere with the log shipping. However, this does mean you are effectively doubling up on your log backups, but the advantage is that you don't need to change your existing backup routines.Martin
The copy only would have to be on the existing routine so you would need to go change it.
If you go hacking the log shipping to do COPY_ONLY backups, the "original" routine will issue a truncation and break the LSN chain and thus break log shipping
That's what I meant Anthony, despite contradicting myself completely in my last sentence 🙁 . What I was inferring is that he wouldn't have to change all the file retention systems which may be nailed down by company policy and can be difficult to get changes signed off. A quick copy_only addition may be an option if that's the case.
April 3, 2018 at 2:19 pm
webtekkie - Tuesday, April 3, 2018 9:01 AManthony.green - Tuesday, April 3, 2018 8:45 AMwebtekkie - Tuesday, April 3, 2018 7:32 AMAnother option that might work for you would be to add the WITH COPY_ONLY option to your BACKUP LOG command. This will then leave the transaction log intact after the backup is completed so it wouldn't interfere with the log shipping. However, this does mean you are effectively doubling up on your log backups, but the advantage is that you don't need to change your existing backup routines.Martin
The copy only would have to be on the existing routine so you would need to go change it.
If you go hacking the log shipping to do COPY_ONLY backups, the "original" routine will issue a truncation and break the LSN chain and thus break log shipping
That's what I meant Anthony, despite contradicting myself completely in my last sentence 🙁 . What I was inferring is that he wouldn't have to change all the file retention systems which may be nailed down by company policy and can be difficult to get changes signed off. A quick copy_only addition may be an option if that's the case.
Thank you all for the response.
April 4, 2018 at 9:12 am
exclude your log shipped database from any log backup jobs, fulls should remain as is
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply