Support

I have not seen any issues and I just completed a backup to Dropbox.

First, try doing the authentication again for each failing backup profile.

If this doesn't help, we will need a backup log file. I have a suspicion that your server has a firewall for outgoing connections and your host would need to allow connections to Dropbox. Do note that hosts do not announce which additional security measures they implement and when, or even to which servers in their fleet. This is why you might experience things "suddenly" not working or working inconsistently across different sites on the same hosting provider.

Please note that all attachments are private, even on public tickets. You don't have to file a private ticket.

It does look like the problem might be a proxy server for outbound connections on your host. I see that the first request to create a new upload session goes through to Dropbox. The second request to actually upload the data seems to hang waiting for a network response until the server gives up (that's the 502 error reported).

This is consistent with the experience other clients of ours have had on Strato, insofar as inconsistency of server setup and occasionally encountering server proxies which effectively kill PUT requests can be called consistent.

What most likely happens is that their proxy "eats" the body (the chunk of binary file data) of the PUT request we send to Dropbox. Dropbox patiently waits for this data to arrive, leading to an impasse: your server sends nothing, Dropbox waits and sends nothing. At some point your web server decides that it has been waiting long enough and kills the PHP execution with a 502 error.

You need to ask your host to look into it and reconfigure their proxy to allow PUT requests to go through correctly.

I understand :) The first time you get two servers on the same host yielding radically different results it's unnerving. What usually happens is that servers may belong to different "generations" of configuration or a server might be in a server group which has exhibited an increased rate of problems for the host (getting its IP blacklisted by spam filters, they received too many abuse reports etc) which might justify stricter measures across all sites hosted on it. Sometimes servers may be part of a group that undergoes a trial of new features / configuration options the host intends to apply. And so on and so forth. When in doubt, ask the host. You may get an evasive reply but they'll do their best to address the situation.

We use the official Dropbox API v2. It uses two different URLs, both using H.

https://api.dropboxapi.com/2/ is used to communicate commands and https://content.dropboxapi.com/2 is used to upload data.

There are two way to upload to Dropbox. One is straight up upload the entire file, the other one is chunked upload. I did check chunked upload before sending you my first reply.

In the straight up uploads things are straightforward. We make a single POST request to the content URL. However, since you're trying to upload a lot of data it might take too long and either PHP or your web server times out. Hence the chunked mode.

In the chunked upload each archive part is uploaded in smaller chunks. Each chunk is as big as the chunk size except for the last chunk which is the remained. So, if you want to upload a 93.4MB file with a 10MB chunk you have ten chunks: nine chunks at 10MB each and a final chunk of 3.4MB. We can pause the upload after each chunk and do a new page load, sidestepping the timeout issue as long as uploading each chunk takes less time than your PHP and web server timeout limit.

For chunked uploads we need to do n+2 requests to Dropbox. First a POST request to the api URL to get a chunked upload key, Then n POST requests (where n is the number of chunks) to the content URL to upload each chunk. Finally a POST request to the api URL to tell Dropbox we're done uploading.

Dropbox uses time limited OAuth2 access tokens for authentication. These last for one hour. When you are linking Akeeba Backup to Dropbox you get a pair of tokens, an access token which expires in one hour and a refresh token which does not expire. If a request fails, Akeeba Backup exchanges the refresh token for a new access token. Since this requires signing with our secret key we cannot distribute with our software this happens through a mediator service on our site. The mediator service requires you to have entered a valid Download ID in the component's options. The Download ID must correspond to a user account on our site with an active subscription which gives access to any of our backup products: AKEEBABACKUP, ESSENTIALS, BACKUPWP, WPESSENTIALS or SOLOPHP.

Your test probably failed for one of two reasons. You either didn't enter a Download ID or the chunk size was too big for the server.

However, that test is not the same problem I see in your real site's log file. What I see there tells me that the token exchange works perfectly fine. The first POST request to the api URL (which is of course authenticated!) works and we do get an upload session ID. The second POST request, to the content URL, seems to never complete. Even if you're using a chunk size of 20MB, at 250 seconds we'd be talking about a transfer rate of under 82 Kb/sec. This is WAY too low to be true, unless your server is on a PSTN dial-up connection. Since the calendar reads 2021, not 1991, I think that's more than unlikely. What is more likely and we have seen before is what I told you: there is a firewall or proxy on the server which "eats up" the POST request to the content URL so that it never returns.

You really need to contact your host and tell them that your site will be uploading stuff to Dropbox therefore requests whose URL begins with the two URLs I shared above must go through and they must be uncached (the HTTP protocol already specifies POST requests must go through uncached but I've seen plenty of hosts doing things they should not be doing, so yeah...).

It must have been a problem with their proxy server, as we suspected :)