I installed on CentOS 7 Duplicati 2 (last canary - 18.104.22.168_canary_2019-11-05). After a few time I see that progress stopped and only after about 10-15 minutes I saw how new files appeared.
But after about 30-60 minutes I see error: “One or more errors occurred. (Could not find file “/tmp/dup-28004bc8-4ed6-4071-8aa0-44ee35e1c5ae” (Could not find file “/tmp/dup-28004bc8-4ed6-4071-8aa0-44ee35e1c5ae”) (One or more errors occurred. (Error getting response stream (ReadDoneAsync2): ReceiveFailure)))” and backup stopped.
There is some files after this backup. But in main window I see than I have never done backup.
I tried two times with same result. What is it and how I can fix it?
Following the only clue provided, the ReadDoneAsync2 looks like Duplicati asked mono to do a WebDAV operation, and Yandex sent nothing (zero bytes), or possibly closed the connection at:
To actually see if a connection closed at the network level is possible if you’re willing to capture packets with tcpdump, wireshark, tshark, or similar. Encryption gets in the way of doing a good higher-level look.
You can possibly get a Duplicati-level look by looking either at About --> Show log --> Live --> Retry or <backup name> --> Show log --> Remote and click on the downloads and uploads around time of error. Possibly you can find a multiple-line stack trace which would say more about where Duplicati was then.
So to confirm, you’re saying you see new files showing up at Yandex, viewed somehow separately from Duplicati, and at some point things stop working? What does the status bar say at the time of the error?
Have you used the “Test connection” button on the Destination screen a few times? Does it run reliably? This is generally just a directory listing, so it might work even if uploads or downloads are having issues. Does the <backup name> --> Verify files button work well? That’s similar to the verification after backup.
In looking over past Yandex reports, I see reports in 2017 and 2018 that it worked, but recently it hasn’t. How’s your experience been on other systems (if you run any)? You might also have a system problem.
At least some of the above look like Canary versions (and yours is). I wonder if older Beta would work, although it’s got a lot of other problems? If you can test 22.214.171.124 or 126.96.36.199 to Yandex it may be helpful.
For a real guess on Canary, you could also try reducing --asynchronous-concurrent-upload-limit to 1 in case somehow the default 4 concurrent uploads causes an issue. Beta doesn’t do concurrent uploads.
Thanks for the additional client testing (and there are lots of others to try). Does the issue seem file size dependent, meaning can you get even a small file to work? Duplicati.CommandLine.BackendTester.exe has --min-file-size and --max-file-size, or try chosen files with Duplicati.CommandLine.BackendTool.exe.
Some prior posts showed you had Windows. Do you still, and does it show the same problem? If so, Network Tracing in the .NET Framework might be a way to get more information, without encryption preventing a view of the activity as one might get with packet capture (without special workarounds). There are probably some forum or GitHub posts that provide specifics. But be careful what you post.
First question I wonder about is did Yandex respond but Duplicati didn’t notice, or did it not respond?
If you feel like seeing whether timing is involved, you can set –throttle-upload and –throttle-download (which the code confuses, so setting both helps) to a low value to see if you can make 1 MB files fail.
All of this might well lead into you filing an issue with as much as you can get, and hoping somebody familiar with WebDAV (and maybe willing to open a Yandex account) can make further progress on it.
Thank you. Yes, I use Windows on my PC, but want to use D2 on servers with CentOS.
I tried [–throttle-upload] and [–throttle-download] equal 1 Mb, but see the same error.
Now unfortunately I don’t have time to make the issue and do tests (. May be later. Now I use another solutions which upload via WebDav and same Yandex account. But this utility uses the original full backups of the site.
Hello! I found that the problem is in Yandex unofficially decide to fight with webdav due official client and new Rest API.
Even paid support doesn’t help with webdav. Only with official program. But they answered that official program use webdav too and there is no problem with webdav. But there are many messages in forums about this problem.
But I use a solution to backup sites via new Yandex Rest API and I see no problem. So the good idea too add support to new Rest API: REST API — Yandex Technologies . Additional profit is a feature to allow access only to special folder as in Dropbox, for example.
Thank you for big help. Now I’m sured what the problem is in Yandex WebDav(((.
Today I decided to use official client and backup to local disk drive (or network). Now HDD free space is not a problem)). But I hope that new REST API Yandex.Disk support will be added soon and I’ll donate for this feature as soon as I can). Because I like Yandex and it costs less that other services including Google.
New cloud storage - mail.ru is a similar feature request for supporting a different Russian cloud storage. That request linked to some projects that potentially could be used. If one for Yandex that looks reliable could be located, that might speed things up. Projects going unreliable underneath us is always a risk…
“soon” seems unlikely unless someone shows up to do it. There are a ton of bugs and feature requests. Main focus seems to be on reliability, and that’s been consuming pretty much all of the few volunteers…
Choosing sizes in Duplicati may help if performance suffers from small file transfers through rclone, which isn’t doing its usual thing but is started for each file operation. That restart might add a delay.
On the other hand, slower operations are probably better than what Yandex WebDAV is doing now.