I got to restore, fill out the information and hit connect. It stays on listing backup dates before failing with Failed to connect: Gateway Time-out
How are you doing a restore? By saying you “fill out the information”, are you doing “direct restore from backup files”?
direct restore from backup files, yes. I’m restoring using SFTP. Fill out information is just the SFTP information and the connection works fine when I test that connection.
Oh, and both the backup location server and the main server are using ubuntu
Do you recall roughly how long it sat before the error?
Does the error look like a typical Duplicati-generated error, with a box made with the error?
Alternatively, it might look kind of raw, meaning not something nicely formatted by Duplicati.
Is the browser URL to Duplicati direct, e.g. localhost:8200 (etc.) or via networking gear?
If through networking gear, is there a reverse proxy, or something that might call a timeout?
Using a direct connection and throttling, I got a slow listing (40 minutes), but didn’t time out.
I had another tab in About → Show log → Live → Information watching dlist files download.
I also started a Wireshark capture while it was working. It caught the backup list response,
however it did not capture the request, which makes me think HTTP view was a slow reply.
Is this a test, or did you lose a system? How much are you trying to restore? Most recent?
The RESTORE command done in CLI would bypass web issues but is harder to set up…
It sits for a few minutes. It looks like a normal error with a box. The domain is pointed to it using nginx. I don’t see anything in the information bit in logs.
This isn’t a test, it’s a small issue but I can look at that restore command.
exit 127 when running the restore cmd
The gateway timeout is likely from nginx. You can either try to find a way to not use nginx for Duplicati, or reduce the number of kept backups to a number that can be read before nginx timeout, or raise timeout.
Search finds there are lots of articles on the latter, such as How to Increase Request Timeout in NGINX.
There might be some other workarounds, e.g. one can recreate (by The REPAIR command) a database with a specific version (0 would be the latest), and possibly that wouldn’t get a web timeout. You can test. Doing it this way is a little more dangerous if the original system still exists, as you never want a backup running from two different source systems into the same destination folder. They will confuse each other.
EDIT:
What is this referring to? If you open a new tab to About → Show log → Information before trying the direct restore, you should be able to see it downloading dlist files one by one. It needs all before it can send the response that lists them in the restore dropdown. In your case, it might have still been listing at the timeout.
By the way, if you use F12 developer tools, the request that gets the slow response with the version info is:
http://localhost:8200/api/v1/backup/<GUID>/filesets
without my artificial throttle, my backup gives a response in 29 seconds instead of the 40 minutes throttled.
I don’t use nginx, but possibly you can customize the longer timeout around the requests that are too slow.
I changed the timeout amount and now I get Failed to connect: Internal Server Error
It goes to listing backup dates than this, any ideas?
Same question – how long, and did dlist file analysis finish before that or was error during downloads?
Do you know how to look at requests and responses with browser web developer tools, commonly F12?
It would be useful to know how far things got. On a similar note, the nginx error log might have some info.
/var/log/nginx/error.log is said to be the standard spot, but it can be moved. Note I don’t run nginx.
How to Fix 500 Internal Server Error in NGINX has some other ideas. Google finds a huge number of hits.
Although I’m not quite sure how nginx fits into the below (is this on Apapche?), the only previous report is:
The below are some people trying to reverse proxy Duplicati. You can see configurations and the issues.
Support reverse proxying the WebUI #1932
EDIT:
These are the requests I got starting from Connect, and stopping when it moves off Listing backup dates:
You can see the slow filesets. This is from Edge (Chromium-based), but most browsers have similar.