The front-end backup feature is intended to provide the capability to perform an unattended, scheduled backup of your site.

The front-end backup URL performs a single backup step and sends a redirection (HTTP 302) header to force the client to advance to the next page, which performs the next step and so forth. You will only see a message upon completion, should it be successful or not. There are a few limitations, though:

We VERY STRONGLY recommend using the Front-End Backup feature only with sites configured to use HTTPS with a properly signed SSL certificate for security reasons: plain HTTP sites and self-signed HTTPS certificates can, under certain circumstances, lead to your Secret Word leaking. If a malicious user obtains the Secret Word they can launch a Denial of Service attack on your site and / or abuse Akeeba Backup's feature to obtain a copy of your site, including all privileged information. Getting a properly signed SSL certificate no longer costs any money. The Let's Encrypt certificate authority offers free of charge SSL certificates. Most likely your hosting control panel already supports automatically acquiring and installing SSL certificates from Let's Encrypt. For example two of our favorite hosts, SiteGround and Rochen, have supported this since late 2015. If you are not sure, ask your host. Using HTTPS not only makes your site safer, it will even make it more popular with search engines. It's a win-win proposition!

Before beginning to use this feature, you must set up Akeeba Backup to support the front-end backup option. First, go to Akeeba Backup's main page and click on the Options button in the toolbar. Find the option titled Enable front-end and remote backup and set it to Yes. Below it, you will find the option named Secret key. In that box you have to enter a password which will allow your CRON job to convince Akeeba Backup that it has the right to request a backup to be taken. Think of it as the password required to enter the VIP area of a night club. After you're done, click the Save & Close button on top to save the settings and close the dialog.

Most hosts offer a CPanel of some kind. There has to be a section for something like "CRON Jobs", "scheduled tasks" and the like. The help screen in there describes how to set up a scheduled job. One missing part for you would be the command to issue. Simply putting the URL in there is not going to work.

If you are on a UNIX-style OS host (usually, a Linux host) you most probably have access to a command line utility called wget. It's almost trivial to use:

wget --max-redirect=10000 "http://www.yoursite.com/index.php?option=com_akeebabackup&

view=Backup&key=YourSecretKey"

Of course, the line breaks are included for formatting clarity only. You should not have a line break in your command line!

Do not miss the --max-redirect=10000 part of the wget command! If you fail to include it, the backup will not work with wget complaining that the maximum number of redirections has been reached. This is normal behavior, it is not a bug.

YourSecretKey must be URL-encoded. You can use an online tool like http://www.url-encode-decode.com or simply consult the Schedule Automatic Backups page.

Do not forget to surround the URL in double quotes. If you don't the backup will fail. The reason is the way operating systems parse command lines. Special characters such as question marks and ampersands have special meanings.

If you're unsure whether your command line makes sense please check with your host. Sometimes you have to get from them the full path to wget in order for CRON to work. For example:

/usr/bin/wget --max-redirect=10000 "http://www.yoursite.com/index.php?option=com_akeebabackup&

view=Backup&key=YourSecretKey"

Again, please do contact your host; they usually have a help page for all this stuff. Read also the section on CRON jobs below.

Optionally, you can also include an extra parameter to the above URL, &profile=profile_id, where profile_id is the numeric ID of the profile you want to use for the backup. If you don't specify this parameter, the default backup profile (ID=1) will be used. In this sense, the aforementioned URL becomes:

/usr/bin/wget --max-redirect=10000 "http://www.yoursite.com/index.php?option=com_akeebabackup&

view=Backup&key=YourSecretKey&profile=profile_id"

wget is multi-platform command line utility program which is not included with all operating systems. If your system does not include the wget command, it can be downloaded at this address: http://wget.addictivecode.org/FrequentlyAskedQuestions#download. The wget homepage is here: http://www.gnu.org/software/wget/wget.html. Please note that the option --max-redirect is available on wget version 1.11 and above. If you are on an incredibly outdated server with wget version 1.10 and earlier the backup will most probably result into an error message concerning the maximum redirections limit being exceeded. This is not a bug in our software, it's a limitation of an ancient version of the third party wget software. Kindly note that version 1.11 which lifts that limitation was released ages ago, in 2008 (two thousand eight!) to be more precise.

We would like to note that some SEO or SEF URL extensions for Joomla! may get in the way of front-end backups, especially on multi-language sites. If you get inexplicable 403 or 404 errors towards the beginning of a front-end backup right after a redirection (HTTP code 301, 302 or 307) please consult with the developers of the SEO / SEF URL extensions you are using. Usually you can add an exception for Akeeba Backup's front-end backup URLs.

