Joomla Backups: Strategy, Tools and Restore Testing

1. The Basics

1.1 What a Joomla Backup Is

A Joomla site is two things that must always travel together:

A backup of only the files gives you an empty site with no articles. A backup of only the database gives you content with no site around it and no images. A real Joomla backup always contains both, made at the same moment.

1.2 What Joomla Core Does (and Does Not) Provide

Joomla itself ships no backup feature. The closest the core comes is a reminder: the Joomla Update component shows a checkbox "I'm aware that a backup before any update is highly recommended" before it lets you update (the backupcheck option, enabled by default). Joomla reminds you; the actual backup is your job, done with a hosting tool, an extension, or your own script.

That is a deliberate choice, not a gap. Backups must be stored away from the site to be worth anything, and that is easier to arrange outside the CMS than inside it.

1.3 What Backups Protect You Against

• Hacks: restore a clean site instead of cleaning a compromised one file by file.
• Failed updates: roll back when a core or extension update goes wrong.
• Human error: a deleted category, an emptied article, a broken template edit.
• Server failure: disks die, hosts disappear, accounts get suspended.
• Ransomware: an off-site backup is the one copy an attacker cannot encrypt.

3. Backup Strategy: the 3-2-1 Rule

3.1 The Rule

The industry standard is called the 3-2-1 rule:

3  copies of your data   (production + 2 backups)
2  different kinds of storage
1  copy off-site, away from the web server

The off-site copy is the heart of the rule. A backup on the same server dies with the server, gets encrypted with the site in a ransomware attack, and disappears with a suspended hosting account. "Off-site" can be cloud storage, another server, or a disk at the office - anywhere that does not share fate with production.

3.2 How Often to Back Up

Match the schedule to how fast the site changes and how much you can afford to lose:

And always, without exception: one extra backup right before any update or big change. It is the cheapest insurance in web development.

3.3 Generations and Retention

Keep multiple generations, not one rolling copy. A hack discovered after three weeks makes every backup of the last three weeks suspect; you want an older, clean generation to fall back on. A common scheme: keep 7 daily, 4 weekly, and a few monthly backups.

Mind privacy law here too: backups contain personal data, so your GDPR retention promises apply to them as well. A backup you keep for years quietly contradicts a privacy policy that promises deletion on request.

3.4 Full, Incremental, and Differential

Backup tools offer three ways to build an archive, and the words appear in every serious tool's options:

For most Joomla sites a nightly full backup is the simplest and most robust choice; storage is cheap and independence pays off on the day you restore. Incremental schemes earn their keep on very large sites - a huge images/ folder, tight storage quotas - where copying everything nightly is not realistic.

3.5 Immutable Backups

Modern ransomware attacks backup storage first, then the site: encrypted backups make victims pay. The answer is immutable storage: backup space where files cannot be changed or deleted during a set retention window, not even with the storage account's own credentials. Cloud object storage offers this as an option (for example S3 Object Lock and comparable features at other providers), and some NAS systems offer immutable snapshots.

If your off-site storage supports an object lock or immutability option, switch it on for your retention window. It converts your off-site copy from "probably safe" to "provably out of reach".

5. Making a Manual Backup

5.1 When Manual is the Right Tool

Every administrator should have made at least one backup by hand: it teaches you exactly what a backup contains, and it works when nothing else does - a broken backend, a locked-out extension, a site you just inherited.

5.2 Step by Step on the Command Line

The credentials you need are in configuration.php ($host, $user, $password, $db). With those:

# 1. Optional: take the site offline during the backup
php cli/joomla.php site:down

# 2. Dump the database (single transaction = consistent dump)
mysqldump --single-transaction -h localhost -u dbuser -p sitedb \
          > site-$(date +%F).sql

# 3. Archive the files, excluding regenerated folders
tar --exclude='./cache' --exclude='./tmp' \
    --exclude='./administrator/cache' \
    -czf site-$(date +%F).tar.gz .

