Best Joomla Backup Extensions : Akeeba and the Alternatives [2026]

Most Joomla sites have something that calls itself a backup, and a meaningful proportion of those backups will not restore. The failure is discovered at the only moment it matters — after a compromise, a failed update or a hosting migration — and by then the question of whether you had a backup is academic, because what you needed was a restore.

This is about backup done properly for Joomla 5.x: what a real backup must contain, where Akeeba Backup fits and what it genuinely does, why host-level snapshots are necessary but not sufficient, how to do it by hand if you want to understand the mechanics, and how to test a restore so the answer is known in advance rather than discovered under pressure.

The definition that matters

A backup is not a file. A backup is a demonstrated ability to reconstruct a working site somewhere else, within a time you can tolerate, from data you can reach. If you have not restored it, you do not know whether you have one — you have a hypothesis with a filename.

That framing changes what you check. Not “did the backup job run” but “when did I last restore it, where to, and did the site come up”.

What a Joomla backup must contain

Three components, and a backup missing any one of them is incomplete.

Portability is the one people misunderstand. A backup that only restores to the same server, at the same path, with the same database name is useless in the two scenarios where you most need it: the host has gone down, or the host is the problem. Joomla stores absolute paths in configuration.php and, depending on your extensions, in a handful of database rows. A restore tool that rewrites those is doing real work; a plain tar is not.

Akeeba Backup: what it genuinely does

Akeeba Backup is the category leader in the Joomla ecosystem and has been for well over a decade. That is not marketing — it is the honest state of the ecosystem, and it is worth being specific about why, because “it is the popular one” is not a reason.

What it does that a shell script does not:

• Backs up files and database into a single archive, in its own JPA format or as a standard ZIP, so the two cannot drift out of sync.
• Handles execution limits. This is the underrated part. Shared hosting kills PHP processes at 30 or 60 seconds, and Akeeba’s backup engine works in resumable chunks — which is why it completes on hosting where a naive PHP backup script times out at 40% every time.
• Ships a restoration script. The archive is not just data; the restore process walks you through database credentials and path rewriting for the new environment. This is the portability point above, solved.
• Uploads offsite. Post-processing to S3-compatible storage, Dropbox, Google Drive, SFTP and similar, so the archive does not stay on the compromised server.
• Schedules unattended. Via a genuine system cron rather than depending on site traffic.

The free version is genuinely capable — full site and database backup, ZIP and JPA output, and restoration. Paid tiers add offsite post-processing to more destinations, scheduling conveniences, incremental file handling and support, typically in the region of €40–100/year for a single site depending on tier. If the free version does what you need, use the free version; that is the correct decision and not a compromise.

Running Akeeba from cron

Browser-initiated backups are fine for an ad-hoc snapshot before an update. For anything scheduled, drive the backup through the Joomla console — it bypasses web server timeouts entirely and does not care whether anyone is logged in. On Joomla 4, 5 and 6 this is the cli/joomla.php entry point; the old standalone cli/akeeba-backup.php script belongs to the Joomla 3 era.

/usr/bin/php /home/account/public_html/cli/joomla.php \
    akeeba:backup:take --profile=1 >> /home/account/logs/backup.log 2>&1

Scheduled nightly at a quiet hour:

15 3 * * * /usr/bin/php /home/account/public_html/cli/joomla.php akeeba:backup:take --profile=1 >> /home/account/logs/backup.log 2>&1

Two operational points. Use separate profiles for different purposes — a nightly full backup on one profile, a database-only backup on another that can run more frequently and cheaply. And monitor the log, or better, monitor the destination: a cron job that has been failing silently for three months is the single most common way people discover they have no backups.

Host-level backups: necessary, not sufficient

Almost every host now offers snapshots or nightly account backups, and some site owners treat that as the whole answer. It is a genuinely valuable layer with specific limitations you should know before you rely on it alone.

The two rows that decide it are restore to a different host and survives account suspension. If your host suspends the account for an abuse complaint — which is exactly what happens after a compromise — your control panel may be inaccessible and your snapshots with it. If the host has an incident of its own, or you simply want to leave, snapshots in their proprietary format do not come with you.

The correct answer is both. Host snapshots give you a fast, zero-effort rollback for the ordinary case: a bad update, a deleted page, a mistake at 5pm. Extension backups stored offsite give you independence for the serious case. Neither replaces the other, and the combination costs very little.

Manual backup: understanding the mechanics

Worth doing once even if you never do it again, because it makes every restore decision afterwards less mysterious. With shell access, a complete Joomla backup is two commands.

grep -E "public \\\$(user|password|db|host)" configuration.php

mysqldump --single-transaction --routines --triggers --events \
  -h localhost -u dbuser -p dbname > site-db-$(date +%F).sql

tar czf site-files-$(date +%F).tar.gz \
  --exclude='./cache/*' --exclude='./tmp/*' \
  --exclude='./administrator/cache/*' \
  -C /home/account/public_html .

sha256sum site-files-*.tar.gz site-db-*.sql > manifest.txt
tar tzf site-files-$(date +%F).tar.gz > /dev/null && echo "archive OK"
rsync -av site-*.tar.gz site-*.sql manifest.txt backup-host:/backups/example.com/

