Log Shipping MOVETO failures
DonFerguson
Posts: 196 Silver 5
Occasionally I run into an issue where a log shipping file gets restored and then recopied into a the destination directory. When this happens, a subsequent restore fails because the .sqb file already exists in the MOVETO destination. If an option to overwrite the destination file were made available, it would help in makeing the Red Gate Log Shipping implementation much more robust.
Consider this a new feature request.
Consider this a new feature request.
Comments
This seems like a strange issue, would you be able to send some SQL Backup log files which contain the error and the restore job prior also?
If you could send them to support@red-gate.com quoting reference F0019058 that would be great.
Thanks,
Redgate Foundry
I already precisely know why this happens. This is a request to allow a MOVETO to self recover when it does.
The reason it happens is because I am log shipping a very large amount of databases and have configured things differently than the way the GUI wants to. I am using a RobyCopy process at the destination to move the files with the /M flag. The problem is one of timing. When SQL Backup finishes creating a .sqb file it closes it and then seconds later writes the LSN information. If the RoboCopy process happens to grab the file at the right time between when the file is initially closed and the time the LSN information is written in, then SQLBackup will retry and often subsequently succeed at writing the LSN. The problem is that since RoboCopy copied the file to the destination and the log shipping restore command is also successful at the target, it gets moved to it's final destination. In the meantime the file gets the Archive bit turned back on at the source side from the original backup with the LSN update. When this happens, RoboCopy copies the file once again to the destination. But when it restores the file and tries to move it, an error is thrown and it remains in the original destination. So in this case I need to have a way to tell it to go ahead and move this file with overwrite if necessary. That's how I manually fix the issue whenever I need to.
I have tried to adjust the timing to minimize this as much as possible, but it still happens occasionally.
The problem with the GUI config is that it needs to be set up on a database by database basis, and since I'm log shipping hundreds of databases, that doesn't work for me.
The files where the failure occurs do not have LSN information in them. But they get overwritten by same files that do. So I don't currently have samples to send you, but since I already know how this happens, I don't feel it is necessary.
This will be considered for a future release.
Thanks.
Redgate Foundry