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

How do I get it to cease trying to copy a file

randyvrandyv Posts: 166
edited May 18, 2010 8:58AM in SQL Backup Previous Versions
I keep getting error messages in the following format:
SQL Backup file copy process failed to copy "M:\LDF BACKUP\LOG_(local)_DecisionStore_20100425_190000.sqb" to "\\whaley10\Backups\WFR-DailyBackups\Whaley08\LOG_(local)_DecisionStore_20100425_190000.sqb"

Last attempt started on 4/26/2010 1:00:31 PM, and failed with the error "COPYTO error: Unable to copy M:\LDF BACKUP\LOG_(local)_DecisionStore_20100425_190000.sqb to \\whaley10\Backups\WFR-DailyBackups\Whaley08\LOG_(local)_DecisionStore_20100425_190000.sqb (Source file does not exist: M:\LDF BACKUP\LOG_(local)_DecisionStore_20100425_190000.sqb).

561 attempts have already been made to copy this file.

This is absolutely accurate and also useless as the calendar has now moved on and these files no longer exist on the main backup drive and are therefore not available to be copied; yet SQL Backup keeps attempting to do so. How do I get it to stop?
What we do in life echoes in eternity <><
Randy Volters


  • Options
    You don't mention what version you are using Randy. V 6 introduced some retry options with defaults of 10 tries after 30 seconds.

    Can you provide the T-SQL that is being run please?

    English DBA living in CANADA
  • Options
    If I have to post the script 'in the clear' I'll just turn in a support call.

    Thanks anyway.
    What we do in life echoes in eternity <><
    Randy Volters
  • Options
    Eddie DEddie D Posts: 1,789 Rose Gold 5
    Hi Randyv

    Thank you for your post into the forum and sorry to read that you are experiencing a problem.

    With the error message that you are getting, I suspect that you using SQL Backup V6.*.

    As ChrisAVWood posted, in SQL Backup V6 Red Gate introduced a number of network resilience measures to help customers recover from minor network outages that in SQL Backup V5 and earlier would have caused a failure.

    The network resilience feature ChrisAVWood is refering too, when a Full, Differential or Log backup is direct to a network and when a Full or Differential includes the COPYTO keyword, the backup task or copy to task is retried by default upto and including 10 attempts which occur every 30 seconds.

    When a Log backup includes the COPYTO keyword (as in a Log shipping backup) a different network resilience feature is utilised. In SQL Backup V5 or earlier, the copying process was part of the backup process and the log backup file created, an attempt was made to copy the file.

    In SQL Backup V6, the copying process for a Log backup as been modified. The copying process is no longer part of the backup job. When the log backup job completes, an entry is added to the Log Copy Queue and it is the function of the Log Copy Queue to perform the copying process.

    By default, SQL Backup attempts to copy each transaction log backup file as soon as it is added to the log copy queue. If the first copy attempt fails, subsequent copy attempts are made according to the following schedule:

    Copy attempt - Copy attempt is made...

    1 - immediately
    2 - 2 minutes after the 1st copy attempt failed
    3 - 4 minutes after the 2nd copy attempt failed
    4 - 6 minutes after the 3rd copy attempt failed
    5 - 8 minutes after the 4th copy attempt failed
    6 - 10 minutes after the 5th copy attempt failed
    All subsequent copies - 10 minutes after the preceding copy attempt failed
    SQL Backup will continue trying to copy the oldest transaction log backup file every 10 minutes, for up to 24 hours.

    It appears from the message you are receiving, that the copying process failed for some other reason. In the period since the copying process failed, the source backup file in the Primary Backup Location is no longer available hence the error you are receiving.

    Are you able to confirm that the backup file exists in the primary backup location? Also was the backup file successfully copied to the COPYTO location?

    If you wish to delete the entry from the Log Copy Queue, please run this query in SSMS or Query Analyzer aginst the server that performed the backup:
    exec master..sqbdata 'DELETE FROM backupfiles_copylist WHERE status &lt;&gt; ''S ''' 

    To revert to the old (SQL Backup version 5) copy behavior for transaction log backups, you must edit the backup script and specify the USESIMPLECOPY keyword in the BACKUP job syntax.

    Many Thanks
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
  • Options
    Ok, I ran the suggested code to delete the entries from the queue; results were 0 rows.

    I'm having the problem again. As you can see below, the problem is the source file does not exist. Note the last message - 111 attempts to copy the file thus far - seems a tad bit over the 10 times quoted in the replies.

    Any idea how to stop this? It is flooding the email.
    ========= attachment ============================

    SQL Backup file copy process failed to copy "M:\LDF BACKUP\LOG_(local)_DBA_20100517_103000.sqb" to "\\whaley10\Backups\WFR-DailyBackups\Whaley08\LOG_(local)_DBA_20100517_103000.sqb"

    Last attempt started on 5/18/2010 8:52:24 AM, and failed with the error "COPYTO error: Unable to copy M:\LDF BACKUP\LOG_(local)_DBA_20100517_103000.sqb to \\whaley10\Backups\WFR-DailyBackups\Whaley08\LOG_(local)_DBA_20100517_103000.sqb (Source file does not exist: M:\LDF BACKUP\LOG_(local)_DBA_20100517_103000.sqb).

    111 attempts have already been made to copy this file.
    What we do in life echoes in eternity <><
    Randy Volters
Sign In or Register to comment.