Support

Akeeba Backup for Joomla!

#41329 Uploading the backup archive failed.

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
4 & 5
PHP version
8.1 and 8.3
Akeeba Backup version
9.9.109

Latest post by nicholas on Wednesday, 13 November 2024 02:40 CST

jamiefowlie

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 10MiB, please upload it on your server and post a link to it.

I saw that others were having a similar issue and in the solution the support talked about the size (2GB)of the file.

But I started having this problem recently with Microsoft ONEDRIVE on two different servers (CENTOS 7 with PNP 8.1 and ALMA LINUX with PHP8.3)

Here is what I found:

I was no longer able to upload any files through ONEDRIVE even if the Joomla file was on 62MB.

I tried to roll back to 9.9.6 same problem /uninstall and reinstall)

I have re inserted the OneDrive authentication key and refresh in all trials.

I have not been able to upload the file.

 

I then decided to switch to Google Drive.

The upload worked perfectly on the first attempt, putting in the new authentication keys,

 

So my deduction is that something is  no longer working with OneDrive option.

 

Hope that helps. Would be happy to run any additional tests for you if you have some ideas about what might be the problem.

nicholas
Akeeba Staff
Manager

Remember that you downgraded to a version that was working for you but it's no longer working for you. This is proof enough that whatever your problem is it is not related to our code, but something that recently changed in your hosting environment. If it was a change in our code, downgrading would've solved it.

Without a backup log file I can speculate all day about the nature of the problem, but I would just be stabbing in the dark. Maybe your host's PHP is linked against a libcurl which does not support TLSv1.2 which is now required by Microsoft. Maybe you have not entered your Download ID correctly, or at all, which means that anything you use that requires refreshing OAuth2 credentials will eventually fail once the initial access token expires. Maybe it's something else. That's why we always ask you to ZIP and attach the backup log file (the short message you left at the top of your issue). The log file will give us more context.

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!

jamiefowlie

Wow. I didn't think I was going to get that level of attitude to a response 

I didn't say I just downgraded. I ran the most recent version on both servers, the older one being one I have used successfully since 2016 and now suddenly doesn't work with OneDrive. I uninstalled the latest version and reinstalled an earlier version only to compare versions. 

I did submit a log through the email form and have no idea why you didn't get it. I definitely attached one. 

Sorry to have wasted your time.

nicholas
Akeeba Staff
Manager

Statements of fact and an offer to help you beyond what you have paid us to do are indeed an "attitude": a positive one. That's in stark contrast with your abrasive and toxic demeanour throughout this interaction.

In an IT context "upgrade" means installing a newer version than the one currently installed. Its antonym, "downgrade", means installing an older version than the one currently installed.

The fact remains that you did install the older version which was working for you in the past. In fact, you did so in a perfect way: completely uninstalling the newer version, forcing a clean installation of the last known good version. I am happy that you did that, because it proves the point. Even though you installed the last known good to you version, it no longer works. This is a data point: neither the old (9.9.6), nor the new (9.9.10) version work for you now when in the past the older version did.

Before replying to you I installed a new test site with Joomla! 4.4 on PHP 8.1. I installed Akeeba Backup 9.9.6 on it, configured OneDrive, and found that the upload works perfectly. I already have a test site with Joomla! 5.2 on PHP 8.3 with Akeeba Backup 9.9.10 on it, and a backup profile configured with OneDrive. I ran the backup on that site and found it to be working just fine. This is another data point: both the old (9.9.6) and the new (9.9.10) versions work perfectly fine on two different, known good server environments – if you wonder, one is a commercial Rochen server, the other is an Ubuntu Server I set up myself, and they are on completely different networks and hosting infrastructure (AWS and Linode respectively), thereby proving that I don't have a magical environment where everything works.

The combination of the two data points objectively means that the problem comes from something outside our code. This is either a server environment issue, or a hosting environment issue. I cannot know which one it is since they are completely outside our control and I have no information about them.

As I told you, I need the backup log file to help you. You insist you attached it, but it's nowhere to be found. Whether an attachment is present in a ticket or not is objective reality which does not leave room for subjective interpretation. This is a public ticket. Anyone can come to our site and check your posts for an attachment. The objective reality is that there is no attachment.

You claim to have used an "email form". I could assume that you mean the ticket submission form, but I'll take it one step further. The only kind of form on our site which could be even remotely described as an "email form" is our Contact Us form. All submissions to this form are logged into the database, in case email delivery fails. You have not submitted the Contact Us form either. This is also a statement of objective fact.

Therefore, the objective reality is that I do not have your log file. You can claim whatever you want, but the objective and independently verifiable fact remains that I DO NOT have your log file.

Telling me that statements of objective fact are an "attitude" is thoroughly unproductive. I need your log file to narrow down the root cause of your issue. As I very clearly stated in my previous reply, I do have several of the usual suspects in mind. The log file would help me deduce what is actually happening.

Side note: As per our Terms of Service, I am not obliged in any way to help you beyond stating that the problem has to do with your server environment since this was proven by none other than you. I am going beyond what I am supposed to help you with because I bloody care about our clients! If you call that an "attitude" then, by God, it is an attitude alright!

Will you send me the log file so I can help you?

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!

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!