Skip to main content
Average reading time: 14 minutes, 52 seconds
Total Votes: 1
Please Rate
Decorative image about how to secure a joomla site

7. Database, backups and monitoring

Database account

Give each site its own database and its own database user, limited to that one database, connecting from localhost only. Never reuse the MySQL root account. The installer's random table prefix (jt_, dqlv8_ and so on) is fine to keep, but it is not a security control.

Cutting the user down to data-only privileges is often suggested. Testing shows where it breaks:

Grants

Front end

Admin login

Smart Search reindex, updates, installs

SELECT, INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, LOCK TABLES

Works

Works

Fails ("DROP command denied")

ALL on the site's database

Works

Works

Works

Only use the reduced grants if your maintenance process restores full privileges for updates. For most teams, "all privileges on this one database only" is the right line.

Backups that actually restore

A backup you have never restored is a hope, not a backup. Two tested options for the database:

# Joomla's own exporter (ZIP of all tables)
php cli/joomla.php database:export --folder=/var/backups/joomla --zip

# Or a consistent mysqldump
mysqldump --single-transaction --quick <dbname> | gzip > /var/backups/joomla/db-$(date +%F).sql.gz

Tested: both completed. The mysqldump file was restored into an empty database, giving all 76 tables and the user record back.

Also back up the files (at minimum configuration.php, images/, files/, templates and any custom code). Keep copies off the server and keep several days of history: if a site was compromised on Monday and you only have Tuesday's backup, you restore the compromise. Store backups outside the web root; a .sql.gz in public_html is a data leak.

Watch the logs and block brute force

Joomla writes every failed login to error.php in the log folder, with the client IP:

2026-10-10T17:23:48+00:00  INFO  127.0.0.1  joomlafailure  Username and password do not match or you do not have an account yet.

Core Joomla does not lock out an IP after repeated failures, so add fail2ban on the server. Filter /etc/fail2ban/filter.d/joomla-auth.conf:

[Definition]
failregex = ^\S+\s+INFO\s+<HOST>\s+joomlafailure\s+
ignoreregex =
datepattern = ^%%Y-%%m-%%dT%%H:%%M:%%S

Jail in /etc/fail2ban/jail.local:

[joomla-auth]
enabled  = true
port     = http,https
filter   = joomla-auth
logpath  = /var/joomla-private/logs/error.php
maxretry = 5
findtime = 10m
bantime  = 1h

Tested: fail2ban-regex against the real log matched 3 of 3 failed-login lines, 0 missed. This depends on correct IPs: keep Behind Load Balancer off unless you really sit behind a proxy (section 3).

Also keep System - Action Logs enabled (it is on by default) so you can see who changed what in the admin, and review Users → User Actions Log after any incident.

If a site is compromised

  1. Take it offline (php cli/joomla.php site:down) and keep a copy of the hacked state for investigation.
  2. Restore from a backup made before the compromise, or reinstall core and extensions from clean packages.
  3. Change every password: Joomla users, database, FTP/SSH, hosting panel. Revoke API tokens.
  4. Find the entry point (out-of-date extension, weak password, writable folder) and fix it before going back online, or it will happen again.

Share this article