CopyTo failure

BruceBBruceB Posts: 14
edited July 22, 2014 4:53PM in SQL Backup Previous Versions
Our normally very reliable log shipping setup failed to copy 19 files in the wee hours of Sunday morning.
For all the failed copies, backupfiles_copylist shows a status of E, count of 0, retrycount of 0, diskretrycount of 10, created 2014-07-19 23:53:06.203, last attempt is NULL and lastupdated of 2014-07-20 13:32:29.000

I'm assuming the count of 0 means that the reason for failure was something that just wasn't recoverable so it didn't retry but I don't have any good ideas of what it could have been.

The backup had completed successfully and subsequent files copied successfully as well.

I've been asked to explain why it happened so any suggestions as to what I can investigate are most welcome.

Running SQL Backup 7.6.0.29

Thanks,
Bruce.[/img]
· Share on Twitter

Comments

  • peteypetey Posts: 2,358 New member
    Anything useful in the 'backupfiles_copylist_log' table?
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
    · Share on Twitter
  • BruceBBruceB Posts: 14
    Nup. Rows like the one below all through the period of the issue (actually, all the rows in the table look exactly the same...).

    copylist_id attempt type copystart copyend success message
    356058 1 C 19/07/2014 23:52 19/07/2014 23:53 -1

    BB
    · Share on Twitter
  • peteypetey Posts: 2,358 New member
    What's interesting is that the status of E(xpired) is logged. By default, the copy engine will stop copying a file after 24 hours. In this case, it seems to have been configured for a shorter duration. You can check the current value (if there's one) in the registry node HKLM\Software\Red Gate\SQL Backup\BackupSettingsGlobal\<instance name>\COPYTO:ExpiryIntervalInMinutes. The value is in minutes.

    From the results you posted, it seems that the file was placed in the copy queue on 2014-07-19 23:53. The copy engine only managed to process the file on 2014-07-20 13:32, by which time it flagged the copy task as having expired, and hence aborted any attempts to copy the file.

    What might have happened is that older files in the queue took a longer than expected time to get copied over to their respective destinations. The copy process only managed to process the file in question some 13 1/2 hours later, at which time the configuration flagged the file as having expired and need not be copied any more.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
    · Share on Twitter
  • BruceBBruceB Posts: 14
    Thanks Peter,

    There is no registry setting for COPYTO:ExpiryIntervalInMinutes

    A lot of large backups get copied around during this time because of database maintenance jobs. Log shipping for this server gets many hours behind at this time of the week but we have only seen it fail to copy files once before.

    BB
    · Share on Twitter
Sign In or Register to comment.