Log shipping is a tried and true method in SQL Server for keeping a copy of your data on a secondary server. You have your primary and secondary server set up, and it’s working great. Are you monitoring it? Do you know what to do if you need to fail over to the secondary? Join Jes in this free 30 minute video to find out!

In case you missed it: Log Shipping Part 1: Preparing for Disaster!

Backups: More Important Than You Think

Grab my Backup & Recovery Step By Step training for more information on why backups and restores are so important, and how to perform them!

↑ Back to top
  1. Great webcast Jes.

  2. Awesome vid Jes…do you have this available in PDF? I just want to have the recovery steps available instead of having to keep following the video :)

  3. One of my friends told that we should not use BACKUP LOG [DBNAME] TO DEVICENAME WITH NORECOVERY during planned failover but instead we should use BACKUP LOG [DBNAME] TO DEVICENAME WITH NO_TRUNCATE,NORECOVERY.

    Also can you please provide me the T-SQL command to backup the log incase of unplanned failover (i.e. my storage on which the db resides failed but my instance is still up and running)


  5. Hi Jes, your videos were incredibly helpful. Thank you!
    I have a question on log ship best practices – is it necessary to run DBCC CHECKDB on the secondary when we do DR Testing since that is the only time it will be online unless it is a real DR scenario? Our secondary server does not have any other databases. Thanks again.

    • If running a DBCC CHECKDB is part of your disaster recovery plan, then any time you do a DR test, you should run a DBCC CHECKDB. It will help to know how long it takes.

  6. Jes, thanks for the wonderful explanation regarding log shipping and disaster recovery in SQL.

    I am not a DBA however recently I have been planning a disaster recovery plan for the company which includes several server and application, using Microsoft Azure as a recovery site. I do a backup of my current database Full and incremental every day and i have restored files (sharepoint) and databases successfully on many occasions, so no worries there. This is the first time i will be using log shipping to create a secondary database on a secondary server on Azure. I will only use that server in case of major disaster where I will not have or will never have access to the primary server. I looked at the videos and understand all the nuances and gotcha however one thing I am not clear on is the following:

    Once I setup log shipping and it is working and I monitor it and wait for disaster. There will be occasions where I might have to restore the primary databased from tape, because we have to roll back to previous days due to inventory or accounting problems (it has happened). Now with this scenario what do I do to my secondary database, do I kill the database there and start a whole new shipping log process?

    Thanks and hope you read this email as the last entry was last sept 2014.

  7. I have a question on the Transaction Log Shipping Status report. This has two columns Alert Enabled. Normally this shows True is my test setup cases.
    Do you know where this value comes from? I can’t figure out how to change this to False. It does not have anything to do with the enabled status of the agent alerts. I cannot find documentation on this.

    Another point it that you advise to enable notification on the alert job(s). Another option is to enable notification on agent alerts ‘Log shipping Primary Server Alert.’ and ‘Log shipping Secondary Server Alert.’. In my test cases this gives more clear error messages to me (not just The job failed …).
    What is your view and experience on this?

Leave a Reply

Your email address will not be published. Required fields are marked *