July 7, 2011 at 7:17 am
Well we are taking full backups every night on primary server, and i believe we need to restore full backup on secondry server(The server where i am restoring T-Logs all day), i am copying them to remote location because if network disconnection occurs my restore wont work as expected
July 7, 2011 at 7:46 am
the log backups are copied over. They are then restored from a local directory. Restores do not fail because of network outages. If a copy fails due to a network outage, logshipping will just try and get the file again next time until it succeeds.
Our advice to you is not to copy the full backup over.
---------------------------------------------------------------------
July 7, 2011 at 7:50 am
Well copy cannot fail as we are using DFS for copying the backups, I am in FL and our remote location is Atlanta...in case of storm network outages can be Bad...and i am using Logshipping because asynchronous mirroring is not available in standard edition
July 7, 2011 at 8:14 am
amitwadhawan (7/7/2011)
we need to restore full backup on secondry server
The first time you initialise log shipping, yes
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
July 7, 2011 at 8:23 am
@SSCrazy, So you are saying we dont need to restore fullbackups again on secondry server ,even if we are backing our primary databases everynight?
July 7, 2011 at 9:33 am
amitwadhawan (7/7/2011)
@SSCrazy, So you are saying we dont need to restore fullbackups again on secondry server ,even if we are backing our primary databases everynight?
dude amitwadhawan
please read up on Log Shipping, there are many topics on this subject including books online.
Full backups are used to first initialise log shipping or anytime you right click the log shipped database and select "Re initialise".
In short a log shipping scenario creates 3 unique core sql server agent jobs (there also some alert jobs but we'll bypass these for now).
➡ The first job is deployed to the primary server and takes scheduled backups of the transaction log (DB must be full recovery not simple)
➡ The second job is deployed to the secondary server and copies the log backup files from a share on the primary server or a dedicated network share and places them onto the secondary server.
➡ The third job is deployed to the secondary server and loops through any backup files and restores them if necessary to the secondary server database
Full and Diff backups may carry on as usual on your primary server, there is no issue there. they do not need to be replicated to the secondary server (although as with all backups they should go to offsite storage). However, any transaction log backups outside of the ones scheduled by the first job on the primary must be applied to the secondary database to avoid gaps in the log chain.
Do you understand this?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
March 26, 2012 at 6:07 pm
1. Stop & Disable Logshipping Restore job
2. Restore the first transaction log (whichever is failing) manually in NORECOVERY Mode
2. Enable & Start the logshipping restore job which automatically created TUF file for you & all proceeding transaction restores get succeded as well.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply