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.

Alexander:

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.

Alexander:

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?

Alexander:

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.