User Guide

FM Backup

How to back up your Joomla site, how to get it back when something goes wrong, and the handful of settings actually worth changing.

Version 1.1.0 For Joomla 6 freemarkit.co.za

Start here

FM Backup makes a copy of your entire Joomla site — all of your files and your whole database — and puts it into one ZIP file. If your site later breaks, gets hacked, or an update goes badly, you can put that copy back and carry on.

That is the whole idea. Everything else in this guide is detail.

The three-minute version

If you read nothing else, do these three things:

  1. Run a backup now — section 3. A profile called Standard is already set up for you, so this takes two clicks.
  2. Move your backups somewhere the public cannot reach — section 6. This one genuinely matters.
  3. Set backups to run automatically — section 8. A backup you have to remember to make is a backup you will not have.

What a backup actually contains

Everything. Your articles, images, extensions, template changes, user accounts, settings, and the database behind all of it. Restoring returns your site to exactly the state it was in the moment the backup ran.

Anything changed after the backup ran is not in it. This is why backup frequency matters: a monthly backup means you could lose up to a month of work.

Plain ZIP files

Your backups are ordinary ZIP files. You can open one on your own computer with any unzip tool and see your site inside it. Nothing is locked into a special format that only this software can read — your data stays yours, and stays recoverable, whatever happens to this extension.

Installing

  1. In Joomla administration, go to System › Install › Extensions.
  2. Drag the FM Backup package file onto the upload area, or click to browse for it.
  3. Wait for the success message.

FM Backup now lives at Components › FM Backup. Open it and you will land on the Dashboard.

What was installed

The one package contains three parts:

PartWhat it doesActive?
The component Everything you see and click — making backups, restoring, settings, history. Ready now
Scheduled task plugin Lets Joomla run backups automatically on a timetable. Off until you enable it
Dashboard icon plugin Adds a tile to your Joomla home screen showing how old your last backup is. Off until you enable it

The two plugins start switched off on purpose. Nothing runs on a schedule, and nothing changes on your dashboard, until you decide it should. Turning them on is covered in sections 8 and 9.

Your first backup

  1. Go to Components › FM Backup › Backup Profiles.
  2. You will see a profile called Standard. Click Run Now next to it.
  3. A progress page opens. Leave this browser tab open and in front of you.
  4. When it reaches 100%, you are done. Click View Backups to see your archive.

What to expect while it runs

A long pause at the beginning
The first step counts every file on your site before it can report any progress. On a large site this can take several minutes with the bar showing nothing. This is normal, and the page tells you so. Do not refresh.
Then steady progress
The bar moves as files are packed, then as the database is copied. A running log below shows what is happening.
How long overall
A small site takes a minute or two. A large site with a lot of images and video can take considerably longer. The first backup is the slow one — you will know what is normal for your site after that.
If you need to leave

Closing the tab or clicking away does not ruin the backup — it pauses it. Go to Logs, find the paused run, and click Resume to pick up where it stopped.

It pauses because your browser is what drives the backup forward, a step at a time. That design is what lets large sites finish on ordinary hosting instead of hitting a time limit and dying half way. If you would rather backups did not need a browser window at all, that is exactly what scheduling is for — section 8.

Reading the results

Three screens tell you what has happened.

Dashboard

The overview. Shows your most recent backup — when it ran, whether it worked, how big it is — plus recent activity. This is the screen to glance at when you want quick reassurance that backups are still happening.

Backups

Every archive currently on disk, with its size and date. From here you can:

  • Details — look inside the archive without unpacking it: how many files and database tables it holds, which Joomla version made it, and the fifty largest files in it. That last list is the fastest way to find out why a backup is enormous.
  • Download — save a copy to your own computer. Do this regularly; see section 16.
  • Delete — remove an archive permanently.

Logs

The full history of every backup and restore, successful or not. Click any entry for a step-by-step account of the run with timings. When something has gone wrong, this is where the answer is — and it is the first thing to look at before asking anyone for help.

