Support

Akeeba Backup for Joomla!

#38807 Backup throws error after moving to new server

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.2.9
PHP version
8.1.17
Akeeba Backup version
9.5.1

Latest post by nicholas on Friday, 31 March 2023 08:39 CDT

chaldama

On my own server Akeeba and the upload to Dropbox worked fine as always. Since this website was set live however, Akeeba keeps having problems so I presume there is a problem with a server setting somewhere. Hope you can point me in the right direction.

Log file

nicholas
Akeeba Staff
Manager

The error message says that Dropbox complains that the access token is expired. If this message appears three times in the log file before it becomes an error —like what happened here— it means that the link between your site and Dropbox has been lost, i.e. the Refresh Token stored for Dropbox has expired.

Please go to the configuration of your backup profile and click again on the Step 1 - Authenticate button under the Post-processing Engine section to relink your site with Dropbox.

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!

chaldama

Thank you Nicholas. In previous backups (if they succeeded) I already noticed that the archives were not uploaded tot Dropbox so I re-did the Dropbox authentication. Then it worked 2 times and now it doesn't even complete the backups anymore. 

nicholas
Akeeba Staff
Manager

Have you entered your Download ID in System, Update Sites, Akeeba Backup for Joomla? This is necessary for the re-authentication during the backup to work correctly (the Download ID is sent to our server as per the documentation).

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!

chaldama

Yes, the download ID has been added.

nicholas
Akeeba Staff
Manager

Something is really wrong with this server. The server is lying to us!

Look at the log entries between

DEBUG |20230330 06:35:29|====== Starting Step number 50 ======

and

DEBUG |20230330 06:35:46|====== Finished Step number 50 ======

If we were to believe what the server claims to have done, we uploaded 13 chunks of 20MiB each, or 260MiB in 16 seconds. That's 16.25 MiB / sec, or roughly 160Mbps.

I call BS on this since I see that the first time it tries to upload 20MiB it takes 5 seconds (which is a far more believable 4MiB/sec, or roughly 40Mbps, the typical maximum transfer rate we see on commercial hosts).

INFO |20230330 06:15:09|Starting immediate post-processing of part file site-www.historischekringbussum.nl-20230330-081256cest-lbrznDiO1NX6l3xi.j02
DEBUG |20230330 06:15:14|Akeeba\Engine\Postproc\Dropbox2::processPartChunked - Using chunked upload, part size 20971520

It beggars belief that the very first 20MiB chunk we try to upload transfers at 5 seconds and every subsequent chunk takes fractions of a second. Servers don't have a nitro boost button.

What actually happens is the the server is simply not sending our requests beyond the very first one to Dropbox at all. It simply caches the response from Dropbox (an HTTP/1.1 200 OK with no body) and returns it immediately to us every time we send a POST request with a new file chunk in the request body.

This is why when we tell Dropbox "Hey, I've uploaded all the chunks! You can now reconstruct the file." it basically replies with "Dude, are you drunk?! I have less data than you promised to send me!":

ERROR |20230330 06:35:46|Chunk upload finalization failed
DEBUG |20230330 06:35:46|[RuntimeException] <root>administrator/components/com_akeebabackup/engine/Postproc/Dropbox2.php(474) – #500 β€ΉChunk upload finalization failedβ€Ί

It also explains why you cannot get a new access token (as per the following):

ERROR |20230330 06:35:46|Error expired_access_token: No error description provided. Raw error: Array \n ( \n [.tag] => expired_access_token \n ) \n
DEBUG |20230330 06:35:46|[Akeeba\Engine\Postproc\Connector\Dropbox2\Exception\APIError] <root>administrator/components/com_akeebabackup/engine/Postproc/Connector/Dropbox2.php(982) – #500 β€ΉError expired_access_token: No error description provided. Raw error: Array \n ( \n [.tag] => expired_access_token \n ) \n β€Ί

At this point Akeeba Backup tried to send a GET request to our own server to help your server get a new access token. However, your server caught it, returned a previously cached request result (with a now expired token) hence the error about a missing token.

Please tell your host that we are aware that they have a misconfigured transparent proxy handling all outbound HTTP requests from your site (i.e. all requests made from code running on your server to access other servers). This is breaking the upload of files to Dropbox. As a result they need to fix their broken configuration and respect the HTTP standard regarding request caching. This means that PUT and POST requests must not be cached, nor should they cache requests which do not explicitly contain headers saying it's okay to cache them. Anything else is in violation of the RFCs which describe the HTTP 1.0 and 1.1 specifications, therefore their server is broken and they need to refund you the money you paid them.

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!

chaldama

Thank you Nicholas for sorting this out. I already thought it had something to with the server. I have informed the hosting company and will keep you posted. 

nicholas
Akeeba Staff
Manager

FWIW, a few months ago I was able to reproduce this exact behaviour by installing Squid Proxy and deliberately sabotaging its configuration. I can see how someone with a mild detachment from reality (e.g. an overzealous middle-manager, or a junior engineer who thinks bigger than they can grasp) would arrive to the sabotage state thinking they are saving their company money and their clients performance while doing the exact opposite. If the host kicks up the ticket up a level the network engineer will probably arrive at the same conclusion: yup, this transparent proxy is a great idea, just not configured exactly like it is now.

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!