Hi Alexander,
We are facing the same issue to one of the FTP Server.
- ERROR: Destination error: This request operation sent to net.pipe://localhost/pranasnet/net/sbf/Trace/Net.pranasnet.sbf.Trace did not receive a reply within the configured timeout (00:03:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
Hi Richard_Hamblin,
Thank you for the details. Please give us some time to check your log.
Sorry for the inconvenience.
Hi Howard_Crompton,
Could you, please send us the advanced log to check it. Here are more details on how to do it https://sqlbackupandftp.com/blog/how-to-send-log-to-developers
Please let us know when the log will be sent, also please provide us with the Application ID (“Help” > “About”) to identify the log.
Sorry for the inconvenience.
Hello,
we’re facing the same issue. After update from SQLBackupAndFTP (SBF) v10.x.x to v12.2.11 job fails each day and we changed nothing in network configuration.
Details (all steps here are carried out by SBF):
- we’ve got a job backingup ~190GB MS SQL database, full backup
- backup is downloaded on backup server where SBF is installed
- file is then compressed (actually just splitted due to another issues in SBF software I’ve already reported, but that was the reason I’ve updated SBF version) which creates 3 volumens 01 (58,6GB), 02 (58,6GB), 03 (47,4GB)
- next we try to upload them on 2 destinations (local drive and Amazon S3)
- upload on local drive fails due to timeout error
- remove from local drive fails due to timeout error
- anything related to the local drive fails but it used to work each time before update to new SBF
- next, S3 upload and cleaning ends without any error (thanks to split into volumes)
My co-worker told me “in previous version there was some kind of a timeout setting, now it dissapeared”.
Steps order also seems to be strange:
- uploading 001 on local drive
- uploaded 99,7%
-
deleting 001 from local drive (???)
- ERROR: timeout destination
- uploading 002 on local drive
- ERROR: timeout delete 001
Log:
• 3:07:09 PM : The current destination folder is “E:\abc\Backups”
• 3:07:09 PM : Sending backup of “abc_FileStore” to Folder destination “E:\abc\Backups”
• 3:07:09 PM : Uploading local “abc_FileStore201912151215.7z.001” to remote “abc_FileStore201912151215.7z.001” in folder “E:\abc\Backups”
• 3:23:38 PM : Uploaded 99.07 % (average speed = 60.1 MB/s)
• 3:15:32 PM : Deleting file “abc_FileStore201912151215.7z.001”
• 3:21:32 PM : ERROR: Destination error: This request operation sent to net.pipe://localhost/pranasnet/net/sbf/Trace/Net.pranasnet.sbf.Trace did not receive a reply within the configured timeout (00:03:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
• 3:12:32 PM : Uploading local “abc_FileStore201912151215.7z.002” to remote “abc_FileStore201912151215.7z.002” in folder “E:\abc\Backups”
• 3:18:32 PM : ERROR: Failed to delete file “E:\abc\Backups\abc_FileStore201912151215.7z.001”: This request operation sent to net.pipe://localhost/pranasnet/net/sbf/Trace/Net.pranasnet.sbf.Trace did not receive a reply within the configured timeout (00:03:00). The time allotted to this operation may have been a portion of a longer timeout. This may be because the service is still processing the operation or because the service was unable to send a reply message. Please consider increasing the operation timeout (by casting the channel/proxy to IContextChannel and setting the OperationTimeout property) and ensure that the service is able to connect to the client.
• 3:23:43 PM : Connecting to Amazon S3 destination “xyz-abc”
Hi Alexander,
I have forward the advanced log to you and my application id is 20ce7936-9eef-4b5f-9e7d-8438dbd9fd37
Hi guys,
Thank you for the details.
Could you please install the following Alpha edition http://sqlbackupandftp.com/download/alpha and save the following Timeouts.xml https://www.dropbox.com/s/dig225j1atp8oly/Timeouts.xml?dl=0 file into the following folder C:\ProgramData\Pranas.NET\SQLBackupAndFTP\Service\ It should resolve the issue.
Sorry for the inconvenience.
Hi Alexander,
I did what you suggested:
- install alpha version (v 12.2.11.14)
- copy Timeouts.xml file and place it inside app directory
- run vaccum command on sqllite (you adviced this in some other topic, probably not related but you need to know)
Unfortunatelly it did not help. Application still throws a timeout exception (dont know for which operation because logs are unclear here).
It is important to notice that timeout period did not changed after applying Timeouts.xml file. It still informs about 3 minutes (00:03:00) where the shortest value in Timeouts.xml is 6 minutes (360sec).
Error:
Timeouts.xml file
Hi jankowicz,
Appreciate your response with the detailed information!
Could you please tell us, have you restarted SQLBackupAndFTP (SQL Server Backup) Windows Service after you saved Timeouts.xml file? If no, please try to restart it and check if the issue is resolved?
Sorry for the inconvenience.
Hi Alexander,
application and service were restarted manually after we copied this file into app folder and after restart we confirmed that Timesheets.xml were not overwritten by the app. Maybe worth to notice: just realized that firs part of backup (1 of 3) is always copied from few weeks (probably after installation of alpha), during the second part it fails. So 58GB is copied ok, and after few more GB it fails. There is no proxy or firewall between these 2 machines.
Alexander, I see you are a busy man and probably you’re alone here, so thank you for answering allquestions on that forum. But… can you treat this ticket with higher priority? It is going on for a very long time now, this topic has 1,8k views and is one of the most popular on your forum. Maybe you guys dont have enough logs inside app?
I’ve reported 4 bugs, 3 of them were confirmed and fixed by your and were not easy to reproduce. So you may assume we’re not fnatasising and we did all we could to support this diagnoscit process and eliminate all obstacles on our side. What else can we do? What has changed between v10 and 11-12? Can you give us some advices, tips, next steps?
Kind regards
jankowicz
Hi jankowicz,
We are really sorry about the inconvenience and thanks for the bug reports. Currently, we are working on the new release where this issue should be fixed.
Sorry for the delay and for the inconvenience.
Hi jankowicz,
Sorry for the delay. The new version with the fix is available at the “Download” https://sqlbackupandftp.com/download page. Could you please install it and check if it works?
Sorry for the inconvenience.
Hi Alexander,
we’ve installed v12.3.3 a few days ago but unfortunately it did not fix the issue. Today we’ve find out why. Timeouts.xml file which we’ve been asked to download from Dropbox a few weeks ago (link to this file is still valid and can be found a few posts above) has different schema than XML described here https://sqlbackupandftp.com/blog/how-to-increase-timeout-values So, I assume spp couldn’t read it (parse error) and has always set up default values and thats why we always get timeout error after 00:03:00 (180 sec). Update process from 12.2.x to 12.3.3 did not replace wrong file with the correct one. Don’t know how to comment it especially that I’ve pasted incorrect Timeouts.xml a few posts above with info that app did not load custom timeouts and instead still uses the defauld ones and… nobody noticed.
We’ve replaced incorrect Timeouts.xml today taking example from your Wiki and increasing timeouts for NetPipe as needed. I’ll let you know tomorrow if it helped.
Dear jankowicz,
Sorry for the inconvenience.
Sure, please feel free to contact us on any issues or concerns.
Hi Alexander,
Timeouts helped. App is finally able to copy backup from the server to disk destinaiton on local network.
Thank you.
Hi Alexander,
Not quite as successful here, After applying the timeouts.xml from the wiki entry, I’m still getting time timeout messages. I’ve double the timeouts to 6 minutes, but I still get regular 3 minutes timeouts according to the error log. It seems to happen when deleting backups that are older and set for cleanup.
Thanks Richard
Hi Richard_Hamblin,
check Timeouts.xml schema twice. I downloaded this file first time from Dropbox as Alexander asked me and it did not work. Found out that XML schema in Wiki differs from schema from Dropbox. Use schama from Wiki and app v12.3.3. App update did not override Timeouts.xml to valid one - maybe a bug or maybe intentional to preserve your configuration. But the fact is that XML schema has changed since they introduced Timeouts.xml for the first time.
Hi jankowicz,
I’ve recreated the timeouts.xml from the Wiki page and I’ll see how it gets on overnight.
Thanks for the info
Hi guys!
Thank you for the details, also you can find more information about how to increase timeout values at https://sqlbackupandftp.com/blog/how-to-increase-timeout-values
Alexander,
it seems that this it not the end 
Got v12.3.4 and it worked as a charm since we’ve changed Timeouts.xml few days ago (valid xml schema and long timeouts). But now 2 times in a row it failed from the same reason as previously - timeout error during upload:
Uploading local “xxx_FileStore202002060900.7z” to remote “xxx_FileStore202002060900.7z” in folder “E:\xxx\Backups\xxx_FileStore”
Error, as previously says it is 3 minute tmimeout:
ERROR: Destination error: This request operation sent to net.pipe://localhost/pranasnet/net/sbf/Trace/Net.pranasnet.sbf.Trace did not receive a reply within the configured timeout (00:03:00).
But we don’t have any 3 minute timeout in the config:
I would think this time it was our fault… if it wasn’t telling me about 00:03:00 timeout.
What are we doing wrong? Please help.
Hi Alexander,
just to confirm, we still have the same issues as before with the 3 minute timeout message. We too have changed all of the values in the xml file way past 3 minutes but are still getting the error message. It is always on the upload. This location is a local disk. Hope this information helps in resolving this issue.
Thanks in advance