StatusMeaning
SuccessFinished. You have a usable backup.
In ProgressRunning right now.
PausedStopped part-way; you navigated away. Resume it from this screen.
FailedSomething went wrong. Open the entry to see what — then see section 15.
CancelledYou stopped it deliberately.
Only "Success" counts

A failed or paused run has not produced a usable backup, whatever partial file may exist on disk. If you see repeated failures, deal with them now rather than discovering the gap on the day you need to restore.

Where backups are stored

By default, archives are written inside your Joomla installation, in a folder belonging to FM Backup. You can see and change this at Components › FM Backup › Options › Storage Folder.

The default is chosen because it works everywhere without configuration. It is not the best place. Two reasons:

  • Privacy. Anything inside your website folder can potentially be reached from the internet. See the next section — this is the important one.
  • It is on the same disk as your site. If the server fails, you lose the site and its backups together. A backup stored only next to the thing it is backing up has not really protected you.

You can enter either a path relative to your site (the default style) or a full absolute path anywhere your web server can write. If your hosting gives you a folder above your public web folder — often called something like private or sitting beside public_html — that is the right place for backups.

Keeping backups private

Read this section

A backup of your site contains your database password in plain text, along with every user account and password on the site. It is the single most sensitive file your website will ever produce. Anyone who downloads one effectively owns your site.

Check whether yours are exposed

Worth doing once, and it takes a minute:

  1. Go to Backups and note the exact filename of an archive.
  2. Open a private or incognito browser window — this matters, so you are not logged in.
  3. Try to visit that file's web address directly. If your storage folder is at the default location, that is your site address followed by /administrator/components/com_fmbackup/backups/ and then the filename.
  4. If a download starts, your backups are public. Fix it now.

FM Backup places protective files in the storage folder that block this on most servers. On some server setups those files are ignored entirely. Testing is the only way to know which kind of server you have.

Fixing it

Best first:

  • Move the storage folder outside your public web folder, as described in section 5. Nothing outside that folder can be requested over the web at all, whatever the server configuration. This is the real fix.
  • Ask your host to block web access to that folder, if you cannot move it.

Also worth knowing:

  • Backups are not encrypted. Anyone who obtains the file can read everything in it.
  • Treat downloaded copies with the same care — a backup sitting in your Downloads folder or emailed to yourself is the same sensitive file.
  • Only administrators can reach FM Backup, and downloads through the component are protected against tampering. The risk is the storage folder being readable directly, not the component itself.

Backup profiles

A profile is a saved recipe describing what to include in a backup. The Standard profile that came with the component backs up everything, and for most people that is the right answer permanently. You never have to create another one.

Profiles become useful when you want more than one kind of backup. A common arrangement:

  • A full profile — everything — run weekly.
  • A database-only profile — small and fast — run daily. Your articles, orders and comments live in the database, so this captures nearly all day-to-day change for a fraction of the size.

Creating one

Go to Backup Profiles and click New. Give it a name, fill in what you need from the fields below, and save.

Additional File Paths to Exclude
Things to leave out, one per line, written relative to your site root — for example images/video-archive. Everything on your site is included unless you exclude it here.
Force-Include File Paths
An exception to the exclusions. If you excluded a whole folder but need one thing inside it kept, name it here. Including always beats excluding.
Additional Database Tables to Exclude
Tables to skip, one per line. * works as a wildcard. Leave this alone unless you know a particular table is both huge and disposable.
Force-Include Database Tables
The same exception mechanism, for tables.
External Paths to Include
Full paths to files or folders that live outside your Joomla site but that you want captured anyway — an SSL key, for instance. These are stored in the archive under a folder named _external. Read the warning below before relying on this.
Debug Mode
Produces a much more detailed log. Leave it off normally; turn it on when investigating a failure.
External paths are not put back automatically

