Support

Akeeba Backup for Joomla!

#28713 Backup fail with DirectFTP

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 Sunday, 10 December 2017 17:17 CST

carloxp
Description of my issue:

Good morning

Backup fails when set to DirectFTP.
Normal backup (jpa) work.
Environment is cPanel 68.0.10 (CL).
I also attached php.ini.

This was a commonly used procedure for me (DirectFTP) but with Joomla <3.4. Now I tried with last versions of both Joomla and Akeeba.

Thank you

nicholas
Akeeba Staff
Manager
The FTP connection was denied by the remote server. Not much you can do about it, I'm afraid.

Due to the way PHP handles FTP uploads we need to create a new FTP connection to the remote server for each file being uploaded there by the DirectFTP engine. Once the upload is complete the connection is closed. This is repeated for every file being backed up.

Many FTP servers have a limit on the number of connections any given IP or user can have in a period of time. If you exceed that limit they start refusing connections. This makes sense, since starting an FTP connection is actually quite resource intensive. This is also why uploading lots of small files by FTP (like DirectFTP does) is painfully slow.

A better approach is to back up to a JPA, JPS or ZIP file with a part size for split archives around 5 to 10M. Use the Upload to FTP post-processing engine with the "upload files immediately" option to upload each generated archive part as soon as it's ready. This results in far fewer uploads of much bigger files which is better for backup performance (faster backups) and unlikely to result in the FTP uploads being blocked. You can also use the "upload kickstart" feature found in the Configuration page to also upload kickstart.php to the target site which allows you to extract the backup really fast.

Alternatively, take a regular JPA backup and use the Site Transfer Wizard to upload it to the remote server. It essentially does the same thing with a small twist: it will only use FTP to upload a special version of "unattended Kickstart". Then it will use this "unattended Kickstart" to upload the backup archive in 1M chunks over regular HTTP/HTTPS (therefore sidestepping the FTP upload limits) and automatically extract the backup on the target server. All you have to do is go through the restoration script's (ANGIE) steps to restore the site on the remote server.

I hope this information helps!

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!

carloxp
Hello Nicholas and thank you for replying!

I'm sorry, but I need provide some additional information.

- I used DirectFTP for years, literally years, as my unique method to clone a website without a single issue
- I always used DirectFTP to clone websites from public_html to a subdomain or from subdomain to subdomain. This is my own way to work!
- I own my server. i.e.: I have full root control of the server: I'm in hosting at myself.
- The FTP transfer DirectFTP is and always has been website->localhost. i.e.: between directories on same server and same account.
- Never had a single issue with Joomla+Akeeba. I paused Joomla development for +1 year and yesterday restarted Joomla development with a fresh environment J3.8.2/Akeeba5.6.0
- I'm trying to DirectFTP on a fresh installed website, means that is almost totally empty
- I tried to tune some PHP settings (timeout, memory, etc.)... my opinion is that something is wrong here (PHP setting) but I don't know what.

So, I don't understand what is changed in the combination Joomla+Akeeba in last year, because the server is always the same (excluding that the server now run with EasyApache4).

Maybe with these additional information is more easy give a further small suggestion :-)

Cheers,
Carlo



nicholas
Akeeba Staff
Manager
I can tell you what has NOT changed: the DirectFTP engine which has not been touched in years :) Also, since you are managing your own server you should have the knowledge required to look at the necessary logs on the server under your absolute control and see what the server under your absolute control that you have set up and you are managing has started denying the FTP connections at some point. Based on your log file, as I already told you, we see that it's your FTP server which is blocking the connection after a while (we've already uploaded several dozen files since we're well past uploading the installation folder and into the backup of the rest of the site). So, no connection problem on the side of the backup software.

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!

carloxp
Hi Nicholas
Ok, now is much more clear.
Yes, you are right, I missed to analyze in depth what happened on server-side. This why I assumed that something changed in PHP configuration only, making my current PHP configuration no longer compatible.
Thank you very much for the assistance.
Cheers,
Carlo

nicholas
Akeeba Staff
Manager
No problem :) I'll leave this ticket open in case you need me to help you on something.

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!