# 4. Bring the site back
php cli/joomla.php site:up

# 5. Move both files OFF the server
scp site-*.sql site-*.tar.gz backup-user@backup-host:/backups/

Step 5 is not optional. A backup that stays in the web root is a security risk (anyone who guesses the name can download your whole site, credentials included) and dies with the server.

5.3 Without Shell Access

On shared hosting without SSH: export the database with phpMyAdmin (select the database, Export, SQL format) and download the files with the hosting panel's file manager as a compressed archive. Avoid plain FTP for thousands of small files; it is slow and silently drops files far more often than people think.

7. Restoring a Backup

7.1 Restoring with a Wizard

With an Akeeba-style archive: upload the archive and Kickstart to the (empty) target folder, open Kickstart in the browser, and follow the wizard. It extracts the files, creates and fills the database, asks for the new database credentials, writes configuration.php, and cleans up after itself. Ten minutes, most of it waiting.

7.2 Restoring by Hand

The manual route mirrors the manual backup:

1. Upload and extract the file archive into the web root.
2. Create an empty database and user, and import the dump: mysql -u dbuser -p sitedb < site.sql
3. Open configuration.php and fix what changed:

public $host     = 'localhost';     // new DB host
public $user     = 'new_dbuser';    // new DB user
public $password = '...';           // new DB password
public $db       = 'new_sitedb';    // new DB name
public $dbprefix = 'jos_';          // must match the dump!
public $tmp_path = '/new/path/tmp'; // absolute paths: update them
public $log_path = '/new/path/logs';
public $live_site = '';             // leave empty unless you know why

4. Check file ownership and permissions (files 644, folders 755, owned by the PHP user).
5. Test the frontend, the backend login, and one image upload. Run System → Database (or php cli/joomla.php maintenance:database) to verify the schema.

7.3 Restoring After a Hack

One special rule applies: restore to a point before the compromise, not just before you noticed it, and investigate the entry point before going live again - otherwise you restore the vulnerability along with the site. The incident response section of the security hardening article covers that order of work.

9. Testing Your Backups

9.1 An Untested Backup is a Hope

Backups fail silently: truncated dumps, archives missing half the images folder, credentials that no longer decrypt, a format the new PHP version cannot read. None of that shows until you restore. The only proof a backup works is a completed test restore - everything else is optimism.

9.2 The Restore Drill

Twice a year (and after every change to the backup setup), run the drill:

1. Take a current backup from the off-site storage - not from the server.
2. Restore it to a separate location: a local Docker stack, a subdomain, or a scratch VPS.
3. Walk a checklist: frontend renders, backend login works, newest article present, images load, one form submits.
4. Note how long it took. That number is your real recovery time, and it is worth knowing before an outage.

The drill has a bonus: a restored copy is a perfect staging site for testing the next big update.

It also has less friction than it seems, because a wizard restore is a predictable browser flow - which means you can automate it. I run my own restore drills with a small Playwright script (a browser automation tool) that uploads the archive, clicks through the Kickstart wizard, and leaves a fresh copy of the site running in a local Docker stack: restoring a site is one command. The lower you make the friction, the more often the drill actually happens - and a drill that happens beats a perfect procedure that stays theoretical.

9.3 From Backup to Disaster Recovery Plan

Professionals describe recovery with two numbers, and both are decisions you should make consciously per site:

• RPO (Recovery Point Objective): how much data you can afford to lose. A nightly backup means an RPO of up to 24 hours - acceptable for a brochure site, painful for a shop.
• RTO (Recovery Time Objective): how fast the site must be back online. Your restore drill measures whether reality matches the ambition.

The second half of a disaster recovery plan is documentation, because a backup only recovers a site if someone can actually execute the restore. Write down: where the backups and their encryption passwords live, the step-by-step restore procedure, the credentials needed (hosting, DNS, database), and who to call. Store that document outside the site itself - a wiki, a password manager note, a printed page in a drawer. The test is simple: could a colleague restore the site while you are unreachable on holiday?