Files captured from outside your site are stored safely in the archive, but a restore will not write them back to their original locations. You must copy them into place yourself from inside the ZIP. This is deliberate: writing files to arbitrary places on a server during an automated restore is dangerous, and doing it silently more so.

Making a database-only profile

There is no single "database only" switch. Create a profile and exclude everything from the file side by entering a single line of * in Additional File Paths to Exclude. Run it once and check the result in Details before trusting it.

What is already left out

Some things are excluded by default for everyone, because backing them up wastes space and achieves nothing: temporary folders, cache folders, and FM Backup's own history tables. The Standard profile additionally skips loose ZIP files and the storage folders of other backup extensions — otherwise your backup ends up containing someone else's backups and grows enormous. You can see and adjust these defaults in Options.

Automatic backups

Manual backups get forgotten. This is the section that turns FM Backup from something you use into something that protects you.

Setting it up

  1. Go to System › Manage › Plugins and search for Task - FM Backup. Open it, set Status to Enabled, and save.
  2. Go to System › Manage › Scheduled Tasks and click New.
  3. Choose the task type FM Backup - Run Profile.
  4. Give it a name you will recognise later, such as "Nightly backup".
  5. In the task's options, choose which profile to run.
  6. Set the Execution Rule — for example, daily at 3am, when your site is quiet.
  7. Save.

The step everybody misses

Joomla's scheduler needs to be triggered

Creating a scheduled task is not enough on its own. Joomla's scheduler has to be woken up by something before it will run anything. Check Scheduled Tasks › Options to see how yours is set.

The common setting, Lazy Scheduler, wakes up when visitors browse your site. That is fine for a busy site, but on a quiet one your 3am backup may not run until someone visits at lunchtime. For backups you actually depend on, ask your host about setting up a proper cron job — most hosting control panels offer this, and Joomla's own options screen tells you what address to point it at.

Confirming it works

Do not assume. On the Scheduled Tasks list, click Run on your new task to trigger it by hand, then check FM Backup › Logs for a new entry marked Success.

If the manual run works but nothing appears overnight, the task is fine and the trigger is the problem — go back to the warning above. Then check again after a day or two that backups are appearing on their own.

Scheduled runs need no browser

A scheduled backup runs entirely on the server, so nothing has to stay open and there is no pausing. This is the more reliable way to run backups on a large site.

Failure emails

A scheduled backup runs when nobody is watching. If it starts failing, nothing on screen tells you — and the longer that goes unnoticed, the more confident you become in a backup that is not actually being taken. FM Backup can email you when a run fails.

Already on

Failure emails are enabled by default and sent to your site's From address (Global Configuration › Server › Mail). If that address reaches you, there is nothing to set up. If it does not, set a proper recipient below — this is the single most valuable five minutes in this guide.

Setting it up

  1. Go to Components › FM Backup › Options › Notifications.
  2. Put your address in Notification Address. Several addresses can be separated with commas.
  3. Save.

Emails come from your Joomla site, using whatever mail settings it already uses. If your site cannot send email at all — a common situation on cheap hosting — then neither can this. Test with Joomla's own mail test before relying on it.

What the email tells you

Enough to judge urgency without logging in: which site and profile, what triggered the run, which stage it died at, the error itself, the last few lines of the log, and a link straight to the full record.

Which failures send email

Scheduled backups
Always emailed. This is the case the feature exists for — a failure nobody saw.
Manual backups
Not emailed by default. You are already watching the screen when one fails, so an email is just noise. Switch Notify For to Scheduled and manual if the person responsible for backups is not the person clicking the button — an agency looking after a client's site, for instance.
Failed restores
Always emailed, whatever the above is set to. A restore that fails part-way can leave a site in a mixed state, so it is never filtered out.

Not being flooded

A backup scheduled hourly that starts failing would, unchecked, send twenty-four emails a day. People respond to that by filtering the messages away — which puts you right back where you started, except now you also believe you would be told. So FM Backup sends one email per profile per day by default, however many times it fails.

