Support

I take exception at the tone and content of your message. It is very provocative and does not reflect objective reality.

I will not dignify the baseless accusations and arbitrary conclusions about Solo with a response. I will simply stick to a few key facts and the log file you provided.

First of all, Akeeba Backup runs inside Joomla, unlike Akeeba Solo. As a result it doesn't need to be configured with the connection details of your main Joomla site database. Joomla's Global Configuration is loaded when Joomla loads up and made available through the Joomla global configuration object, accessible to all extensions through JFactory::getConfig(). Moreover, Joomla's database connection object is available to all extensions through JFactory::getDbo(). This is what we're using in Akeeba Backup. Therefore the Configuration Wizard does not need to retrieve or store that information anywhere.

Please note that the configuration page includes a "Site Overrides" and it's documented as such. This is only meant to be used when you need to override Joomla's default database connection options e.g. when backing up a different site than the one Akeeba Backup is running in or in some exotic cases where you have a database cluster and would like to use the Master server for backups instead of the Slaves. This is not your use case, you do not need that section and it's normal that it's empty.

In your log file I see that you are using the Multiple Databases Definitions feature. As documented, these are meant to include additional databases to the backup archive beyond the one Joomla is currently configured to use (the main site database). This feature is necessary because of the fact that Joomla can only be configured to use ONE set of database connection information. It does not provide any way to define additional database connections, therefore it's impossible for any extension – including Akeeba Backup – to automatically determine which additional database connections are used or what their connection settings are. By the very nature of what you are putting in there it has to be entered manually – as I said, this is information that can NOT be retrieved automatically. It's your responsibility to provide accurate information there. We do provide a button to test this connection information while setting it up.

Speaking of which, shall we take a look at your provocatively named "cannotbelievethishashappenedoutofthebox.zip" log file?

DEBUG   |200416 00:15:39|====== Starting Step number 6 ======
DEBUG   |200416 00:15:39|Kettenrad :: Ticking the domain object
DEBUG   |200416 00:15:39|Akeeba\Engine\Core\Domain\Db :: Iterating next database
DEBUG   |200416 00:15:39|Akeeba\Engine\Dump\Native :: New instance
DEBUG   |200416 00:15:39|Akeeba\Engine\Core\Domain\Db :: Now backing up 70A44104-BB19-4EA2-82B5-BD26DF03F761 (auler_kto)
DEBUG   |200416 00:15:39|Akeeba\Engine\Dump\Native :: Processing parameters
DEBUG   |200416 00:15:39|Kettenrad :: Domain object returned with errors; propagating
ERROR   |200416 00:15:39|Akeeba\Engine\Dump\Native :: Database Error: Could not connect to MySQL
DEBUG   |200416 00:15:39|[RuntimeException] <root>administrator/components/com_akeeba/BackupEngine/Dump/Native.php(82) – #0 ‹Akeeba\Engine\Dump\Native :: Database Error: Could not connect to MySQL›
DEBUG   |200416 00:15:39|#0 <root>administrator/components/com_akeeba/BackupEngine/Base/Part.php(211): Akeeba\Engine\Dump\Native->_prepare()
DEBUG   |200416 00:15:39|#1 <root>administrator/components/com_akeeba/BackupEngine/Core/Domain/Db.php(159): Akeeba\Engine\Base\Part->tick()
DEBUG   |200416 00:15:39|#2 <root>administrator/components/com_akeeba/BackupEngine/Base/Part.php(216): Akeeba\Engine\Core\Domain\Db->_run()
DEBUG   |200416 00:15:39|#3 <root>administrator/components/com_akeeba/BackupEngine/Core/Kettenrad.php(531): Akeeba\Engine\Base\Part->tick()
DEBUG   |200416 00:15:39|#4 <root>administrator/components/com_akeeba/BackupEngine/Base/Part.php(216): Akeeba\Engine\Core\Kettenrad->_run()
DEBUG   |200416 00:15:39|#5 <root>administrator/components/com_akeeba/BackupEngine/Core/Kettenrad.php(185): Akeeba\Engine\Base\Part->tick(0)
DEBUG   |200416 00:15:39|#6 <root>administrator/components/com_akeeba/Model/Backup.php(360): Akeeba\Engine\Core\Kettenrad->tick()
DEBUG   |200416 00:15:39|#7 <root>administrator/components/com_akeeba/Model/Backup.php(56): Akeeba\Backup\Admin\Model\Backup->stepBackup()
DEBUG   |200416 00:15:39|#8 <root>administrator/components/com_akeeba/Controller/Backup.php(133): Akeeba\Backup\Admin\Model\Backup->runBackup()
DEBUG   |200416 00:15:39|#9 <root>libraries/fof30/Controller/Controller.php(420): Akeeba\Backup\Admin\Controller\Backup->ajax()
DEBUG   |200416 00:15:39|#10 <root>administrator/components/com_akeeba/Controller/Mixin/PredefinedTaskList.php(41): FOF30\Controller\Controller->execute('ajax')
DEBUG   |200416 00:15:39|#11 <root>libraries/fof30/Dispatcher/Dispatcher.php(175): Akeeba\Backup\Admin\Controller\Backup->execute('ajax')
DEBUG   |200416 00:15:39|#12 <root>administrator/components/com_akeeba/akeeba.php(64): FOF30\Dispatcher\Dispatcher->dispatch()
DEBUG   |200416 00:15:39|#13 <root>administrator/components/com_akeeba/akeeba.php(94): mainLoopAkeebaBackupForJoomla()
DEBUG   |200416 00:15:39|#14 <root>libraries/src/Component/ComponentHelper.php(402): require_once('/home/auleres/n...')
DEBUG   |200416 00:15:39|#15 <root>libraries/src/Component/ComponentHelper.php(377): Joomla\CMS\Component\ComponentHelper::executeComponent('/home/auleres/n...')
DEBUG   |200416 00:15:39|#16 <root>libraries/src/Application/AdministratorApplication.php(101): Joomla\CMS\Component\ComponentHelper::renderComponent('com_akeeba')
DEBUG   |200416 00:15:39|#17 <root>libraries/src/Application/AdministratorApplication.php(159): Joomla\CMS\Application\AdministratorApplication->dispatch()
DEBUG   |200416 00:15:39|#18 <root>libraries/src/Application/CMSApplication.php(196): Joomla\CMS\Application\AdministratorApplication->doExecute()
DEBUG   |200416 00:15:39|#19 <root>administrator/index.php(51): Joomla\CMS\Application\CMSApplication->execute()
DEBUG   |200416 00:15:39|#20 {main}

