Support

The error message says that Dropbox complains that the access token is expired. If this message appears three times in the log file before it becomes an error —like what happened here— it means that the link between your site and Dropbox has been lost, i.e. the Refresh Token stored for Dropbox has expired.

Please go to the configuration of your backup profile and click again on the Step 1 - Authenticate button under the Post-processing Engine section to relink your site with Dropbox.

Have you entered your Download ID in System, Update Sites, Akeeba Backup for Joomla? This is necessary for the re-authentication during the backup to work correctly (the Download ID is sent to our server as per the documentation).

Something is really wrong with this server. The server is lying to us!

Look at the log entries between

DEBUG |20230330 06:35:29|====== Starting Step number 50 ======

and

DEBUG |20230330 06:35:46|====== Finished Step number 50 ======

If we were to believe what the server claims to have done, we uploaded 13 chunks of 20MiB each, or 260MiB in 16 seconds. That's 16.25 MiB / sec, or roughly 160Mbps.

I call BS on this since I see that the first time it tries to upload 20MiB it takes 5 seconds (which is a far more believable 4MiB/sec, or roughly 40Mbps, the typical maximum transfer rate we see on commercial hosts).

INFO |20230330 06:15:09|Starting immediate post-processing of part file site-www.historischekringbussum.nl-20230330-081256cest-lbrznDiO1NX6l3xi.j02
DEBUG |20230330 06:15:14|Akeeba\Engine\Postproc\Dropbox2::processPartChunked - Using chunked upload, part size 20971520

It beggars belief that the very first 20MiB chunk we try to upload transfers at 5 seconds and every subsequent chunk takes fractions of a second. Servers don't have a nitro boost button.

What actually happens is the the server is simply not sending our requests beyond the very first one to Dropbox at all. It simply caches the response from Dropbox (an HTTP/1.1 200 OK with no body) and returns it immediately to us every time we send a POST request with a new file chunk in the request body.

This is why when we tell Dropbox "Hey, I've uploaded all the chunks! You can now reconstruct the file." it basically replies with "Dude, are you drunk?! I have less data than you promised to send me!":

ERROR |20230330 06:35:46|Chunk upload finalization failed
DEBUG |20230330 06:35:46|[RuntimeException] <root>administrator/components/com_akeebabackup/engine/Postproc/Dropbox2.php(474) – #500 β€ΉChunk upload finalization failedβ€Ί

It also explains why you cannot get a new access token (as per the following):

ERROR |20230330 06:35:46|Error expired_access_token: No error description provided. Raw error: Array \n ( \n [.tag] => expired_access_token \n ) \n
DEBUG |20230330 06:35:46|[Akeeba\Engine\Postproc\Connector\Dropbox2\Exception\APIError] <root>administrator/components/com_akeebabackup/engine/Postproc/Connector/Dropbox2.php(982) – #500 β€ΉError expired_access_token: No error description provided. Raw error: Array \n ( \n [.tag] => expired_access_token \n ) \n β€Ί

At this point Akeeba Backup tried to send a GET request to our own server to help your server get a new access token. However, your server caught it, returned a previously cached request result (with a now expired token) hence the error about a missing token.

Please tell your host that we are aware that they have a misconfigured transparent proxy handling all outbound HTTP requests from your site (i.e. all requests made from code running on your server to access other servers). This is breaking the upload of files to Dropbox. As a result they need to fix their broken configuration and respect the HTTP standard regarding request caching. This means that PUT and POST requests must not be cached, nor should they cache requests which do not explicitly contain headers saying it's okay to cache them. Anything else is in violation of the RFCs which describe the HTTP 1.0 and 1.1 specifications, therefore their server is broken and they need to refund you the money you paid them.

FWIW, a few months ago I was able to reproduce this exact behaviour by installing Squid Proxy and deliberately sabotaging its configuration. I can see how someone with a mild detachment from reality (e.g. an overzealous middle-manager, or a junior engineer who thinks bigger than they can grasp) would arrive to the sabotage state thinking they are saving their company money and their clients performance while doing the exact opposite. If the host kicks up the ticket up a level the network engineer will probably arrive at the same conclusion: yup, this transparent proxy is a great idea, just not configured exactly like it is now.