Backup Tables Left In The Database

What this check and mySites.guru tool looks at on your site

This check connects to your database using the credentials in your site’s Joomla configuration and looks for tables prefixed with bak_, a naming pattern Joomla itself creates under specific circumstances during installation.

Unlike the other checks in this group, this one is not about a configured setting at all. It is about leftover data sitting in tables nobody uses, created once during an installer run and then never touched again, so the fix is a cleanup task rather than a change to how the site is configured. It sits alongside the rest of the automated database checks covered in how to check Joomla database security.

Old password hashes hiding in plain sight

bak_ tables are not a separate, isolated backup sitting safely off to one side. They live in the same live database as your working site, reachable by anything that can already query that database, whether that is a hosting-panel database tool, a vulnerable extension with a SQL injection flaw, or a compromised administrator account. If your site is ever breached, an attacker with database access sees the bak_ tables exactly the same as they see your current #__users and #__content tables.

That matters because these tables can hold an older, forgotten snapshot of user data, including password hashes generated under whatever hashing scheme was in use when the backup was made, which may be weaker than what your site uses today. A user who changed their password since that backup was made is still exposed through it, because the old hash sitting in the bak_ table has no idea the current one was ever rotated. If your site’s live #__users table has been through a forced password reset after a past incident, the bak_ copy quietly undoes part of that response.

They also simply take up space. On a hosting account with a limited database quota, tables nobody is using are wasted allowance that could be needed elsewhere, and on some hosting plans the database size is exactly what determines whether you need to upgrade to a more expensive tier.

There is also a discovery problem specific to these tables. Most people who have bak_ tables in their database do not know they are there. The option that creates them lives inside Joomla’s installer, ticked once, years ago, during a migration or a reinstall, and forgotten the moment the new site was working. Nobody goes looking inside their database for tables they do not remember creating, so these tend to sit untouched indefinitely unless something specifically flags them. It is not unusual to find several generations of bak_ tables from more than one past reinstall sitting in the same database, each one a slightly different snapshot of old user data.

No leftover tables in the database

No tables in your database prefixed with bak_. If Joomla’s installer created any during a past reinstall or migration, they have since been reviewed and removed.

What actually creates these tables

Joomla’s installer offers a “Backup Old Database Tables Before Installation” option whenever you point it at a database that already contains tables from a previous Joomla installation, which happens most often during a migration, a fresh reinstall over an existing database, or a restore where the destination was not cleared first. Ticking that box, which is easy to do without thinking much of it, renames every existing table with a bak_ prefix instead of dropping it, and then creates the new installation’s tables fresh alongside them. It is a reasonable safety net at the moment of installation. The problem is entirely what happens afterwards: nothing in Joomla ever prompts you to come back and deal with the renamed tables, so they simply stay.

How to fix it

1. Take a full backup of your database before removing anything. Even though these are themselves old backup tables, confirm you do not need the data in them first.
2. Log in to phpMyAdmin, usually available through your hosting control panel, and list the tables in your Joomla database.
3. Identify every table prefixed with bak_ followed by your site’s usual table prefix, for example bak_jos_users or bak_xk3f2_content.
4. Confirm each one is genuinely an old backup table rather than something a third-party extension legitimately created with a similar name, then drop it.
5. Log in to https://yoursite.com/administrator and confirm the site still loads and functions correctly afterwards; dropping unrelated tables by mistake is the main risk here, not dropping genuine bak_ tables.

What mySites.guru does about it

We look for bak_ prefixed tables in your database on every snapshot and flag any we find. There is no one-click fix for this, because deleting tables from a live database is not something we do unattended, so we surface the finding and let you confirm and remove them yourself with a backup in hand.

This check pairs with three others in the same family: whether your database prefix is still the guessable default, whether your database user is running as root, and whether that user can see other databases on the server.