Both halves of that are adjustable — Maximum Emails per Window and Throttle Window (hours). Setting either to 0 turns throttling off and sends every single failure, which is rarely what you want. Each profile is counted separately, so a nightly backup failing repeatedly never suppresses the alert for a different profile.

What this does not catch

Emails are sent when a run fails. If a run is killed outright instead — the server runs out of memory or time, or the host restarts mid-backup — there is no failure to report, and the run simply stops. It will sit in the Logs list as Running and never finish, with no email sent.

So the emails are a safety net, not a guarantee. Keep glancing at the dashboard tile (next section): it shows the age of your last successful backup, which catches the vanished runs that email cannot.

The dashboard tile

FM Backup can add a tile to your Joomla home screen showing how long ago your last successful backup ran. It is an easy way to notice that backups have quietly stopped — which is exactly the sort of thing nobody notices until it matters.

  1. Go to System › Manage › Plugins and search for Quick Icon - FM Backup.
  2. Open it, set Status to Enabled, and save.
  3. Go to your Joomla Home Dashboard.

Reading the tile:

  • Green — a successful backup within the last 24 hours.
  • Red — the last backup is more than 24 hours old, or there has never been one. Worth investigating.

If you deliberately back up weekly rather than daily, the tile will show red most of the time. That is expected and not a fault; either accept it or leave the plugin disabled.

Housekeeping

Backups accumulate, and each one is roughly the size of your site. Left alone they will eventually fill your hosting account — and a full disk breaks the website itself, not just the backups. FM Backup manages this in two ways.

Keep the most recent few

Options › Retention Count sets how many archives to keep per profile — ten by default. After each successful backup, anything older than that count is deleted. Set it to 0 to keep everything and manage the folder yourself.

Do not set this to 1

A retention count of 1 leaves you with exactly one backup — and if the most recent run captured a site that was already broken or compromised, that is now the only copy you have. Several backups spanning several days is what lets you go back to before a problem started. Three is a sensible minimum; the default of ten is better.

Delete anything older than a set age

A second, optional task deletes backups by age rather than count. Set it up exactly like the backup task in section 8, but choose the task type FM Backup - Purge Old Backups, pick a profile, and set how many days to keep (30 by default).

This one always keeps the single most recent backup, even if it is older than the limit — so it can never empty your storage folder completely.

Why both? Retention by count only happens as a side effect of a successful backup. If backups quietly stop working, nothing gets tidied up ever again. The age-based purge runs on its own schedule regardless, so it keeps working when the other one cannot. Using both is fine; whichever applies first simply gets there first.

Restoring

Restoring puts a backup back, returning your site to how it was when that backup ran.

Restoring overwrites, and cannot be undone

A restore replaces your current files and database with the ones from the archive. Anything created since that backup ran is gone. There is no undo.

Take a fresh backup before restoring, even when the current site is broken. If the restore turns out to be the wrong one, that new backup is your way back. If a restore stops half way through, the site is left partway between two states — this is precisely when having that extra copy saves you.

How to restore

  1. Go to Components › FM Backup › Restore.
  2. Choose the backup to restore from. The list shows the date and profile of each archive found in your storage folder.
  3. Choose what to restore — see the options below.
  4. Read the warning on screen, then click Start Restore.
  5. Leave the tab open until it finishes, exactly as with a backup.

The options

Files and Database
The complete restore. This is the normal choice and the default.
Files Only
Replaces files and leaves the database untouched. Useful when an extension or template change broke the site but your content is fine — you keep everything written since the backup.
Database Only
Replaces the database and leaves files alone. Useful after content is deleted or damaged but the site itself works.
Restore configuration.php
Off by default, and should usually stay off. This one file holds your database password and server paths. Restoring it onto the same site is harmless; restoring it onto a different server overwrites correct settings with the old server's, and the site will not load. See section 13.

