Initial Log backup fails for large database

8/24/2021 7:50:04 AM [Warning] Destination error: An unexpected network error occurred.
8/24/2021 7:50:04 AM [Info] Trying again…
8/24/2021 7:50:06 AM [Warning] Destination error: An unexpected network error occurred.

8/24/2021 7:50:06 AM [Info] Trying again…

There are no issues when I manually copy files - only this case. Any ideas?

**Yes - there is adequate space

Hi Shawn_Fielding,

To investigate this case we need more details.

Could you please let us know what destination place do you use?

Sorry for the inconvenience.


Both VMs are on SHARED storage on a SAN. So the file is being copied from one VM to the OTHER. As I said - manually copying the file never seems to fail. It only has an issue with SQLBackupAndFTP copying the file. This does not happen on the smaller databases.


Any ideas here? Is there a log that can help you diagnose the issue? Can I restore the database manually and schedule the job to run and import the smaller diff/log backups? Or is it required to press the “Initial Log Shipping” button to start the process?

Hi Shawn_Fielding,

Thank you for the details.

Could you please try to specify the full path to your network folder starting from \ also, please make sure you specify your user name and password at the "Advanced Local/Network folder/NAS settings?

Thank you and sorry for the inconvenience.

With all due respect why would you even ask this question? If ALL OTHER LOG SHIPPING JOBS WORK how would this be different? The ONLY variable in the equation is that this is the LARGEST backup file in the group.

The full path is CORRECT
The credentials are CORRECT

If those items were NOT correct then NONE of the log shipping jobs would work.

Now, can you answer the question I asked please above? Is there a way for ME to restore the backup MANUALLY and then just allow SQLBackupAndFTP to sync from that point forward? Similar in the way you configure log shipping in SQL server.

Hi Shawn_Fielding,

Oh, sorry, it seems we missed it.

Yes, you can do it, but there is one imperative requirement. The name of a full backup file that is used to be restored must have the same name as generated via SQLBackupAndFTP (for example AdventureWorks202109052100.bak). In this case, SQLBackupAndFTP recognizes that the last restored backup is a full backup, and will not download it.

Here are more details about the restore process: How to Restore SQL Server Backups | SQLBackupAndFTP's blog

Sorry for the inconvenience.

Definitely - we only use SQLBackupAndFTP to do our backups. I will try this and hopefully it works. Will let you know. Is there any way we can help you determine the root cause of the issue? For example - is there logging of any kind that can be turned on to capture more information? Maybe it will show you the real exception?


This did not work - it STILL tries to download so I assume I’ve done something wrong. I restored the backup from this morning then simply enabled the job to run - and it shows trying to copy the file still. FYI: The backup file is 67GB and ALMOST copies the whole file before timing out (or whatever the error is). Any idea what I am missing?

Hi Shawn_Fielding,

For further investigation, we need more details. Could you please provide us with your Advanced Log How to send Log to developers | SQLBackupAndFTP's blog

Please provide us with your Application ID (“Help” > “About”) to identify the logs and notify us when the log will be sent.

Sorry for the inconvenience.


Log was sent.

AppID: 011741fa-8cb5-4073-b00d-eef824e68c56

The file size is 68,747,856 kb. But at the time the issue happens you can see it grow PAST that size…after 2 retries the file was “69,849,088” kb and GROWING. It was as if the copy routine threw the exception and started to append the backup to itself.

After this you are stuck in a loop and the only way out is to kill the service.


Any ideas here yet?

Hi Shawn_Fielding,

Thank you for the logs, we have checked the issue and all indicate the network issues between SQLBackupAndFTP and your storage. Sorry, but the issue cannot be resolved from our side. Could you please contact your network administrator to check it?

Sorry for the inconvenience.

And what is your indication? You are making a statement with zero proof. Show me in the logs where there is a clear indication that this is my network.

Again - I repeat -

  1. Copying the same file via windows explorer or other utility works just fine. Every single time I copy a file manually I have zero issues.
  2. This only happens with the largest database and your application
  3. I routinely see your support site down with server 500 errors so this does not bode well for reliability
  4. I haver submitted this issue to your support email (I paid for TWO copies of this product) and when I have submitted reports of issues I did not get replies - again this does not bode well for reliability on your part. This is why I have had to post here in your forum.

Nothing in my network has changed. Nothing added, removed, or configuration changed. No faults in the equipment or wiring. So please - if you are going to say it’s on my side present actual proof from your log. Actual concrete proof.

And I would appreciate this PAYING customer being contacted directly via email as he should have been all along.

Hi Shawn_Fielding,

If you have a license with an active Full-Service subscription you can contact directly our support team at SQL Server Backup Support - SQLBackupAndFTP

Our customers faced this issue before, and we have already investigated it earlier.

The error message you get is generated in the Windows library and we do not have access to the detailed information of this error. In the last log that you sent, this error was not fully logged, since you interrupted the job before the error was generated.

We can extend the logging in the application, (or please do not click the “Cancel” button) so that the error that leads to the Windows library will be generated.

Sorry for the inconvenience.