According to this log file the backup fails when it's trying to connect to the database “auler_kto”. However, this is database connection information that you have entered yourself in the Multiple Databases Definitions page. The backup fails because the information you entered is wrong, or at least PHP's MySQL connector cannot establish a connection to that database. I'm afraid that this is NOT something that happens "out of the box" since as I made clear above this is information you have to enter yourself. It is your responsibility to enter accurate information there and test it. If the information is wrong the backup will fail and rightly so. Continuing the backup despite the fact that a database cannot be connected to and backed up would be a massive bug; the backup in this case would not be complete. Backups fail when it's not possible for them to be complete representations of what you configured should be included.

Regarding the configuration wizard behavior, I'd like to point out that you are complaining that the Configuration Wizard is doing what it's meant to do, per its documentation. As you can read on the top of that page, the Configuration Wizard has the following immediate effects:

• Your backup type is switched to "Full site backup".
• The archiver engine is switched to "JPA (Recommended)".
• Post processing options are reset to "None" i.e. your backup will not be uploaded to a remote storage location.

So telling me that you're surprised that using the Configuration Wizard re-selected JPA as the archiver engine doesn't make sense. It looks like you're mistaken.

Furthermore, I do take exception at your insistence that the the JPA format is "faulty". The JPA format has existed since 2007; that's 13 years. Are you seriously implying that I am maintaining a faulty feature and using it as a default for 13 years? Moreover, the JPA format is really a subset of the ZIP file format, supporting only those features that can be safely supported on a generic web server and which are relevant for a backup – as I've written in its documentation. The ZIP format, on the other hand, requires CRC32 checksums which can fail for large files (due to memory or time restrictions on the server) and a Central Directory the generation of which can fail because of the same memory or time constraints on the server. I've actually documented all those problems with ZIP files.

If your JPA backup archive is broken the problem is somewhere along your server killing the backup prematurely or your download being corrupt for reasons that have to do with the server configuration and the way you are downloading the backup archive. However, these problems would also exist with the ZIP format. In any case, we can help with these problems if asked – not to mention I've already documented everything in the User's Guide and the troubleshooting documentation.

I would appreciate it if you refrained from using this kind of provocative tone and content in your future communications to us. This kind of behavior does not help us help you, especially when the problem is self-inflicted.

I am closing your ticket because we've told you in numerous occasions to check your Multiple Database Definitions. This is a recurring issue for you but it's one that is self-inflicted. We really can't do much more than providing you with the tools to check that configuration (it's already in the Multiple Databases Definitions page when you set up or edit a definition) or tell you that you really need to provide correct configuration. I am afraid that at this point we will have to refrain from answering any more tickets bearing the same provocative tone or concerning the same issue we've helped you with on numerous occasions but you insist on not following our advice. Thank you and have a nice day.