Support

Are you uploading to Amazon S3 proper or to a different, third party service? There is a very big difference there, that's why I am asking.

This is a known issue. Try using the latest dev release: Akeeba Backup for Joomla 4 & 5 Professional (dev release). Let me know if that addresses your problem. Strato is one of the third party services I don't have direct access to test with. Based on their wording in the message about accepting RFC1123Z timestamps I believe the dev release should work. I would very much prefer a “for real” test from someone like you to be extra sure before making a new release.

Apologies, I linked you to the wrong file. The correct one is Version 9.8.0-dev202309200547-revdb82d3d.

Please remember that you should not try to uninstall Akeeba Backup. Uninstalling removes the entire component, including its configuration and backup records.

First I installed the version that you linked with the error message that I pasted here.

Then I installed the previous version again and my configuration was lost.

Ah, now I understood the sequence of events.

Yes, in this case you would indeed lose the configuration because in Akeeba Backup 9.8 we have changed the way the backup engine is included in the component and, as a direct result, we moved the file holding the encryption key for the encrypted settings to a different folder. This happens automatically when you update from Akeeba Backup 9.0–9.7 to 9.8 and later. If you try to downgrade the file is not moved back since we did not know about this change when we released Akeeba Backup 9.0–9.7, therefore we could not have added code to anticipate this.

In general, downgrades cause problems. That's why I had enabled Joomla's feature which prevents downgrades in Akeeba Backup 9.7. Unfortunately, I had to roll this back because the way this feature is implemented in Joomla is useless in practice: if you have a dev release you cannot install a newer dev release in the same version range, or roll back to the previous stable version. I could foresee a huge problem doing support, therefore I had to once again disable this feature.

Is there an easy way to get the configuration back from last night's Akeeba Backup?

The best way is, as you intuited, to restore the backup to a test server, export the configuration, and then import on your real site. All other methods can be more or less problematic.

There are pros and cons to the validation. The biggest issue is that we'd need the validation in triplicate. Once in the backup engine, where it already is. Once again in the backend when we save the configuration. And yet once more in JavaScript on the configuration page itself so we can show you what is invalid. This quickly gets out of hand and out of sync, even more so considering the fact that the backup engine is used in another two backup products (or three, if you count Akeeba Backup for Joomla 3) and that there are two programming languages involved with different regular expression libraries which work ever so slightly different.

Ultimately, people have only had this issue a handful of times the last 14 years. Adding complexity would cause far more trouble for far more people in much less time: unnecessary complexity breeds trouble. That's why I have decided against validation in the Configuration page.

Well, it is better than having the entire component being broken every few months because one of the three validation checks in one of the dozens of options inevitably got out of sync with the other two.  One is a minor annoyance, the other one destroys trust in the software and leads to the business dying.

Keep in mind that there's really no practical way to test all three validations with the practically infinite number of configurations across hundreds of third party services, most of which we have never heard of. Having something continuously breaking because the test space is unknown and too diverse to fully test sounds like a stupid way to make software, if you ask me.

Also remember that no amount of client- or server-side validation can possibly be as accurate as trying an upload for real. And no, saving the Configuration must not try to make an upload for several reasons including performance, the fact that there are write-only destinations we can't pollute with test uploads etc.

Besides, if you get the configuration wrong you only have to take one backup, which you'd do anyway. Then you go back to Configuration, change your configuration, go to Manage Backups, and click on Upload To S3 next to the record which failed to upload earlier. This only retries the upload. This has been the case since February 2010 when I first introduced the remote storage feature in Akeeba Backup 3.0.