Thank you for the log file. Unfortunately this is not a bug in Akeeba Backup. Your host has some kind of caching proxy in front of your server. This means that the responses to all requests being made from your server to the outside world (like when you try to upload a backup archive to Dropbox) are being cached. That's why in the log file you see that the upload to Dropbox takes no time at all and is considered successful. For example:
DEBUG |170104 02:05:17|Loading post-processing engine object (dropbox)
INFO |170104 02:05:17|Initializing post-processing engine
DEBUG |170104 02:05:17|11 files to process found
INFO |170104 02:05:17|Beginning post processing file <root>/administrator/components/com_akeeba/backup\site-(REDACTED)-20170104-020001.jpa
INFO |170104 02:05:17|Finished post-processing file <root>/administrator/components/com_akeeba/backup\site-(REDACTED)-20170104-020001.jpa
DEBUG |170104 02:05:17|Not removing processed file <root>/administrator/components/com_akeeba/backup\site-(REDACTED)-20170104-020001.jpa
DEBUG |170104 02:05:17|Akeeba\Engine\Core\Domain\Finalization::_run() Running built-in method run_post_processing
So the sequence of events is:
- Akeeba Backup tries to upload the last part (.jpa) to Dropbox.
- This usually succeeds, since it's the first request to Dropbox made from your server for a while. This means that your server DOES forward the request to Dropbox as it should
- Your server caches the HTTP 200 OK response from Dropbox and returns it to Akeeba Backup.
- Akeeba Backup marks that part as uploaded.
- Akeeba Backup tries to upload the next part (.j01) to Dropbox.
- Your server DOES NOT forward the request to Dropbox because it thinks it's a repetition of the previous upload we made just before.
- Your server returns the cached HTTP 200 OK response to Akeeba Backup.
- From Akeeba Backup's point of view the upload is successful because we got a 200 OK response. Therefore that part is considered successfully uploaded.
- The previous four steps are repeated for all subsequent parts.
From your point of view Akeeba Backup "didn't work" because you only see the last part (.jpa file) in your Dropbox. From Akeeba Backup's point of view the upload worked
because your server had been lying to Akeeba Backup instead of letting the upload go through.
That's all the help we can offer from our end.
You have to contact your host with this information and let them know that the caching they are using is causing major problems with uploading your backup archive. They should
exclude requests to the following URLs from caching for the uploads to Dropbox to work:
- https://api.dropboxapi.com/2/*
- https://content.dropboxapi.com/2/*
- https://www.akeebabackup.com/oauth2/*
Where * means "and all paths under this URL". The first two URLs are the official Dropbox v2 API endpoint URLs as they can read in https://www.dropbox.com/developers/documentation/http whereas the last URL is an OAuth2 "facilitator" endpoint which lets your site renew its connection tokens to Dropbox (our site holds the secret key you need to do that; we don't cache, store or otherwise manage the connection tokens ourselves).
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
