Comments
1 comment
-
A common cause is when the connection to the network share is lost during the copying process. When SQL Backup then reattempts to copy the file at a later time, it detects the incomplete file and chooses not to overwrite it.
To resolve this, use the option to overwrite existing files in the COPYTO location in the backup command via the FILEOPTIONS parameter. If you are not currently using the FILEOPTIONS parameter, then add FILEOPTIONS = 4 to the backup command. If you are already using FILEOPTIONS, add 4 to the current value. For more details, please see the FILEOPTIONS section in the help file (https://documentation.red-gate.com/sbu/scripting-sql-backup-pro/the-backup-command)
Add comment
Please sign in to leave a comment.
First, read and understand how the Log Copy Queue works.
Files are placed in a backupfiles_copylist with a certain status.
Based on another forum answer, this is what the status column means.
To see all non-successful file copies, you could run this:
EXEC master..sqbdata 'select * from backupfiles_copylist WHERE status <> ''S'''
To update a status, you could run something like this:
EXEC master..sqbdata 'UPDATE backupfiles_copylist SET status = ''S'' WHERE id in (123,456)'
If after updating the status, a few minutes later the status gets set back to active, you can try a few things, restarting the SQL Backup service, or, copying/removing the files from the destination and letting Sql Backup copy them up.