Support

Akeeba Backup for Joomla!

#31899 Amazon S3 transfer Failing

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by on Friday, 22 November 2019 17:17 CST

jpcombeau
Hi, we have a configured database backup every hour, which is transferred to S3. It has worked without problem for several months, until today.

Error with SSL activated:
0 :: Akeeba\Engine\Postproc\Connector\S3v4\Connector::putObject(): [60] SSL: no alternative certificate subject name matches target host name 'hotelero.s3-us-west-2.amazonaws.com'

Error with SLL desactivated:
413 :: Unexpected HTTP status 413

I attach both logs.

Thanks.

nicholas
Akeeba Staff
Manager
While I cannot reproduce this issue I have an idea about what might be going on.

Go to the Configuration page of your backup profile and click the Configure button next to the Post-processing Engine. Set the "Bucket access" setting to "Path access (legacy)". If I recall correctly, your region (US West 2) doesn't work properly with Virtual Hosting bucket access for some buckets created before Amazon S3 started asking developer to use the Virtual Hosting access.

As for the HTTP 413 message, according to Amazon's documentation it cannot happen, meaning that it's not a documented HTTP status their REST API should ever return. It literally means Payload Too Large (the data sent to the server exceed its capacity to process information) which doesn't make sense in the context as you're trying to upload a file less than 5MB when the size limit for Amazon S3 is 5GB i.e. more than a thousand times bigger. I also see in your log that there's a subsequent 500 Internal Server Error from Amazon when we're trying to delete files. All these together make me thing that the problem may indeed be the "Bucket access" setting.

If you're wondering why this started happening now: Amazon S3 deprecated the "Path access" method for accessing bucket. As a result we changed our code to use virtual hosting bucket access by default, following Amazon's advice. I had already bumped into cases similar to yours in the past, hence the option in the configuration to keep using the legacy method that Amazon says we shouldn't be using (but requires us using for some older buckets -- go figure). It's one of those changes that you're damned if you do and damn if you don't, all because the third party vendor is exhibiting a behavior its documentation says it shouldn't be exhibiting. In other words yet another day in the life of an IT person...

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!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!