Backup on Share NFS fails - Windows Server 2008 R2 I've a network disk where backups are stored every night, but after some hour the backup fails with the following error:


  Executing the query "BACKUP DATABASE [foo] TO  DISK = N'\\XXX.XX.XX...." failed with the following error: "Cannot open backup device '\\XXX.XX.XX.XX\vol\BACKUP\BACKUP\foo\foo_backup_2019_07_04_010253_4929321.bak'. Operating system error 1450(Insufficient System Resources Exist to Complete the Requested Service.).


or else:


  ...failed: 121(the semaphore timeout period has expired.)


To mount this share NFS i've used this command:

mount -o mtype=hard XXX.XX.XX.XX:/vol/BACKUP T:


then in registry editor i've created two DWORD values (AnonymousUid and AnonymousGid) set to 0.

I've tried also to increase KeepAliveTime registry setting but it was uncessful.

If i modify the backup job in SQL Server Management Studio to store to a local disk (eg. D:) it runs without problem but then a free space problem will be raised.

There is something i can do to solve my problem?

Hope everything is clear
Backups over the network are risky as network connectivity is not redundant.  While you can setup your server to have multiple Network Interface Cards (NICs), if one were to fail while sending the stream of data establishing a connection from the secondary NIC would still cause a disruption to the original stream, which in this case, will cause a backup failure.

There are 2 things I can readily suggest you do, as follows:


Backup Locally: Make a local backup first and then use a secondary job such as robocopy, PowerShell, etc. to copy these backups over to your network share.
Stripe your backups: Make use of backup striping.  This will often times speed up the backup process significantly.  I still think you should backup locally, but striping your backup over the network may help you beat whatever network traffic is likely causing your latency issues.  Even Ola's solution supports striping in the event you're using that.


Backing up locally is most important for your TLog backups.  If enough of those fail in a row and your Tlogs fill the drive, you can run into a database halt situation which will be a service outage.  I'm not a fan of outages, nor should you be, which is why I really think you should make a backup locally, then offload a copy of those files to your network share.