Support

Hello,

This is an automatic reply to a common question we detected in your ticket.

We have removed integration with the Dropbox v1 API because Dropbox itself announced it is deprecated and will be turned off by June 28th, 2017. We chose to remove support for the deprecated API now to make sure that all of our clients will be ready for Dropbox' deprecation next year. If you think that's an overkill please keep in mind that we added Dropbox v2 support in November 2015 with the documentation note that it's the recommended version and that the v1 API may stop working at any point.

Unfortunately, Dropbox' v1 and v2 APIs are very different and there is no way to have an automatic migration from v1 to v2. The access tokens used in the two API versions are and work different. This means that by upgrading to a new version of Akeeba Backup / Akeeba Solo your backup profiles which were using the deprecated Dropbox v1 API integration are no longer linked to a post-processing engine and produce errors.

Luckily there's a very simple process you have to follow once on every site and backup profile you want to (re)link to Dropbox.

THIS PROCESS ONLY NEEDS TO TAKE PLACE ONCE PER BACKUP PROFILE AND SITE.

• Go to your Akeeba Backup / Akeeba Solo main page.
• Select the backup profile you want to relink.
• Click on Configuration.
• In the Post-processing Engine dropdown select "Upload to Dropbox (v2 API)"
• Click on Configure next to it.
• Click on the "Authentication – Step 1" button.
• You may have to log in to Dropbox if you are not already logged in. Also, if you had not authorized another Akeeba Backup or Akeeba Solo installation to use Dropbox you may see a confirmation about it. If you are already logged in and have authorized our software to use Dropbox you will not see any of that.
• You then see a page with the big title "Dropbox Authentication is almost complete". Click on the blue "Complete Dropbox authentication" button below it.
• Now you're back to Akeeba Backup / Akeeba Solo. Click on Save & Close to complete the setup.

Unlike the Dropbox v1 API you must not copy the token from one profile / site to another. Instead, repeat the process above. Dropbox API v2 produces a new token every time you link a new backup profile or site to Dropbox without revoking the previous one.

Again, we apologize for having to go through this process but this is due to changes made on Dropbox' side. On the upside, the Dropbox API v2 is much more stable, allows for bigger uploads and lets us perform "chunk uploads", a technique which allows us to transfer very large backup archives without you having to set up small part sizes. You can now safely use a Part Size for Split Archives up to 2047 Mb without any upload worries.

If the instructions did not work for you please reply back to your ticket on our site, not by email, and let us know what you tried already (the more details you give the better). Also remember to ZIP and attach your backup log file if you have not already done so.

If I go into the Joomla back-end, and manually use the " Transfer Archive (dropbox2) " button, the .JPA file IS uploaded to Dropbox, but not deleted from the server.

The other parts, 'J01' '.J02' etc files are NOT uploaded.....

This means that the backup is NOT uploaded to Dropbox. Remember that the backup consists of all files (.jpa, .j01, .j02 etc). If any one of them is not uploaded Akeeba Backup considers the archive not transferred.

Based on what I see on your log file, the upload fails because of a server error. Namely, when we try to upload each part we receive an empty response with an HTTP 200 OK status. This is how Dropbox normally signals that the upload is correctly received. However, I see in the log that this result is returned in 0 seconds, i.e. there is no way anything was transferred. We have seen that before. It's broken caching implemented at the server by the host. Instead of sending our request to Dropbox they simply return an empty response. This is WRONG: a failed request must return an HTTP error status (in the 400 to 599 range), not 200 OK. So that's a host problem. Due to Dropbox' unfortunate API choice of signaling end of successful upload with an empty 200 OK response, from where we stand the wrong response returned by your host's cache is identical to success.

The only thing you can do is disable chunk uploads to Dropbox. Go to Components, Akeeba Backup and activate the backup profile that uploads to Dropbox. Click on Configuration. Find the Post-processing engine option and click on the Configure button next to it. Find the Enable chunk upload checkbox and uncheck (clear) it. Then click on Save & Close.

It should help, unless your host is really badly configured.

Please note that since you have disabled chunked uploads you are limiting the maximum size of parts which can be sent to Dropbox. If the upload fails please try setting a part size for split archives of 10Mb and increase in 10Mb increments to see what is the "sweet spot". You can change that by going to to Components, Akeeba Backup and activate the backup profile that uploads to Dropbox. Click on Configuration. Find the Archiver engine option and click on the Configure button next to it. Find the Part size for split archives option and set it to the desired value (all values measured in Mb). Then click on Save & Close.