Akeeba Backup for Joomla!

Monday, 05 August 2013 15:08 CDT

jcc

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 2.5.14
PHP version: 5.3.3
MySQL version: 5.1.69
Host: RHEL6
Akeeba Backup version: 3.7.10

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

When restoring a backup with a second database configured, both the CMS and second database names, credentials are requested. These are used to restore the databases correctly, but the Akeeba profile used to create the backup, which has the name, credentials for the second database is not updated with the information supplied during the restore.

Edited by jcc on 2013-08-05 15:12 CDT

Monday, 05 August 2013 15:58 CDT

nicholas

This is the correct and expected behaviour. Akeeba Backup settings are stored in the CMS database encrypted. Even if the restoration was able to decrypt / re-encrypt these settings, it has no idea which backup profile it was taken with and how to match the new database credentials with the Akeeba Backup settings.

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!

Monday, 05 August 2013 16:14 CDT

jcc

I'm looking at the database and everything in the configuration column is encrypted, but secondary database information is in the filters column and NOT encrypted:

mysql> select id,filters from kpog_ak_profiles where id=1;
+----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | filters |
+----+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1 | a:2:{s:7:"multidb";a:1:{s:36:"...not sure what that is...";a:8:s:6:"driver";s:6:"mysqli";s:4:"host";s:9:"localhost";s:4:"port";s:0:"";s:8:"username";...continues on to include the username, password, database name.

At backup time you know the names of the databases...I thought it recorded the names of the databases for restore purposes (when restoring to the same site.)

Monday, 05 August 2013 16:32 CDT

nicholas

You're right, the filters are not encrypted. But let me give you this question.

Site A has three backup profiles #1, #2 and #3.
Profile #1 has one additional database.
Profile #2 has two additional databases.
Profile #3 has no additional database.

Site B has one backup profile, #1 with one additional database. Its backup profile is set up to back up Site A's files and database.

A backup is taken from Site B (which actually backs up site A). Corollary: there is no cat's chance in hell of knowing which of Site A's extra databases in each one of its profiles corresponds (or if it corresponds) to the extra database in Site B's #1 profile. As a result what you ask can't be implemented as it requires the kind of guesswork that only leads to unexpected behaviour.

So let me stress this again: what you observe is not a bug. It is the expected behaviour. I am not going to change this behaviour as it will introduce unexpected behaviour (bugs) in several occasions which are impossible to solve without reverting to the currently expected behaviour.

That said, Akeeba Backup has always been an Open Source project. If you have found a solution and write the code to implement it you are welcome to contribute it. It will then go through the same testing process all third party contributions go through and if found to introduce no unexpected behaviour it will be included in the next version of the component.

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!

Tuesday, 06 August 2013 09:09 CDT

jcc

I do see that you support complexity well beyond my (current) needs. It never really occurred to me that it might be beneficial to backup a different website's database, but I can see that it might be useful in some circumstances.

I will add verifying all of the backup profiles to my list of post-restore issues to correct manually.

Thanks.

Support