Support

If you are restoring to exactly the same location (subdomain, domain and directory) you don't have to re-enter this information, it is filled in automatically. If you are restoring to a new location these fields are empty. This has been the case for the last five and a half years.

Furthermore, if you go to Configuration, Database backup engine, Configure and check "Blank out username/password" you will always have to enter your database connection information when restoring. This has been the case since approximately 2 years ago.

Just to be perfectly sure I just did a test. I took a backup and used the integrated restoration (which merely extracts the backup in place) to restore it. Sure enough, I can see the database information filled in. Therefore the feature –that I have not touched since 2013 as I can see in the Got repository– works exactly as I described.

This leaves us with very few possibilities.

Are you restoring EXACTLY over the same site? Please note that if you were backing up a site at http://www.example.com restoring to the following locations will NOT preserve the db information:

• https://www.example.com (different protocol)
• http://www.example.net (different domain name)
• http://foo.example.com (different subdomain)
• http://www.example.com/something (different directory)

If you go to Options and change something, does the change stick? If not, you have a Joomla issue with the #__extensions table I cannot help you with.

Try disabling caching in Joomla's Global Configuration, go to Components, Akeeba Backup click on Configuration, save & close. This should refresh the saved URL of the site.

Are you accessing your site's backend using EXACTLY the same subdomain and path? For example, if your site's URL is http://www.example.com, accessing your back-end using one of the following URLs will NOT preserve the db information:

• https://www.example.com (different protocol)
• http://www.example.net (different domain name)
• http://example.com (different subdomain – note the missing www!)
• https://www.sharedssl.foo/yoursite (shared SSL: different protocol, domain and path!)

Likewise, does your webcron.org CRON URL match the protocol, domain name, subdomain and path of your site?

Finally, a minority of servers (about one in a hundred) will not report the current site's URL correctly to PHP. In these cases the restoration script cannot figure out if you are restoring on the same or a different site. According to our experience the safest bet is that someone in this situation is restoring to a different site and for this reason we blank out the database connection information.

This is an exhaustive list.