11. Backups and the Web Services API

The Joomla Web Services API has no backup endpoints: you cannot trigger or download a backup via /api/index.php/v1/... with core alone. That is sensible - streaming a full site archive through the CMS it is supposed to protect would be fragile and risky.

Remote backup automation therefore runs on other rails: SSH for script-based setups, the JSON APIs that backup extensions expose for fleet tools (this is how services that manage many Joomla sites trigger nightly backups remotely), or the hosting provider's own API for account snapshots. What the Web Services API is good for in this context is monitoring: a fleet script can call a site's API to verify it is up and on the expected Joomla version after a restore completes.

13. Common Mistakes and Pitfalls

13.1 The Backup Lives on the Server it Protects

Symptom: backups exist, but the server crash / hack / account suspension took them down together with the site.

Fix: apply the 3-2-1 rule. At least one current copy must live somewhere that shares no fate with the web server, and the web root is the worst place of all - there it is also downloadable by attackers.

13.2 Only the Database, or Only the Files

Symptom: after a restore, a site with no articles - or all articles with every image broken.

Fix: a Joomla backup is files plus database from the same moment. Check that both are in the archive and that images/ and configuration.php are actually inside.

13.3 The Untested Backup That Cannot Be Restored

Symptom: the restore fails on the worst day - corrupt archive, incomplete dump, forgotten password on the encrypted backup.

Fix: run the restore drill from section 9 twice a year. Store the backup encryption password in your password manager, not only in the tool that made the backup.

13.4 Relying Solely on the Host

Symptom: "the hosting company makes backups" turns out to mean 7 days of retention, and the hack is 12 days old.

Fix: host backups are a bonus layer. Keep your own schedule with your own retention (dailies, weeklies, monthlies), under your own control.

13.5 The Automation That Silently Died

Symptom: the last backup is from March. It is November.

Fix: monitor for the absence of backups, not just failures: a monthly check of the newest file's date and size, and alerting that notices when the nightly job stops reporting.

13.6 Restoring Over the Only Evidence

Symptom: after a hack, the site was restored immediately - and now nobody can find out how the attacker got in, and they return within a week.

Fix: before restoring, preserve a copy of the compromised state (files + logs) for investigation, then restore to a clean point and close the entry hole. Containment first, restore second.

15. Quick Reference

CONTENT      files:  configuration.php, images/, templates/, media/,
                     extension folders     (skip cache/, tmp/, logs)
             db:     all #__ tables        (skip #__session)

RULE         3 copies - 2 storage types - 1 off-site
             extra backup before EVERY update
             generations: 7 daily / 4 weekly / few monthly
             full = independent restore, incremental = chained
             immutable storage (object lock) resists ransomware

MANUAL       php cli/joomla.php site:down
             mysqldump --single-transaction -u USER -p DB > site.sql
             tar --exclude='./cache' --exclude='./tmp' -czf site.tar.gz .
             php cli/joomla.php site:up
             scp both files OFF the server

RESTORE      extract files > create db > import dump
             fix configuration.php: $host $user $password $db
                                    $dbprefix $tmp_path $log_path
             permissions 644/755, test frontend + backend + upload
             php cli/joomla.php maintenance:database

MIGRATE      = restore on the new server
             test via temp URL > install SSL > then switch DNS

TEST         restore drill 2x/year to a separate location
             check: pages, login, newest content, images, forms
             note the recovery time
             RPO = max data loss, RTO = max downtime
             document: locations, procedure, credentials, contacts

TOOLS        extension (Akeeba: JPA + Kickstart, restores anywhere)
             + host panel backups as second layer
             + own mysqldump/tar scripts for full control

MONITOR      alert on missing backups, not only failed ones
             watch newest file age + size monthly

API/CLI      no core backup:* command, no REST backup endpoint
             site:down / site:up / config:get / maintenance:database