Furthermore, some hosts with very finicky web server firewalls may automatically block the front-end backup URL. Typically you get a 403 error at the very beginning of the backup process or after 2-3 redirections (at which point the front-end backup will no longer work). This typically happens when they misunderstand the front-end backup Secret Word as a security threat. Try changing your Secret Word to something else. If the problem persists please contact your host and ask them to take a look and add an exception for the front-end backup Secret Word you are using.

Using webcron.org to automate your backups

Assuming that you have already bought some credits on webcron.org, here's how to automate your backup using their service.

First, go to Akeeba Backup's main page (Control Panel) and click on the Options button in the toolbar. Find the option titled Enable front-end and remote backup and set it to Yes. Below it, you will find the option named Secret key. Type in a secret key. We strongly recommend using only alphanumeric characters, i.e. 0-9, a-z and A-Z. For the sake of this example, we will assume that you have entered ak33b4s3cRet in that field. We will also assume that your site is accessible through the URL http://www.example.com.

Log in to webcron.org. In the CRON area, click on the New Cron button. Here's what you have to enter at webcron.org's interface:

Now click on Submit and you're all set up!

A PHP alternative to wget

As user DrChalta pointed out in a forum post, there is an alternative to wget, as long as your PHP installation has the cURL extension installed and enabled. For starters, you need to save the following PHP script as backup.php somewhere your host's cron feature can find it. Please note that this is a command-line script and needn't be located in your site's root; it should be preferably located above your site's root, in a non web-accessible directory.

The script below is a modification over DrChalta's original script, taking into account changes made in later versions of our software. In order to configure it for your server, you only have to change the first three lines.

<?php
define('SITEURL', 'http://www.example.com'); // Base URL of your site
define('SECRETKEY', 'MySecretKey'); // Your secret key
define('PROFILE',1); // The profile's ID

// ====================== DO NOT MODIFY BELOW THIS LINE ======================
$curl_handle=curl_init();
curl_setopt($curl_handle,CURLOPT_URL,
SITEURL.'/index.php?option=com_akeebabackup&view=Backup&key='.
SECRETKEY.'&profile='.PROFILE);
curl_setopt($curl_handle,CURLOPT_FOLLOWLOCATION,TRUE);
curl_setopt($curl_handle,CURLOPT_MAXREDIRS,10000); # Fix by Nicholas
curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER,1);
$buffer = curl_exec($curl_handle);
curl_close($curl_handle);
if (empty($buffer))
    echo "Sorry, the backup didn't work.";
else
    echo $buffer;
?>

Where www.yoursite.com and YourSecretKey should be set up as discussed in the previous section.

The ampersands above should be written as a single ampersand, not as an HTML entity (&).

