What are the challenges you face when working across database platforms? Take the survey

newbie log ship console questions

richardjrichardj Posts: 3
edited November 5, 2007 4:24AM in SQL Backup Previous Versions

Using the product (v5.2) for the first time today I set up log shipping of a 24GB db. I left the console for a couple of hours, came back and the UI was unresponsive. Left it another hour and it was still unresponsive. I end tasked the session (I could not see any SQL activity) and went back. The db restore is stuck on 21.9GB and is "in progress".


Once you loose/hide the log ship setup wizard window how do you view/get it back?

I presume this attempt is fubar'd - how do I kill the this job, do I have to restart the service?

If I want to log ship but include a full db restore each night, what's the simplest way to achieve this?

Many thanks in advance

Just an update on this. I've realised that the console/wizard seems to hang/crash when I connect/disconnect from a TS session onto the server. Is this a known issue?


  • Options
    When a backup or restore step is in progress and the progress dialog has been minimised, the window can be reopened by clicking on the arrow at the bottom right of the screen (which indicates the number of tasks in progress currently).

    The simplest and safest way to stop an in-progress backup is to stop and restart the service.

    As for your third question, I'm not entirely sure why you would want to include a full restore, since if the log shipping is running successfully it should include all of the updates that the full backup would supply.

    But to attempt to answer your question anyway; including a full restore in a log shipping scenario can be tricky, because as soon as you perform the restore you may have one or more logs that are no longer applicable (and no simple way to identify or remove them from the log shipping process). The only suggestion I can make would be as follows:

    - Set up a task to disable the log shipping backup job before the restore occurs
    - Ensure that at least one final restore job occurs to process any outstanding backup files
    - Perform the full restore - note that during this time the secondary server will not be usable and if the primary server goes down any changes during this time could be lost.
    - Enable both the backup and restore log shipping jobs again.

    It's not ideal, and it requires a fair bit of Transact-SQL know-how (although Books Online may be able to help). You should only consider that option if you really have to do it.


    We're not aware of any issues specific to Terminal Services or Remote Desktop with SQL Backup. If you could provide some reproduction steps (and information; such as OS, SQL Server and SQL Backup versions), I'll look into the situation further.

  • Options
    Hi Jason

    Thanks for the reply.

    The need for nightly full backup is...
    a) With nightly index maintenance jobs the total size of the logs is equivalent to the size of the database, so a full restore might as well be taken.
    b) I am not confident in a DR solution built upon thousands and thousands of transacation logs 24 hours a daya 365 days a year. However I would be confident in a nightly full restore solution plus tlogs throughout the day. The system I am working only needs to be recoverable during business hours 8am-8pm, so I have a 12 hour window to complete a full restore.

    The TS issue is probably because the log shipping wizard is still executing. However I can't prove/disprove this.

    I will keep you updated on my progress.

Sign In or Register to comment.