Support

Hello,

do you have more one than backup profile? Can you please attach the log of a backup process affected by this issue?

For what it's worth, I tried reproducing your issue and I may have an idea.

I had an account with a very old refresh token (I've been using it over the last few years). This one was the only one that failed to upload.

I then went into the Configuration page and clicked on the Step 1 – Authorisation button again. I copied over the new refresh token, and the backup now uploaded to OneDrive just fine.

In theory, and according to Microsoft's documentation, this should never happen. The refresh token is there to avoid exactly this situation. However, it wouldn't be the first time Microsoft decided to change the format of their tokens and silently broke older ones. I think that's what happened here.

If this doesn't help, ask your host if the libcurl the PHP cURL extension (NOT the curl executable itself!) is compiled against supports TLS 1.2. Another change Microsoft is rolling out at the moment is removing support for TLS 1.1 and 1.0 across Microsoft Azure. Since OneDrive technically runs on top of Microsoft Azure I would expect OneDrive to also be affected by this requirement. I couldn't reproduce this kind of issue on any of my development or live hosts; they all support TLS 1.2 since more than five years ago.

The Download ID is not stored in the component, it's stored in Joomla's Update Sites.

Go to System, Update, Update Sites and search for “Akeeba Backup”.

There should only be one item called “Akeeba Backup Professional for Joomla!” with the URL https://cdn.akeeba.com/updates/pkgakeebabackuppro.xml shown underneath it. It should have the Download ID shown below that. The Name column next to it should read “Akeeba Backup for Joomla! package”.

If this is not the case, please let us know and attach a screenshot of what you see instead.

The Download ID is actually stored in the #__update_sites table in the extra_query column. You will see that it's saved as dlid=YOUR_DOWNLOAD_ID. If it disappeared, it means that this update site record was removed and then added again.

One way I know of is when updating the software, there is a tiny chance that Joomla might screw up and remove the update site record. However, this happens very infrequently – based on anecdotal evidence, it appears to be less frequent than once every hundred thousand updates.

Another way this could happen is if you, another super user, or a third party extension removed the update site. When this happens and you go back to Components, Akeeba Backup our software catches that problem and installs the missing update site record. Of course, since there is no longer a record of your Download ID the reinstalled record is missing the Download ID.

The final way I know is when you use the Rebuild button in the Update Sites page. Since Joomla! 3.9 it's supposed to keep the Download ID (the contents of the extra_query column), but according to my experience it sometimes does not. I have only seen this twice myself and could not figure out the exact conditions, so I cannot rule that out either.

Basically, it's not something you need to be overly worried about. You would either need to do something deliberate, or be really unlucky for this to hit you. If it happens to you twice within a few months I'd say you ought to buy a lottery ticket.

You're welcome!

I relate to that, too. Yesterday morning I tried to uninstall an older version of PostgreSQL from my laptop so I can upgrade it. A freak failure occurred which trashed my installation to the point it was faster for me reinstalling the OS and restoring the configuration of various dev services and tools I use on it from a backup than try to fix what broke. It took 5 hours. The chance of that happening is nearly non-existent, but it did happen to me. Hm, maybe I should go buy a lottery ticket… :D