In order to call this script with a schedule, you need to put something like this to your crontab (or use your host's CRON feature to set it up):

0 3 * * 6 /usr/local/bin/php /home/USER/backups/backup.php

Where /usr/local/bin/php is the absolute path to your PHP command-line executable and /home/USER/backups/backup.php is the absolute path to the script above.

If you set up your cron schedule with a visual tool (for example, a web interface), the command to execute part is "/usr/local/bin/php /home/USER/backups/backup.php".

Thank you DrChalta for this wonderful tip!

Using the front-end backup in SiteGround and other hosts using cURL instead of wget

As one of our users pointed out in the support forum, finding the correct command to issue for the CRON job is tricky. What he writes applies not only to his host, SiteGround, but many other commercial hosts as well. We'll simply quote our user, bzcoder.

In the CPanel for SiteGround there is a cronjob option, you create a cronjob using that and use:

curl -b /tmp/cookies.txt -c /tmp/cookies.txt -L --max-redirs 1000 -v "<url>"

as your command.

Replace <url> with your backup URL. Make sure to use the initial url displayed on the backend NOT the final URL when you run the backup manually (been there, done that) - when you do that you end up with a url that doesn't work because of the extra parameter used in continuing the backup process.

The Akeeba Remote JSON API was designed for use with our own software: Akeeba Remote CLI and Akeeba UNiTE.

There are third party services which interface with Akeeba Backup to automate backing up your sites. These services are not affiliated with Akeeba Ltd and we cannot provide support for them, as noted in the introduction section of this chapter.

There are three discrete versions of the Akeeba Remote JSON API:

As noted above, Akeeba Backup for Joomla only supports the v2 and v3 Akeeba Remote JSON API. If you are using an older version of our software, or a third party software or service, which only supports the v1 API you will to upgrade, or ask the third party vendor for an upgrade.

We very strongly recommend that you use the JSON API over HTTPS connections. On most servers you can install an SSL certificate from Let's Encrypt at no additional cost. Please consult your host.

Things you should know:

Classic v2 Endpoint (using code in Akeeba Backup)

To enable the classic v2 endpoint you need to go to Components, Akeeba Backup for Joomla, click the Options button in the toolbar, then select the Frontend tab. In there, set Enable JSON API (remote backup) to Yes. Then click on Save & Close.

Back in the Akeeba Backup Control Panel, our software will check to see if you have a non-empty Secret Key and if it meets the minimum complexity criteria for security purposes. If it does not, you will be shown the message “The front-end and remote backup features are disabled”. Click on it to expand it, then click on the Apply the suggested Secret Key button to apply the automatically generated Secret Key.

The classic endpoint is https://www.example.com/index.php?option=com_akeebabackup&view=Api&format=raw where https://www.example.com is the full URL to your site's front page. Akeeba software which implements the JSON API (Akeeba Remote Control and Akeeba UNiTE) can only be given the full URL to your site; they will figure out the rest of the URL automatically.

The secret key for using the classic v2 endpoint can be found by going to Components, Akeeba Backup for Joomla, clicking the Options button in the toolbar, then selecting the Frontend tab. You can read your secret key in the Secret Key option.

New v2 Endpoint (using the Joomla API Application and the Akeeba Backup Secret Key for authentication)

This endpoint is available on Joomla 4.2.0 and later versions, using Akeeba Backup 9.6.0 and later versions.

To enable the new v2 endpoint, first go to System, Manage, Plugins and enable the Web Services - Akeeba Backup plugin. This should normally be enabled automatically when you install or update Akeeba Backup.

Then, go to Components, Akeeba Backup for Joomla, click the Options button in the toolbar, then select the Frontend tab. In there, set Enable JSON API (remote backup) to Yes. Then click on Save & Close.

Back in the Akeeba Backup Control Panel, our software will check to see if you have a non-empty Secret Key and if it meets the minimum complexity criteria for security purposes. If it does not, you will be shown the message “The front-end and remote backup features are disabled”. Click on it to expand it, then click on the Apply the suggested Secret Key button to apply the automatically generated Secret Key.

The new v2 endpoint is https://www.example.com/api/index.php/v2/akeebabackup where https://www.example.com is the full URL to your site's front page.

The secret key for using the classic v2 endpoint can be found by going to Components, Akeeba Backup for Joomla, clicking the Options button in the toolbar, then selecting the Frontend tab. You can read your secret key in the Secret Key option.

v3 Endpoint (using the Joomla API application and Joomla's API authentication)

This endpoint is available on Joomla 4.2.0 and later versions, using Akeeba Backup 9.6.0 and later versions.

To enable the v3 endpoint, first go to System, Manage, Plugins and enable the Web Services - Akeeba Backup plugin. This should normally be enabled automatically when you install or update Akeeba Backup.

To enable the Joomla API authentication using a secure token, as long as you are a Super User, you need to go to to System, Manage, Plugins and enable the API Authentication - Web Services Joomla Token plugin. Then go to User Menu at the top of the backend page, Edit Account, and click on the click on the Joomla API Token tab. Make sure Active is set to Yes and click on Save & Close.

The new v3 endpoint is https://www.example.com/api/index.php/v3/akeebabackup where https://www.example.com is the full URL to your site's front page.

The token required to use the v3 API (and theJoomla API Application in general) is in your user settings as long as you are a Super User. go to User Menu at the top of the backend page, Edit Account, and click on the click on the Joomla API Token tab. The Token field has a Copy button; this is the API token you need to use to connect to the Joomla API Application.

Support for backup issues when using the Akeeba Remote JSON API

If you are using Akeeba Remote CLI or Akeeba UNiTE and qualify for support according to our Terms of Service we can provide substantial but not unlimited assistance. We can identify whether your connection information is correct (or let you know how to correct it). Moreover, we can determine whether the problem is with our software or outside or of our control. In the first case we will identify the issue in our software and fix it. In the latter case we will tell you our analysis, where we believe the problem lies to, produce evidence that the backup can be run from our computers or servers and try to point you to the correct direction for resolving the issue that's not coming from our software itself.

When it comes to third party services, please remember that we can't provide a lot in the way of support as we are not affiliated with these third party businesses, nor do we have control over their servers and networks. The only thing we can do is make sure that we can connect to your site from our computers and/or servers using Akeeba Remote CLI and a Secret Key generated by our software — we will ask for access to your site's backend as a Super User to do that. Upon successful connection and if the issue is about a backup we will try to take a backup. If these steps succeed we will let you know that the issue is not something in our software, and we will have to unfortunately decline providing any further assistance including any insight, deduction, or speculation of what might be the problem due to the litigious nature of some third party service operators.

If you have access to the command-line version of PHP, Akeeba Backup Professional includes an even better - and faster - way of scheduling your backups. The CLI command can be executed from the command-line PHP interface (PHP CLI) using the Joomla CLI Application. It doesn't require the front-end backup in order to work; it is a native backup solution for your Joomla!™ site, even if your web server is down.

In order to schedule a backup, you will have to use the following command line to your host's CRON interface:

/usr/local/bin/php /home/USER/webroot/cli/joomla.php akeeba:backup:take

where /usr/local/bin/php is the path to your PHP CLI executable and /home/USER/webroot is the absolute path to your web site's root. You can get this information from your host.

The backup command accepts three optional parameters:

The command will return a different exit code, depending on the backup status. When the backup is successful and without warnings, the exit code will be 0. When the backup completed but with warnings, the exit code will be 1. Finally, if the backup fails, the exit code will be 2. This allows you to check the backup status, for example inside a shell script, for automation purposes.

In order to give some examples, I will assume that your PHP CLI binary is located in /usr/local/bin/php - a common setting among hosts - and that your web site's root is located at /home/johndoe/httpdocs.

It goes without saying that the line breaks are for readability only. You should not include line breaks in your command line.

Special considerations:

Setting up a CRON job on cPanel

Go to your cPanel main page and choose the CRON Jobs icon from the Advanced pane. In the Add New CRON Job box on the page which loads, enter the following information:

Finally, click the Add New Cron Job button to activate the CRON job.

CLI backups on restrictive hosts

Some hosts, especially shared hosting environments, have a maximum CPU usage time limit per process. If your backup takes longer to complete — including any uploading of the backup archives to remote storage — than this time limit the backup process will be terminated prematurely by your host. The log file will show no error but it will also not show that the backup is complete.

There are two ways to resolve that.

Option 1: Talk to your host (hardest to do, faster backups).

Ask your host to increase the maximum CPU usage limit to a higher value that's enough for your backup to run. How much is that? Take a backup from the backend of your site. Go to the Manage Backups page. Read the Duration of the backup and add 15% to it. For example, if the backup took 1 hour 13 minutes and 42 seconds (a total of 4422 seconds) you need to tell your host to increase the CPU usage time limit to at least 5085 seconds.

Please note that this may impossible to explain to first level support techs. If they seem to misunderstand you and start talking about the PHP time limit (something completely different) ask for your ticket to be escalated to a second level support tech. You can tell the second level support tech that the issue is with the ulimit -t which is applied to your CRON jobs. They should be able to either raise the hard limit or tell you how to modify your CRON job command line to set a higher soft limit. It's okay if you do not understand what that means; the second level tech does and will be able to help you.

Option 2: Use Joomla's Scheduled Tasks (easiest to do, slower backups).

Use Joomla's Scheduled Tasks with the CLI scheduling option. When choosing the task type select the “Akeeba Backup – Take a Backup”.

This method is slower than taking a backup with the native CRON script but it works around the maximum CPU usage time limit your host has applied by spreading the backup execution across multiple executions of the backup task. In this case do keep in mind that unlike the native CRON script you MUST set up Joomla's Scheduled Task CRON job to run every minute, NOT just at the desired backup time. You can control the backup time and frequency of the backups from Joomla itself (System, Manage, Scheduled Tasks).

Please note that when you go for this option you can no longer override configuration variables.

Overriding configuration variables

You can override or supply missing configuration variables in the command line. This is especially useful for security reasons. One security issue with the cloud storage service integration is that other Super Users can peek at Akeeba Backup's configuration and read the username, password or API keys used to access the cloud storage service. You can, however, leave these fields blank in the configuration and supply their values in the command line.

Overriding a configuration variable requires knowing its key name. The key names are represented in dot-format, i.e. engine.postproc.s3.accesskey for Amazon S3's access key. Determining the key name is quite easy, as they are stored in JSON files throughout the component's back-end. The first location you should look at is administrator/components/com_akeebabackup/engine/core, where you will find four JSON files with general settings. Inside the administrator/components/com_akeebabackup/engine subdirectories you will find one JSON file per engine.

If you are using Akeeba Backup Professional you will find more JSON files under the administrator/components/com_akeebabackup/platform/Joomla/Config directory. These files include some of the features only available in the Professional version of the software.

In order to save you from trouble, here are the most useful key names. The names are designed to be self-explanatory.

For your information, the configuration keys for cloud storage services can be found in the .json files under administrator/components/com_akeebabackup/engine/Postproc.

Applying them on the command line is easy. Take this command line as an example:

usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:take
--profile=2 --description="My automated backup"
--override="engine.postproc.s3.accesskey=ABCDEF"
--override="engine.postproc.s3.secretkey=1234567890abcdefgh"

In this case, we are telling the backup script to use the backup Profile with ID=2, give the backup description of "My automated backup" and then supply the S3 access and secret keys. The values of the override parameters must be enclosed in double or single quotes (depends on your Operating System), otherwise the operating system will not pass them back to the backup.php script. Do note that your command line MUST NOT include the line breaks in the previous example. The line breaks are there only for typesetting purposes.

Finally, it should be noted that you can use the command-line override feature to do more tricky configuration overrides, for example turning off the archive splitting or using a different backup output directory to enhance your security. If it's something you can do in the Configuration page of the component, you can also do it using command line overrides.

This command uses the front-end backup feature of Akeeba Backup to run a backup. This may work on some hosts where the regular CRON script doesn't.

As already stated in the Front-End Backup feature, we VERY STRONGLY recommend using the Front-End Backup feature -including the case where it's used by the alternative CRON script- only with sites configured to use HTTPS with a properly signed SSL certificate for security reasons: plain HTTP sites and self-signed HTTPS certificates can, under certain circumstances, lead to your Secret Word leaking even if you are only using it with the alternative CRON script. If a malicious user obtains the Secret Word they can launch a Denial of Service attack on your site and / or abuse Akeeba Backup's feature to obtain a copy of your site, including all privileged information. Getting a properly signed SSL certificate no longer costs any money. The Let's Encrypt certificate authority offers free of charge SSL certificates. Most likely your hosting control panel already supports automatically acquiring and installing SSL certificates from Let's Encrypt. For example two of our favorite hosts, SiteGround and Rochen, have supported this since late 2015. If you are not sure, ask your host. Using HTTPS not only makes your site safer, it will even make it more popular with search engines. It's a win-win proposition!

You will have to a command line similar to this with your host's CRON interface:

/usr/local/bin/php /home/USER/webroot/cli/joomla.php akeeba:backup:alternate

where /usr/local/bin/php is the path to your PHP CLI executable and /home/USER/webroot is the absolute path to your web site's root. You can get this information from your host.

The backup script accepts the following optional parameters:

In order to give some examples, we will assume that your PHP CLI binary is located in /usr/local/bin/php - a common setting among hosts - and that your web site's root is located at /home/johndoe/httpdocs.

It goes without saying that the line breaks are for readability only. You should not include line breaks in your command line.

Special considerations:

If you are seeking assistance regarding a failed CRON job please indicate if and which of these steps you have already tried. We don't want to ask you to do something you've already tried.

Akeeba Backup is a component which takes backup when someone or something tells it to do so. Automating backups is all about having something tell Akeeba Backup when to take a backup at a predefined time, as well as keep telling it to step through the backup until the backup is done. We can call this the “execution controller”.

In the previous sections we have covered different ways this can be done: using a native CLI CRON job; using your host's or a third party's scheduler which accesses a special URL; or using a CLI CRON job which accesses a special URL. There is also the possibility of using a third party service, Akeeba UNiTE or Akeeba Remote Control CLI using the JSON API.

All of these methods require an execution controller external to your site. While this is the best way to run something complex and long running — like a backup — it is not the only way. Joomla 4.1.0 and later have a feature called Scheduled Tasks which allows you to set up stuff to run on a schedule which you define and modify within Joomla itself. In its turn, the Scheduled Tasks feature has three execution controllers: using a native CLI CRON job; using a special URL; or using traffic on your site as the access trigger.

Akeeba Backup 9.2.0 and later offer an integration with Joomla Scheduled Tasks with two different task types, one that works with all execution controllers and another one which only works with the CLI execution controller. Please make sure to read the next two sections which explain the differences between the two task types and the caveats from using Joomla Scheduled Tasks before you decide whether to use this feature.