Restoring by hand is the reverse: extract, create a database, import the SQL, edit configuration.php for the new credentials and the new log_path and tmp_path, and fix permissions to 755/644. Note how much of that is manual fiddling — that is precisely what a restoration script automates, and why extension backups are worth having even though the manual route works.

Restore testing: the part everyone skips

An untested backup is not a backup. Testing is not difficult; it is just never urgent, which is why it does not happen. Make it a scheduled task with a date.

Offsite storage and the 3-2-1 rule

The old rule still holds: three copies of the data, on two different media or systems, one of them offsite. For a Joomla site that maps to the live site, a copy on the server or host snapshot, and a copy somewhere the server cannot reach.

That last clause is the one that matters. If the backup destination is writable using credentials stored on the web server, an attacker with code execution can delete your backups — and ransomware tooling does exactly that as a matter of routine. Mitigations, in increasing strength: a write-only upload credential that cannot list or delete; object storage with versioning and a lifecycle policy; and a pull-based model where a separate machine fetches backups from the site rather than the site pushing them out.

For a small site, object storage from any of the mainstream providers costs pennies a month at typical Joomla backup sizes, and enabling versioning on the bucket is a single setting that defuses most of this risk.

Retention: how far back you need to reach

Retention is chosen by asking how long a problem can go unnoticed. A deleted page is noticed in a day. A quiet compromise, a slow database corruption or a botched content edit on a rarely visited page can go unnoticed for months.

Note the split cadence on the busier profiles. Files change rarely on a typical Joomla site — an extension update, a template tweak — while the database changes constantly. Backing the database up more often than the files is cheaper and gives you a much tighter recovery point where it counts.

The things outside the archive that you also need

A perfect site archive still leaves you unable to restore if the surrounding pieces are missing. These are not in any backup tool’s scope, which is exactly why they get forgotten.

Registrar and DNS access. If you are restoring to a new host, you need to repoint DNS, and that means credentials for the registrar or DNS provider. Record where the domain is registered, who holds the account, and when it renews. A site restored perfectly to a new server is still down if nobody can change an A record.

Extension licence keys and download credentials. Commercial extensions are usually re-downloaded rather than restored, and that needs a subscription login. Keep a list: extension, vendor, account, renewal date. Discovering mid-restore that a licence lapsed eight months ago is a bad moment.

Custom template and override files. These are inside the archive, but only if you actually deployed them to the server. Bespoke work developed locally and pushed piecemeal has a habit of existing in exactly one place, on a laptop, uncommitted.

Third-party service configuration. SMTP credentials, payment gateway keys, API tokens and analytics identifiers live in extension settings, so they are inside the database — but they are also the things most likely to need rotating after an incident. Keep a documented inventory of what the site talks to.

Fifteen minutes writing this down, stored with your backup credentials rather than on the site, converts a restore from an investigation into a procedure.

Comparison of approaches

That last row is the honest recommendation. Host snapshots handle the frequent, boring case — an update went wrong, roll back twenty minutes. An extension backup stored offsite handles the rare, serious case — the host is unreachable, the account is suspended, the site was compromised. They cover different failures and the combination is neither expensive nor difficult.

Frequently asked questions

Is the free version of Akeeba Backup enough?

For many sites, yes. It performs complete file and database backups and includes restoration, which is the core of the problem. The paid tiers mainly add automated offsite transfer to more destinations, scheduling conveniences and support. If you are willing to move archives offsite by another route, the free version covers the essentials properly.

How often should I back up my Joomla site?

Ask how much content you are prepared to re-create. A site publishing daily needs daily backups; a brochure site edited twice a year needs a weekly job and a manual backup before every change. The one universal rule is to take a backup immediately before any update, extension install or template change.

Can I just copy the files over FTP?

That is half a backup, and the less important half. Without the database you have no articles, users, menus, module configuration or extension settings — the site is unrecoverable from files alone. Files also transfer slowly over FTP and interrupted transfers produce silently truncated files, which is exactly what you do not want in a backup.

Where should backup archives be stored?

Not in the web root — an archive in /backups under public_html is directly downloadable by anyone who guesses the filename, and contains your database credentials. Store archives outside the web root and ship a copy to storage the web server cannot delete. At minimum, put them somewhere that survives the hosting account being suspended.

How do I restore a Joomla site to a different domain?

Restore files and database as normal, then update configuration.php with the new database credentials and the new log_path and tmp_path. Joomla itself stores few absolute URLs, so most sites come up correctly at that point. Afterwards, search article content for hardcoded absolute links to the old domain, which is where the remaining breakage lives.

My host takes daily backups. Do I need anything else?

Yes. Host backups are a good first layer and a poor only layer: retention is typically short, restoring to a different provider is usually impossible, and if the account is suspended you may lose access to the backups along with the site. Add an offsite extension backup — an hour of setup for a materially different worst case.

How do I know my backups are actually working?

Only by restoring one. Monitor that the job runs and that new archives appear at the destination with a plausible size — a suddenly smaller archive usually means something stopped being included — but the real test is a quarterly restore to a staging subdomain, worked through as if it were an emergency.