Support

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 10MiB, please upload it on your server and post a link to it.

Thank you for the log files. They corroborate your analysis and make us positive that the following reply is correct.

This is a bug in the 18 month old version of Akeeba Backup you are running, and we have already fixed it. It is not your host, not your Dropbox account, and not anything you have set up wrongly.

Here is what to do:

1. Update Akeeba Backup to version 10.3.7. You are currently on 10.0.2, which we released in February 2025. You can update from Joomla’s System → Update → Extensions page, or from the update notice inside Akeeba Backup itself. Your Joomla and PHP versions are both fine for it.
   
   ⚠️ You may have to update Joomla to 5.4 first. The version of Joomla you are using has been End of Support since October 2025. We only support the actively maintained versions of Joomla which, in the case of Joomla 5, is Joomla 5.4; it will be receiving support – at least for security fixes – until October 2027. If unsure whether you should do that, or how to do that, please do ask your site developer for help.
   
   
2. Reconnect Dropbox. After updating, go to backup profile #5, open its Configuration page, scroll to the “Upload to Dropbox” section, and click “Authentication – Step 1” once more. This is the same thing you did by hand last time; doing it on the new version makes it stick.
3. Let the next scheduled backup run as normal. It should now keep working, instead of failing on the run after next as it has been doing.

We are confident this is what you have been running into, though we cannot be completely certain until we see a successful run on the new version. If it fails again after the update, send us the new log and we will take another look.

Technical information

The rest of this is the detail behind the above. You do not need to read it — it is here for completeness, and in case you want to pass it to whoever prepared the analysis you sent us.

Your diagnosis was on the right track. Since 10.0.2 we have fixed three separate bugs in the way our software handles Dropbox (and Box, Google Drive, and OneDrive) authorisation tokens.

The one that matters most for you shipped in 10.3.6, listed in our changelog as “Box, Dropbox, Google Drive, OneDrive token refresh raced expiry”. In 10.0.2 the profile’s Dropbox access token is renewed at the start of the upload, but the renewed token is never written back into the backup profile. Every subsequent step of the backup therefore starts again from the token that had already expired, and the profile only ends up holding a working token as a side effect of a request having failed first. That is exactly the “the Refresh Token is not being used or persisted correctly for this profile” behaviour you suspected in your point 2, and it is why relinking Dropbox by hand fixes things for precisely one backup run and no longer.

10.3.7 fixed two further issues in the same area, including one we rated HIGH: a token renewal performed during an upload could write the new tokens into a different backup profile’s remote storage settings, leaving the profile actually being backed up with the stale ones. Whether that one affects you depends on how your scheduled backup is triggered, which is why we asked above.

Your point 1 — why it always fails at finalisation and never on the individual chunks — is a real characteristic of the code, and a good catch. In the chunked upload routine every Dropbox call except the last one is wrapped in a “if this fails, renew the token and try again” guard: creating the upload session retries, uploading each chunk retries. Closing the session (files/upload_session/finish) has no such guard — if it fails for any reason at all, the backup is aborted on the spot. So an expired token during the chunk uploads is absorbed silently and never becomes visible, while the very same expired token at the finalisation step takes the whole backup down. That is why both of your incidents look identical and land on the same call. We have raised this internally so that the finalisation step gets the same protection as the rest of the routine.

Your point 4 — no, we do not believe this has anything to do with LiteSpeed, or with host-side handling of outbound POST requests. The error in your log is Dropbox’s own expired_access_token response, which means the request did reach Dropbox and Dropbox rejected the credentials it was given. Your host appears to be in the clear; if it was a host-induced error this failure would've happened when uploading the first chunk of each backup archive part file, not during the chunked upload's finalization.

Your point 3 — understood, and nothing described above depends on having copied or duplicated a backup profile.