Restoring a backup from elsewhere

The Restore screen simply lists whatever ZIP archives it finds in your storage folder. You can copy a backup taken from another site into that folder and it will appear in the list, ready to restore. Nothing needs to be registered or imported first.

This is what makes recovery possible in the situations that matter — rebuilding on a new server, or restoring a site whose own records are damaged.

After a restore

  • Log in to administration again — restoring the database restores the old sessions, so you will be logged out.
  • Clear your Joomla cache: System › Clear Cache.
  • Check the front end of the site properly: a few pages, images, and a login.

Moving to a new host

The same mechanism that restores a site can move one. The important detail is that FM Backup adjusts the database naming automatically, so a backup from one site will import cleanly into another even when the two were set up differently.

  1. On the old site, run a backup and download it to your computer.
  2. On the new server, install Joomla normally, then install FM Backup on it.
  3. Set the storage folder on the new site, then upload your archive into that folder using FTP or your host's file manager.
  4. Go to Restore. Your uploaded archive appears in the list.
  5. Choose Files and Database, and leave Restore configuration.php switched OFF.
  6. Run the restore, then log in and check the site.
The one thing that goes wrong

If you leave Restore configuration.php switched on when moving to a different server, the new site inherits the old server's database password and folder paths. The result is a site that will not load at all, usually with a database connection error.

If this happens, it is fixable: edit configuration.php in your site's root folder by FTP and correct the database settings and paths for the new server.

Settings reference

Found at Components › FM Backup › Options. The defaults are sensible; the only one most people should change is the first.

SettingDefaultWhat it does
Storage Folder Inside the site Where archives are written. Worth moving outside your public web folder — see section 6.
Retention Count 10 How many archives to keep per profile. 0 keeps all. Do not set this to 1.
Debug Mode by Default No Turns on detailed logging for new profiles. Leave off unless investigating a problem.
Step Time Budget 20 seconds How long the backup works before reporting progress and continuing. Lower it if runs fail with timeout errors; otherwise leave it.
ZIP Compression Level 6 Higher makes smaller archives but takes longer. See the note below.
Default File Exclusions Caches, temp, .git Applied to every profile. Rarely needs changing.
Default Database Table Exclusions Sessions, search index, cache Applied to every profile. Excludes data that rebuilds itself anyway.
Verify Integrity in Dry Run Yes Re-checks the archive during a Dry Run to confirm it is undamaged. Reads the whole archive, so turn it off if dry runs are slow on very large backups — integrity is still checked when the restore itself runs.
Send Failure Emails Yes Emails you when a run fails. See section 9.
Notification Address Site From address Where failure emails go. Comma-separate several. Worth setting explicitly.
Notify For Scheduled only Whether manual backup failures are emailed too. Failed restores always email regardless.
Maximum Emails per Window 1 How many failure emails one profile may send per window. 0 disables throttling.
Throttle Window 24 hours The period the limit above applies over. Together these mean one email a day per profile.
About compression

FM Backup already skips compressing files that are compressed by nature — photographs, video, PDFs. Turning the level up therefore does far less than you would expect on a media-heavy site, while costing real time on every run. If your backups are slow and disk space is not tight, try lowering it rather than raising it.

When something goes wrong

Start at Components › FM Backup › Logs and open the failed run. For a stubborn problem, switch Debug Mode on in the profile and run it again for far more detail.

