Support

This doesn't make any sense at all.

Your use of the term "prefix" is ambiguous. It can either refer to the database table naming prefix ($prefix in configuration.php) or the prefix in the name of your database name or database username.

When restoring a backup archive taken with Akeeba Backup you need to enter and confirm the database connection information i.e. database server hostname, database name, database username, password and database table name prefix. The restoration script (ANGIE) can only and will only use the information that YOU have explicitly provided in its interface. Period.

As for the Akeeba Backup component itself, it uses Joomla's database API. It CAN NOT and WILL NOT change any of your database connection information i.e. database server hostname, database name, database username, password and database table name prefix. These are part of Joomla's configuration.

So, either you messed up when restoring sites or your host is lying to you. In the latter case please give me the name of your host so I can add them to my list of bad hosts to avoid at all cost.

This still doesn't make sense to me.

I need you to clarify what you mean by "prefix" because it can mean two completely different things.

A. Database TABLE NAMING prefix. This is the $prefix property in the configuration.php file of Joomla. For example, if $prefix = 'foo_' then you have a table named foo_users in your database.

Having your host complain about it makes no sense. Yes, if you restore a site you CAN change the table naming prefix. If you are restoring on a database that already had another site's tables (or the same site's tables) using a different table naming prefix then you will end up with unused tables.

B. The prefix of the DATABASE NAME and DATABASE USER. This is typically used in cPanel and Plesk. For example, if your database name prefix is myuser then your database is called something like "myuser_whatever" and your database user is called something like "myuser_something".

You CAN change the database name and database user when restoring your site. However, if your site is not using a database that exists and that MySQL can connect to then your restoration will not work. If you delete the database after the restoration then your site will not work.

It is possible to have two or more sites share the same database, using different table naming prefixes. That's the reason why Joomla (and pretty much every other major CMS) has the concept of a table naming prefix. One site using the prefix foo_ and the other one using the prefix bar_ means that you can have their user tables as foo_users and bar_users respectively, i.e. it's possible to have two completely different sets of data in the same database. If a table naming prefix didn't exist both sites would be trying to use the same table (users) which would end up in a conflict. Essentially, both sites would have to be identical and changing one site would change the other.

Therefore, the bits of information you are giving me make absolutely zero sense.

All I can tell you is that Akeeba Backup does NOT change the database name, database username or table naming prefix on its own. It will only ever do what you explicitly tell it to do DURING RESTORATION AND ONLY DURING RESTORATION. So all I can tell you in the end of the day is that this issue does not concern our support. There's nothing in our software which would magically change something without you explicitly asking it to do. Fair?

cPanel and Plesk are hosting account control panels. This is where you be setting up databases for your sites. It's of course possible that your host is using their own hosting control panel. Seeing how their site is rather, um, vintage I guess it's very likely.

You don't need to hire a database expert. This is a hosting issue.

There is no way that your site is working if it is trying to use a database that doesn't exist. What seems to have happened is that your sites are using a database which is not connected to your hosting account.

Here's a simple solution.

Take a backup of each and every site first. Keep those backup archives not just on your site itself but also somewhere safe (ideally keep two off-line copies; one on your hard drive and one on a USB drive).

Now for each site:

• From the hosting control panel, delete the database
• From the hosting control panel, create a new database and database user
• Restore the site...
• ...and when you see the database restoration page enter the database name, username and password you created above.

Now everything will be in sync.

If you are not sure if / how you can delete and create databases and database users ask your host. And please do ask them to provide accurate information. They tried covering their incompetence the first time by blaming our software. Unfortunately for them I'm not some timid idiot. I've spent almost 20 years managing my own servers. I have both the technical expertise and the demeanor to expose a bad host's BS when my clients ask me.

If at all possible change hosts. I think you'd be better off with a competent host. They're more expensive on the face of it, that's true. But, really, how much does the time you're wasting now cost you? Is a more expensive host much cheaper in the end of the day after all? ;)

You're welcome. It' pretty clear that your host is trying to skin you alive.

Whatever you do, keep regular backups of your site and store them outside of that server. Even if the host decides to pull the plug on your site you can still reconstruct it to its last backed up state, on a new host, using nothing but the backup.

The only thing you'd lose is your email configuration. Make a plan for your emails, e..g have them automatically copied to a Gmail account.

The reason I'm saying this is that I don't trust a host that wants to charge 500 Euros to create a new database. The same operation costs exactly zero in any respectable (and even most sketchy!) hosts...