Support

The errors you get mean that your host is closing the FTP connection on you. This is not something we can "fix" because we are not your host. We can, however, tell you how to work around your host's problems. Do note that if you want me to explain in detail what is going wrong with your host I can, just ask me. I am skipping that bit since my priority is to tell you how to transfer your site as this seems to be what you are mostly interested in right now.

Extract the backup archive locally, using Akeeba eXtract Wizard.

Upload all of the extracted files to your host by FTP or SFTP. Do NOT upload Kickstart or your backup archive.

Visit the /installation/index.php URL on your new site. For example, if the new site is located in https://www.example.com you need to visit the URL https://www.example.com/installation/index.php This starts ANGIE, the restoration script.

Follow the on screen instructions to restore your site. Remember to enter the database connection information for the new server. The database and database user must be created before the restoration using your host's control panel. Don't forget to assign the database user to the database and give it full permissions to create tables!

In case the configuration.php file cannot be written to you will be told to replace its contents and given the new contents. If that happens please DO follow the instructions on your screen, otherwise the restored site will fail.

After the restoration is over it will tell you to delete the installation directory. Clicking the provided button may not work. In this case follow the instructions on your screen to delete the directory called "installation" before trying to visit your site. If you don't do that the restoration process will start all over again.

Don't panic. We're here to help. I know how frustrating restoring a site to a really bad quality host can be. More so when you do not have years of experience. I was in your shoes some fifteen years ago. Bear with me and I'll help you not only restore your site but understand why things are happening which will help you make more informed decisions about hosting in the future (trust me, this will save your sanity).

can't restore the database, getting error message "Unable to connect to the Database: Could not connect to MySQL."

You have either not created a database OR you are entering the wrong connection details when restoring the site. In fact, this is so common that I've written a step by step tourbelshooter. Typically your problem is either step 1 (which I talked about in my previous reply) or step 4 (because it's completely non-obvious in cPanel and Plesk - I have been frustrated by this myself when I started building sites fifteen years ago and their interface has not improved at all since then!).

Before doing that, there's a small chance that it's related to your previous issue. Since you're uploading all files by FTP their ownership may prevent the web server from writing to them. This is something we extensively explain in the How your web server works chapter of our documentation. That, compounded with a host that has an invalid session save path set up in their server's php.ini, would make the restoration script unable to "remember" the settings you entered and unable to detect that it cannot "remember" them either (because the host would be lying about the PHP session working). To cut a long story short, give the installation/tmp folder 0777 permissions.

Please note that if changing the installation/tmp folder permissions worked for you there's a good chance that your restored site will NOT work unless you give 0777 permissions to the directories tmp, cache, administrator/cache and administrator/logs (Joomla's temporary, cache and log folders). This is NOT something related to our software, it's something related to a very low quality shared host. To be precise, it's an indication of a host using PHP as an Apache module instead of FastCGI. If that's the case I strongly recommend switching to a better host for security reasons. Using PHP as an Apache module (mod_php) makes the server vulnerable: one hacked site has read access to every other site on the server, allowing a hacker who knows what he's doing to bypass your defenses and hack your site even though you've done nothing wrong on your site.

I remain for your questions.

In the last step (Site Setup) please uncheck the box "Replace main .htaccess file with default". This will let the restoration continue.

Please note that when you get this error message it means that your server doesn't support either method Joomla can use to download files (cURL or URL fopen wrappers). It is very likely that the restored site will NOT work properly. Namely, the following Joomla! features will not work:

• Joomla! Update: being notified about update availability, downloading / installing updates
• Extension updates: being notified about update availability, downloading / installing updates
• The news feeds component
• Joomla anonymous statistics collection

Likewise, any Akeeba Backup feature requiring access to remote servers, i.e. transferring the backup to any kind of remote storage, will not work.

The same applies for third party extensions which require access to remote content.

After restoration I'd recommend that you contact your host and request that the PHP cURL module is installed and enabled on the server. It's 2017, there's no reason to not have the PHP cURL module enabled.

Sure. In no particular order: SiteGround, Rochen, CloudAccess.net and EuroVPS. I currently have sites with the first two.