The progress bar sits at zero for ages
Normal. The first step counts every file before reporting anything. Give a large site several minutes before assuming it has stalled.
The backup stops when I switch tabs
Also normal — it pauses, and resumes from Logs. Browsers deliberately slow down background tabs. Keep the tab in front, or use scheduled backups instead, which need no browser at all.
The backup fails part-way with no clear reason
Usually disk space. Check what your hosting account has free against the size of your site — you need room for roughly another whole copy. Failing that, exclude something large and non-essential and try again to confirm.
It fails on the same file every time
That file is probably unreadable — a permissions problem or a broken link left behind by something else. The debug log names it. Add it to the profile's exclusions and it will stop blocking backups.
Timeout or "gateway" errors during a run
Something between your browser and the server is cutting requests short. Lower Step Time Budget in Options to 10 seconds so each step finishes sooner.
Scheduled backups never happen
Three things must all be true: the Task plugin is enabled, the task exists and is enabled, and Joomla's scheduler is being triggered. The third is nearly always the culprit — see the warning in section 8. Click Run on the task manually: if that works, the task is fine and only the trigger is wrong.
No backups appear on the Restore screen
That screen lists ZIP files found in the storage folder. Either the folder setting is wrong, or the archives are somewhere else. Check the path in Options matches where your files actually are.
The site is broken after restoring
Almost always configuration.php, especially if you restored onto a different server with that option switched on. See section 13.
The restore finished but content is still missing
Check you did not choose Files Only, which leaves the database untouched. The log records exactly what was restored.

Asking for help

Include these, and you will get a useful answer first time:

  • Your Joomla and PHP versions
  • Your FM Backup version
  • What kind of hosting (shared hosting, VPS, local)
  • What you did, what happened, and what you expected
  • The log from the failed run, with Debug Mode on
Check logs before sharing them

Debug logs list server folder paths and can include details you would not want public. Read through and remove anything sensitive before posting one in a public forum.

Tips from experience

Test a restore before you need one
This is the single most valuable thing in this guide. An untested backup is a hope, not a backup — plenty of people discover their archives were unusable only on the day everything depended on them. Set up a spare test site, restore a backup onto it, and see it work. Then you know.
Keep copies somewhere else
Backups stored only on the same server disappear with that server. Periodically download an archive and keep it on your own computer or in cloud storage. Even once a month transforms your position if the hosting account is lost entirely.
Back up before you change anything
Updating Joomla, installing an extension, editing a template — run a backup first. It takes a couple of minutes and turns a potential disaster into an inconvenience.
Schedule for a quiet hour
Backups work the server hard. Early morning is usually the least disruptive time for both your visitors and your host.
Look at the Details screen once
The list of the fifty largest files in an archive tells you immediately why a backup is bigger than expected — usually a forgotten folder of video or old downloads that need not be backed up weekly at all.
Glance at the logs occasionally
Automatic backups fail silently. A brief look every few weeks — or the dashboard tile from section 10 — is what stops a three-month gap going unnoticed.
Keep more than you think you need
Some problems are not noticed for days — a hack, a bad edit, quietly corrupted content. Only having yesterday's backup means only being able to restore the problem. A run of ten gives you somewhere to go back to.

What it does not do

Stated plainly, so nothing surprises you at a bad moment.

  • No automatic offsite copies. Archives are written to your own server. Sending them to cloud storage or another machine is currently your job — and worth doing.
  • Every backup is a full backup. There is no incremental mode that saves only what changed, so each archive is roughly the size of your site.
  • Restores cannot be undone or rolled back. If one fails part-way, the site is left in a mixed state. This is why taking a fresh backup first matters.
  • External paths are archived but never put back automatically — see section 7.
  • Deleting an archive leaves its history entry behind. The Logs list can mention backups that are no longer on disk. Harmless, but worth knowing so it does not confuse you.
  • Failure emails do not catch a run that is killed outright. If the server runs out of time or memory mid-backup, the run stops without failing, so no email is sent and the entry stays on Running. Watch the dashboard tile as well — see section 9.
  • MySQL and MariaDB only. PostgreSQL is not supported.
  • One site per installation. There is no multi-site management.
In short

Run backups automatically, keep several, store them where the public cannot reach them, keep a copy somewhere other than the server, and restore one onto a test site at least once so you know it works. Do those five things and you are in a genuinely good position.