Support

Documentation

Automating your backup

Taking backups automatically

Why you need scheduled backups

Akeeba Backup is an excellent tool for taking backups of your site every time you want to transfer it to a different server, are ready to make substantial changes to it (like upgrading Joomla) or are about to or have just made changes to it. This way is something goes wrong you can easily roll back to the last known state of your site. The corollary to that is that if your backups are too far in between they might not encompass all useful changes to your site, leading to lost work and frustration.

This poses two concerns, depending on the type of site you have. If you have an infrequently changing site (low traffic blog, company presentation, organization bulletin board, ...) it takes a lot of self-discipline to take backups every time something changes, something that's not a given when you have multiple people managing a site. If you have a fast changing site (such as an e-commerce site, a busy blog with loads of comments, a community / forum site etc) you'd have to frequently log into your site and take backups, probably multiple times a day. This is admittedly time-consuming and boring. In the end of the day you might skip a few or a lot of backups and that could prove detrimental to your ability to rescue your site should things go awry.

The solution to that is scheduling your backups, i.e. having backups being taken automatically, at regular intervals. This is not something that will happen without any intervention by you, the site owner. Backups take too long to run in a single page load and need your site to maintain a fairly consistent state throughout the backup. Therefore having traffic to the site trigger the backups is a bad idea as it's neither guaranteed to come at the right frequency and quantity to guarantee a backup when you'd like it to happen, nor does it guarantee a consistent state, by definition (people accessing your site may indeed cause things to change). Ideally, your backups should run when your site experiences the least amount of traffic. If you're not sure when: check your hosting control panel's traffic logs and look for the time of the day you receive the lowest number of requests. From that, it should be fairly obvious that you need something else to trigger the backup.

An overview of scheduling methods

Akeeba Backup offers several options which are explained further below in this section of the documentation. This is a quick overview which will let you pick a method suitable for your site.

The first group of methods are designed to run on the same server as your site.

Depending on your hosting company you might be able to use CRON jobs. This is the preferred option. True CRON jobs allow you to run custom scripts or commands accessible from the command line (CLI) at regular intervals. However, some hosts may limit the amount of time CRON jobs are allowed to run. If this time is less than the time it takes to run a backup this method is unsuitable for you. If you're not sure how long the backup takes: take a backup from the back-end of your site, go to the Manage Backups page and look at how long it took to run it. You can use the Native CRON Script and the Alternative CRON Script with this method.

On other servers you might be able to use pseudo-CRON jobs. In this case you can tell your host to access a specific URL at regular intervals. Please ask your host whether their pseudo-CRON follows HTTP redirections and if it does, whether it has a limit of redirections followed. If they answer that they do not follow HTTP redirections or that they impose a limit of redirections followed you cannot use this method. Furthermore, the time limits explained in the previous paragraph apply.

If the previous methods which rely on your own server are not suitable for your site, Akeeba Backup does offer two alternatives.

The first alternative is the Front-end Legacy Backup API. You can use a special URL with third party CRON services which follow HTTP redirections and do not impose a limit of redirections followed such as WebCRON or even a shell script using wget, curl or something similar on any server or Internet connected computer under your control. For example, you could set up a CRON job on your Linux machine, a Scheduled Task on your Windows computer or even have a Raspberry Pi or your NAS access that URL. If you use a third party service to trigger the backups be advised that they charge fees which are usually pretty low.

The second alternative is the Akeeba Backup Remote JSON API. This is a more advanced way of taking backups remotely. It is used in two distinct cases. First, in conjunction with our remote backup software, namely Akeeba Remote CLI and Akeeba UNiTE. These can be used to schedule taking backups remotely and, in the case of UNiTE, restoring them on a computer under your control as well. Second and most common, with a third party service that can schedule and take remote backups using Akeeba Backup's Remote JSON API such as BackupMonkey or Watchful. Third party services charge fees according to their commercial policy.

Availability of scheduling methods

Backup scheduling features are only available in Akeeba Backup Professional, our for-a-fee edition. They are not included in Akeeba Backup Core, our free of charge edition.

The target audience of Akeeba Backup Core has always been the small, hobbyist site owner and those who need a relatively easy way to transfer their sites between servers. This target audience does not need backup scheduling, either because their sites change too infrequently or because they perform one-off backups for site transfers.

If you find yourself with a site that changes often enough to warrant automatic backups we kindly ask you to consider an Akeeba Backup Professional subscription. There are several good reasons to do so. For starters, a site valuable enough to warrant automatic backups should also have these backups stored off-site, a feature exclusive to the Professional edition. Moreover, your small investment in Akeeba Backup Professional will save you copious amounts of time and money should something go awry. Furthermore you will have access to our acclaimed support, provided by the same developers writing the software, should you have any issue using it. It's worth noting that if you are a web professional you only need one subscription for unlimited sites, including those of your clients. Finally, by purchasing an Akeeba Backup Professional subscription you are financing the painstaking and expensive research, development and maintenance that goes into Akeeba Backup – thank you for making this software possible!

Scheduling backups

Each available backup method has a different way of scheduling. This documentation section explains in detail how each method works and how you can schedule it.

You should also go to Akeeba Backup's Schedule Automatic Backups page. You will get a condensed version of these instructions, specialized -to the degree possible- for your own site and the currently active backup profile. Trust us, this page will save you a lot of headache. In fact, it's what we reference on our own sites.

Front-end backup, for use with CRON

[Tip]Tip

This feature is only available in Akeeba Backup Professional.

Requires the Enable Legacy Front-end Backup API (remote CRON jobs) option to be enabled in the component's Options, Frontend tab.

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:

  • It is not designed to be run from a normal web browser, but from an unattended cron script, utilizing wget or cron as a means of accessing the function.

  • The script is not capable of showing progress messages.

  • Normal web browsers tend to be "impatient". If a web page returns a bunch of redirection headers, the web browser thinks that the web server has had some sort of malfunction and stop loading the page. It will also show some kind of "destination unreachable" message. Remember, these browsers are meant to be used on web pages which are supposed to show some content to a human. This behaviour is normal. Most browsers will quit after they encounter the twentieth page redirect response, which is bound to happen. Do not report a "bug" stating that Firefox, Internet Explorer, Chrome, Safari, Opera or another browser doesn't work with the front-end backup feature. It was NOT meant to work by design and you've been sufficiently warned.

  • Command line utilities, by default, will also give up loading a page after it has been redirected a number of times. For example, wget gives up after 20 redirects, curl does so after 50 redirects. Since Akeeba Backup redirects once for every step, it is advisable to configure your command line utility with a large number of redirects; about 10000 should be more than enough for virtually all sites.

[Tip]Tip

If you want to automate your backups despite your host not supporting proper CRON jobs you can use a third party service, such as Webcron.org. Just make sure you set up the time limit to be at least 10% more than the time it takes for Akeeba Backup to backup your site. Don't know how much is that? Just take a regular backup from your site's back-end, then go to the Manage Backups page and take a look at the Duration column.

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.

[Tip]Tip

Use only lower- and upper-case alphanumeric characters (0-9, a-z, A-Z) in your secret key. Do not use symbols, accented characters, non-Latin character sets (like Green or Cyrillic letters) etc. Such characters may need to be manually URL-encoded in the CRON job's command line. This is error prone and can cause the backup to never start even though you'll be quite sure that you have done everything correctly.

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.

[Warning]Warning

If your host only supports entering a URL in their "CRON" feature, this will most likely not work with Akeeba Backup. There is no workaround. It is a hard limitation imposed by your host: they do NOT follow redirections. In these cases you can schedule a CRON job on your own computer. The downside is that your computer will need to be powered on (not turned off or even in sleep / hibernate) at the time you've set up the backup to run and for the entire length of time it take to run the backup.

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.

[Warning]Warning

The ampersands above should be written as a single ampersand, not as an HTML entity (&). Failure to do so will result in a 403: Forbidden error message and no backup will occur. This is not a bug in our software, it's how the Internet works.

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:

  • Name of cronjob: anything you like, e.g. "Backup www.example.com"

  • Timeout: 180sec; if the backup doesn't complete, increase it. Most sites will work with a setting of 180 or 600 here. If you have a very big site which takes more than 5 minutes to back itself up, you might consider using Akeeba Backup Professional and the native CRON script (akeeba-backup.php) instead, as it's much more cost-effective.

  • Url you want to execute: http://www.example.com/index.php?option=com_akeebabackup&view=backup&key=ak33b4s3cRet

  • Login and Password: Leave them blank

  • Execution time (the grid below the other settings): Select when you want your CRON job to run

  • Alerts: If you have already set up alert methods in webcron.org's interface, we recommend choosing an alert method here and not checking the "Only on error" so that you always get a notification when the backup CRON job runs.

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 (&amp;).

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.

Remote JSON API

[Tip]Tip

This feature is only available in Akeeba Backup Professional.

Requires the Enable JSON API (remote backup) option to be enabled in the component's Options, Frontend tab.

[Important]Important

Akeeba Backup 9.0 and later only includes support for the Akeeba Backup JSON API version 2 (API level 400). If the service or software you are using only supports the version 1 API you will need to ask them to update their service or use a newer version of the software you are using.

This feature is designed to let third party services and software take and optionally download backups of your site remotely (from any computer or a server other than the one your site is hosted on). This API is currently used by popular Joomla management and backup scheduling services such as Backup Monkey and Watchful.

The JSON API uses optional encryption to ensure confidentiality of the API calls even on plain HTTP sites. However, 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:

  • It is not designed to be run from a web browser, but from an application or service which understands the API.

  • The API is available through the Akeeba Backup component which runs inside Joomla. While we take reasonable precautions, third party plugins may interfere with it. These problems are very rare.

  • Since it's running over the web it is subject to the PHP and web server timeout limits. Make sure your backup runs to completion through the back-end of your site before using the JSON API. If your backup fails through the back-end it will definitely fail through the JSON API as well.

  • Since it's running over the web your host may intercept, alter or block the requests to the JSON API and its replies. If that happens taking a backup will be impossible or may terminate before it is complete. In this case please contact your host. They should be able to determine why they interfered with the request and help you work around it.

  • Giving access to the Remote JSON API is not to be taken lightly. Software and services given access to your site's Akeeba Backup Remote JSON API have the authority to see information about your past backups, get information about the version and update availability of Akeeba Backup, read and modify your backup settings (including remote storage services' access information), take backups and download backup archives. Only give access to services and software you trust.

  • Downloading a backup archive through the JSON API is by no means guaranteed to work. It largely depends on the size of the backup archive and your host. Our advice to third party services and software is to always offer an alternative for downloading the backup archives using SFTP or FTP.

  • Access to the Remote JSON API has many intermediate layer which are not under the control of Akeeba Ltd. Indicatively these are: the code which produces the request to the JSON API; the operating system and server / computer configuration where the code producing the request to the JSON API is installed in, including its firewall configuration; network connectivity between that server / computer and your site's server; your site server's firewall and system configuration; your server's web server and PHP configuration; any third party plugins running on your Joomla site. If you can take a backup through your site's back-end but not through the remote JSON API do not assume it's a bug with our software (99.9% of the times it's not). First contact the developer of the third party service or software which implements the remote backup. That's a small community, we know them and they know us. They can identify whether the problem is on their end, on your server or if it's a backup issue. If you do have a backup issue and are already a subscriber with access to Akeeba Backup's support (that is to say, you have access to Akeeba Backup Professional) please file a support ticket on our site's Support section and we will help you.

  • If you are trying to run remote backups from your own server or computer we have limited troubleshooting options for clients who qualify for support. Namely, we will try to run the backup through our own computers and servers and try to determine the root cause of the issue. If it's outside our client software or the Akeeba Backup installation on your site we can only tell you that it's not a bug in our software and tell you about what could be interfering (see the above bullet points). In this case the root cause is outside our control and we cannot reasonably be expected to resolve it.

  • Your secret key must be non-empty and meet a minimum complexity metric for this feature to be enabled. If you have not set up a secret key or if the secret key is too easy to guess the JSON API will respond with an access denied message and Akeeba Backup will display a prominent warning in its control panel page with instructions to fix it.

Setting up third party services

Each third party service has a slightly different way to set up the connection with Akeeba Backup's Remote JSON API. In most cases you install an extension on your site and the third party service can set up the connection automatically. They do so by reading the Secret Key you have set up in Akeeba Backup's Options page and using the known endpoint URL to Akeeba Backup's JSON API.

In some cases you may need to provide either or both of these pieces of information to the third party service. The set up for third party software below explains how to obtain that information.

Setting up software

Setting up software for remote backups through the JSON API requires providing either or both of the following information:

Endpoint URL: It 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.

Secret Key: This is the secret key you set up in Components, Akeeba Backup, Options, Front-end Backup tab, Secret word option. We recommend using a random, 64-character password generated with a random password generator as explained in the documentation page of the Options page of Akeeba Backup. If the secret key you provide to the third party software or service does not match the one you set up in Akeeba Backup, or if the secret key you set up in Akeeba Backup is too easy to guess (based on automated password complexity metrics) the JSON API will always respond with an access denied message.

Support for backup issues when using the JSON API for remote backups

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 we kindly ask you to always seek support with the service provider before contacting us. In many cases the problem lies with the service itself or its connection to your server. We do not have access to these third party services and cannot troubleshoot or resolve such issues. The service providers can. If you ask us to assist with such third party service issues we will have to decline support for objective reasons.

If the service provider tells you that you have a backup issue your support options are determined by the Support Policy which is part of our Terms of Service. That is to say, if you qualify for support according to our Terms of Service we can provide assistance for your backup issue with the JSON API in the same way we would provide assistance for any other backup issue.

Native CRON script

[Tip]Tip

This feature is only available in Akeeba Backup Professional.

[Important]Important

Unlike Akeeba Backup 3.x to 8.x inclusive, the CRON script is no longer a standalone PHP application. Instead, it's implemented as a command for Joomla CLI application.

First of all, you need to make sure that the Console – Akeeba Backup plugin is published and its Access is set to Public. If you do not do that, Joomla does not know about Akeeba Backup's CLI commands.

The joomla.php script you see below is part of Joomla itself, not something we have written or have any control over. This means that any code that runs before you see any output from Akeeba Backup is handled by Joomla itself, not our code. If you get an error before reaching that point you will need to file a bug report with the Joomla project which controls this code, not us (we can't fix Joomla's code).

Further to that, keep in mind that the Joomla CLI Application DOES NOT run at all under the PHP-CGI binary. It will only run under the PHP-CLI binary. Our custom CLI scripts in versions 3.x to 8.x did run under PHP-CGI, with some caveats which could cause the backups to fail with a timeout error. Therefore the Joomla CLI application may fail to run in some cases our scripts used to work. THIS IS NOT A BUG IN OUR SOFTWARE AND WE HAVE ABSOLUTELY ZERO CONTROL OVER IT. Please file a bug report with the Joomla project so they can fix it.

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:

  • --profile profile_id allows you to select which backup profile you would like to use for the scheduled backup. The profile_id is the numeric profile ID you can see in your Control Panel page.

  • --description "Your description" allows you set a backup description different than the default. Do not forget to enclose your description in double quotes, or this parameter will not work! Since Akeeba Backup 3.1 the description supports backup naming variables, e.g. [SITE], [DATE] and [TIME]. This allows you to use them in conjunction with this parameter to provide flexible backup descriptions.

  • --override "keyname=value" allows you to override profile configuration variables. This parameter can appear an unlimited number of times in the command line. It can be used, for example, to provide the username and password to your cloud storage service in the command line, without having to store it in the backup profile's configuration, therefore never storing it in database and hiding it from other administrators. Please take a look at the "Overriding configuration variables" subsection for more information.

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.

  1. Backup with the default profile (ID = 1) and default description:

    usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:take
  2. Backup with profile number 2 and default description:

    usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:take --profile=2
  3. Backup with the default profile (ID = 1) and a description reading "My automated backup":

    usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:take --description="My automated backup"
  4. Backup with profile number 2 and a description reading "My automated backup":

    usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:take --profile=2
      --description="My automated backup"

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

Special considerations:

  • All parameters must start with a double dash. If you use a single dash, they will be ignored. This is how Joomla's CLI application works, following the UNIX conventions of command line parameters.

  • Most hosts do not impose a time limit on scripts running from the command-line. If your host does and the limit is less than the required time to backup your site, the backup will fail.

  • This script is not meant to run from a web interface. If your host only provides access to the CGI or FastCGI PHP binaries or pseudo-CRON (accessing a URL on a schedule), joomla.php will not work with them. The reason is actually the same as the time constraint above.

  • Some servers do not fully support this backup method. The usual symptoms will be a backup which starts but is intermittently or consistently aborted in mid-process without any further error messages and no indication of something going wrong. In such a case, trying running the backup from the back-end of your site will work properly. If you witness similar symptoms please use the Alternative CRON Script, outlined in the next section.

Setting up a CRON job on cPanel
[Note]Note

This section depends on your host's control panel software. It is included it for informational purposes only and we cannot guarantee its accuracy. If you have questions about this please ask your host.

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:

Common Settings

Choose the frequency of your backup, for example once per day.

Command

Enter your backup command. Usually, you have to use something like:

/usr/bin/php-cli /home/myusername/public_html/cli/joomla.php akeeba:backup:take --profile=YourProfileID

where myusername is your account's user name (most probably the same you use to login to cPanel) and YourProfileID is the numeric profile number you want to use for your backup job. Do note the path for the PHP command line executable: /usr/bin/php8-cli. This is an example for the location of the correct executable file for PHP CLI. Your host may use a different path to the executable. If the command never runs, ask them. We can't help you with that; only those who have set up the server know the changes they have made to the default setup.

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.

JPS archive password
  • engine.archiver.jps.key

ANGIE password
  • engine.installer.angie.key

Amazon S3
  • engine.postproc.s3.accesskey

  • engine.postproc.s3.secretkey

Microsoft Windows Azure BLOB Storage
  • engine.postproc.azure.account

  • engine.postproc.azure.key

RackSpace CloudFiles
  • engine.postproc.cloudfiles.username

  • engine.postproc.cloudfiles.apikey

CloudMe
  • engine.postproc.cloudme.username

  • engine.postproc.cloudme.password

DreamObjects
  • engine.postproc.dreamobjects.accesskey

  • engine.postproc.dreamobjects.secretkey

Dropbox (v1 API, old)
  • engine.postproc.dropbox.token

  • engine.postproc.dropbox.token_secret

Dropbox (v2 API, new)
  • engine.postproc.dropbox2.access_token

Remote FTP server
  • engine.postproc.ftp.user

  • engine.postproc.ftp.pass

Google Drive
  • engine.postproc.googledrive.refresh_token

Google Storage
  • engine.postproc.googlestorage.accesskey

  • engine.postproc.googlestorage.secretkey

iDriveSynce
  • engine.postproc.idrivesync.username

  • engine.postproc.idrivesync.password

  • engine.postproc.idrivesync.pvtkey

OneDrive
  • engine.postproc.onedrive.access_token

  • engine.postproc.onedrive.refresh_token

Remote SFTP server
  • engine.postproc.sftp.user

  • engine.postproc.sftp.pass –– Either the password for the username specified above, or the password to the private key file

  • engine.postproc.sftp.privkey –– Absolute path to the private key file (optional, for certificate authentication)

  • engine.postproc.sftp.pubkey –– Absolute path to the public key file (optional, for certificate authentication)

SugarSync
  • engine.postproc.sugarsync.email

  • engine.postproc.sugarsync.password

WebDAV
  • engine.postproc.webdav.username

  • engine.postproc.webdav.password

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.

Alternative CRON script

[Tip]Tip

This feature is only available in Akeeba Backup Professional.

Requires the Enable Legacy Front-end Backup API (remote CRON jobs) option to be enabled in the component's Options, Frontend tab.

[Important]Important

Unlike Akeeba Backup 3.x to 8.x inclusive, the CRON script is no longer a standalone PHP application. Instead, it's implemented as a command for Joomla CLI application.

First of all, you need to make sure that the Console – Akeeba Backup plugin is published and its Access is set to Public. If you do not do that, Joomla does not know about Akeeba Backup's CLI commands.

The joomla.php script you see below is part of Joomla itself, not something we have written or have any control over. This means that any code that runs before you see any output from Akeeba Backup is handled by Joomla itself, not our code. If you get an error before reaching that point you will need to file a bug report with the Joomla project which controls this code, not us (we can't fix Joomla's code).

Further to that, keep in mind that the Joomla CLI Application DOES NOT run at all under the PHP-CGI binary. It will only run under the PHP-CLI binary. Our custom CLI scripts in versions 3.x to 8.x did run under PHP-CGI, with some caveats which could cause the backups to fail with a timeout error. Therefore the Joomla CLI application may fail to run in some cases our scripts used to work. THIS IS NOT A BUG IN OUR SOFTWARE AND WE HAVE ABSOLUTELY ZERO CONTROL OVER IT. Please file a bug report with the Joomla project so they can fix it.

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:

  • --profile profile_id allows you to select which backup profile you would like to use for the scheduled backup. The profile_id is the numeric profile ID you can see in your Control Panel page.

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.

  1. Backup with the default profile (ID = 1)

    /usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:alternate
  2. Backup with profile number 2

    /usr/local/bin/php /home/johndoe/httpdocs/cli/joomla.php akeeba:backup:alternate --profile=2

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

Special considerations:

  • Most hosts do not impose a time limit on scripts running from the command-line. If your host does and the limit is less than the required time to backup your site, the backup will fail.

  • This script is not meant to run from a web interface. If your host only provides access to the CGI or FastCGI PHP binaries, backup.php will not work with them. The solution to this issue is tied to the time constraint above. The workaround we're planning will solve both issues.

  • You must enable the front-end backup feature of your Akeeba Backup Professional instalaltion and assign a Secret Key for it. This is possible by going to the Akeeba Backup Professional's Control Panel page and clicking on the Options button on the top right corner of the toolbar.

  • Before using the alternative CRON script for the first time, or after moving your site to a new domain name and / or enabling HTTPS, you must visit the Akeeba Backup's Control Panel page at least once. This will cache the URL to your site for use by the alternative CRON script.

  • Your host must support one of the three methods used by the helper script to access your front-end backup URL:

    1. The PHP cURL module.

    2. The fopen() URL wrappers

    If none of these methods is available, the backup will fail.

  • Taking a backup with the front-end backup feature must be possible on your site. See the Discussion in the chapter about the front-end backup, especially the issues with SEO / SEF URL extensions and host firewalls.

  • Your host may have a firewall setup which doesn't allow the CRON script to access the front-end backup URL if it's launched from the same server. In this case the backup will consistently fail without a new log file being produced and without a backup entry being written to the database. You will have to contact your host so that they can allow the script to access the front-end backup URL. Do note that despite the alternative CRON script and your site running on the same server, the firewall restriction might still be in place. This is counter-intuitive, but we've seen this happening on a few hosts.

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.

Joomla Scheduled Tasks (without CLI)

[Note]Note

This feature is only available on Joomla 4.1.0 and later. Make sure the plugin Task - Akeeba Backup is published.

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.

The two Akeeba Backup task types

The Task - Akeeba Backup plugin makes two task types available to you:

Akeeba Backup – Take a Backup

This is the regular backup task type which works with all three execution controllers for Joomla Scheduled tasks (lazy, URL and CLI). Technically speaking it is a “resumable” task, meaning that it will do some work and notify Joomla that it's pausing for now. Joomla will note that down along with the fact that it needs to resume this task at the first opportunity. Depending on how many other tasks you have scheduled, their priority and when the execution controller is triggered it may take a while until the task is resumed and the backup continues. Rinse and repeat until the backup is done.

While this can be used to take backups using the lazy scheduling offered by Joomla Scheduled Tasks it MAY cause backup consistency issues, backups may run at odd times or not at all, backups may take an unrealistic amount of time to run and so on and so forth. Please read the DANGER AHEAD section below to understand all the risks you are taking by using this scheduled task.

We consider this backup method to only be suitable for small to medium-sized sites with a fairly steady flow of traffic which does not cause major changes in the database or file content e.g. news sites, blogs and the like. If you have a high value, high traffic, high rate of change site such as an e-commerce site or a community site we VERY STRONGLY RECOMMEND AGAINST USING JOOMLA SCHEDULED TASKS TO TAKE A BACKUP. The only realistic options for you are native CLI CRON jobs, the URL CRON jobs, third party services / remote JSON API backups and maybe the CLI-only Scheduled Task type.

Akeeba Backup – CLI-only Backup

Unlike the previous task type, this backup task will run start to finish without pausing. As a result this will only run when using the CLI execution controller for Joomla Scheduled Tasks. This is on purpose! Only under CLI are we confident there are no execution time limits which could be of concern.

You might wonder, why use this task type instead of a native CLI CRON job? Well, there are pros and cons.

On one hand, using this type of Joomla Scheduled Task means you can control its execution schedule and / or disable it from within Joomla itself, without having to mess with your host's CRON jobs after you've set them up.

On the other hand, the only option you can choose is the backup profile to use when taking a backup. You have none of the other options, including configuration overrides and the description and comment customisation you have with the native CLI CRON job.

We consider this task type as a useful tool for an advanced site integrator to allow their clients to exercise a modicum of control over the backup schedule, or as a tool to be used for convenience purposes. If you want the full power of the CLI CRON jobs use that feature instead.

DANGER AHEAD: Caveats on using Joomla Scheduled Tasks.
Start of execution is fuzzy and unreliable

First and foremost, the Joomla Scheduled Tasks feature does not have the scheduling resolution you get from real CRON jobs. A real CRON job service — either the one built into your server's operating system or an external, third party one — has a resolution of a few seconds. This means that scheduled tasks will always run on the scheduled time give or a take a few seconds. Joomla's Scheduled Tasks have a resolution which can be several hours depending on which execution controller you are using:

  • Lazy Scheduling. This is triggered by traffic to your site and at most once in as many seconds as you set up in System, Scheduled Tasks, Options, Lazy Scheduler, Request Interval. The default is 300 seconds, meaning you only get to execute one task (or one partial task) every 5 minutes. If you have a steady flow of traffic your backups may start several minutes after you have scheduled them. If you don't have a steady flow of traffic your backups may start hours later, or not at all.

  • URL (“Web Cron”) or CLI: this only triggers the execution whenever you access the special URL or run the CLI CRON job for Joomla's Scheduled Tasks. The maximum resolution you can do by scheduling the execution of these execution controllers is one minute. This means that your backups may start several minutes after you have scheduled them.

Joomla Scheduled tasks are sequential, not parallel

Moreover, unlike real CRON jobs which run in parallel, Joomla Scheduled Tasks run sequentially. This means that depending on the number of scheduled tasks you have defined, their schedule and their priority it is possible that the backup task does NOT start / does NOT resume the very first time the Joomla Scheduled Tasks execution controller is triggered. It may take several triggers of the execution controller to circle back to the pending backup scheduled task. In fact, it is possible to come to a scheduling situation where the backup NEVER starts or NEVER finishes. This CAN be worked around when using the URL or CLI CRON job execution controller; it can NOT be worked around when you are using the lazy backup scheduling.

The combination of the previous two issues may lead to backups taking forever or not finishing at all

The next thing to note is that backups do not run start to finish, they run in small chunks of work. This is intentional. A backup can be a very long operation which may last from a dozen seconds on small sites hosted on really fast servers to several hours for big sites and/or sites hosted on slower hosts. When accessing a URL you are executing a PHP script which is subject to limits: the PHP execution time limit, the PHP memory limit, the web server time limit waiting for PHP to send it an indication on whether the script has finished running, the maximum CPU usage time per process controlled by your server's operating system etc. The only way to work around these limits is split the backup process in smaller chunks of work.

Once a small chunk of work is done the Akeeba Backup task will tell Joomla Scheduled Tasks that we are pausing for now and please tell; us to resume at the first available opportunity. This is the same thing we do during a backend backup. There is, however, a big difference!

When taking a backend backup the execution controller is a piece of JavaScript running on your browser. Once it sees that “I'm done but I need to do more work” signal it immediately tells the Akeeba Backup component to continue working on the next chunk of backup work.

As we explained above, Joomla Scheduled Tasks does not work like that. Based on the execution controller you are using and the other scheduled tasks you have on your site it may take a minute to several hours for the backup to resume running (i.e. execute the next chunk of backup work). At best, this will make the backups take MUCH, MUCH LONGER than they do when taking a backup from the backend of your site or when using any of the other backup scheduling options. We ran a test on a real world site which normally takes 2 minutes to take a backup from the backend. When using Joomla Scheduled Tasks and its CLI execution controller scheduled to run once a minute (the maximum frequency allowed for a CRON job) it took over 20 minutes for the backup to complete. On another site that normally takes 14 minutes the backup took approximately 2 hours to complete.

Lazy scheduling may lead to inconsistent backups

The best time to run a backup for your site is when there is as little traffic as possible to minimise the chance that there will be database or filesystem changes while the backup is executing. This ensures backup consistency.

By its nature, Joomla Scheduled Task's Lazy Scheduling only runs backups when there is traffic on your site. Even worse, it only really works when there's a lot of traffic on your site. This means that your backups will run only when your site is under load with two major consequences.

First, your site will be slower since you are running a process that's heavy on I/O and memory during the peak usage time of your site. For the same reason it is possible that some requests may fail outright — including the one which runs your backup! Therefore you end up with either a slow site or a failed backup.

The other problem is that you can no longer expect consistency of your backups since you are running them exactly when you expect a lot of things to change on your site as a result of the traffic it is receiving.

Therefore using Lazy Scheduling is A VERY BAD IDEA unless you have a mostly “read-only” site such as a news site or a blog with no comments or using a third party comments service outside of your site. If you try to use that on a site where major changes are expected as a result of your user's traffic — such as a community site, a forum, or an e-commerce site — your backup will most likely be inconsistent and possibly unusable.

These issues are objectively outside our control which is why we offer no support for lazy scheduling and limited support for URL and CLI CRON jobs triggering the Joomla Scheduled Tasks.

Setting up your site for lazy backup scheduling
[Warning]Warning

We very strongly advise against using the Lazy Scheduling method for Joomla Scheduled Tasks to take backups of your site. We will offer no support for taking or restoring backups taken using this method — use at your own risk. There are a lot of issues which can arise from the use of this kind of unreliable backup scheduling method which are objectively outside our control as explained in the “DANGER AHEAD” section above.

If you decide to ignore this very strong warning we advise you to at least test each and every backup taken with this method to catch the inevitable issues before they become insurmountable problems leading to data loss.

Backup profile configuration

Unlike backend backups , scheduled backups don't have each backup step run in quick succession to each other. This means that we don't need to have any wait time between them — the nature of the scheduling method adds enough wait time, ranging from several seconds to several hours. Therefore we are going to change the fine tuning options to cram as much work as we can within a given amount of time.

Go to the Configuration page of your backup profile and use the following settings:

  • Minimum execution time: 0 seconds

  • Maximum execution time: 120 seconds

    Depending on your server you may want to modify this value. Setting it higher you can do more work per backup step and your backup finishes faster. However, this means that your server is slower during that time and your backup may fail if you hit the PHP or web server time limit, or if you hit your host's maximum CPU usage time. We recommend trying high values first — but not higher than about half of the Task Timeout set up in Joomla Scheduled Tasks' Options page which is 300 seconds by default — and lower them if you notice your site being too slow or your backups are failing.

  • Execution time bias: 80%

  • Disable step break before large files: Yes

  • Disable step break after large files: Yes

  • Disable proactive step breaking: Yes

  • Disable step break between domains: Yes

  • Disable step break in finalisation: Yes

  • Set an infinite PHP time limit: Yes

Joomla Scheduled Tasks setup for Lazy Scheduling

In your site's administrator backend go to System, Manage, Scheduled Tasks.

Click on the Options button in the toolbar.

Click on the Configure Tasks tab.

Set the Task Timeout (seconds) to 300. As noted above, this is the time limit beyond which Joomla will kill a task already running. This needs to be at least twice as much as the Maximum Execution Time in your backup profile and no smaller than 60 seconds. The default value of 300 seconds should be enough for most practical purposes and servers. On some servers you may have to lower this to 60 seconds. If you need to lower it even more DO NOT use the Lazy Scheduling for Joomla Scheduled Tasks — they won't work right. You will need to use a real CLI CRON job. If your host doesn't offer that option, well, you will have to use a third party service to schedule your backups or consider moving to a decent host (there's only so much anyone can do to work around really restrictive and badly set up hosting environments running atop oversold servers which are permanently on the verge of crashing due to too much load...).

Click on the Lazy Scheduler tab.

Set Lazy Scheduler to Enabled.

Set the Request Interval (seconds) to 30 (thirty).

Click on Save & Close.

The request interval needs to be relatively low to allow backups to run at a reasonable amount of time as long as there is enough traffic on your site. The default value of 300 (5 minutes) is too coarse for the backup to run in a reasonable amount of time, leading to most definitely corrupt or inconsistent backups.

Set up the scheduled task itself

In your site's administrator backend go to System, Manage, Scheduled Tasks.

Click on the New button in the toolbar.

Choose the “Akeeba Backup – Take a Backup” task type.

Give it a title of your liking, e.g. “Lazy Backup”.

Set up the execution rule and it configuration. For example, if you want your backup to run every day at midnight set the Execution Rule to Interval, Days, set the Interval in Days to 1 and set the Execution Time (UTC) to 12:00 AM.

[Tip]Tip

The backup date and time is always expressed in the UTC time zone in Joomla. If you want to convert your local time zone to UTC you can use a free time zone converter.

Under Task Parameters you can see a drop-down list with your backup profiles. By default, the default backup profile (#1) is selected. If you would like your backup to run under a different profile select it in the drop-down.

In the Advanced tab we very strongly recommend setting the Priority to High, making the backup task take priority over other scheduled tasks. You should leave other tasks in the Normal or Low priority. This ensures that the backup completes in as little time as possible.

Regarding the Notifications section we strongly recommend enabling all of the options in there. This will keep you appraised of the execution of all backup tasks, regardless of their status.

You may change the Permissions if you'd like to limit who can edit the backup schedule. We recommend removing all privileges for non-Super User groups who have some editing permissions by default e.g. Editor, Publisher, Manager and Administrator.

Click on Save & Close.

Further steps and caveats

Tempting as it may be DO NOT try to use the Run Test button next to the backup task. It does nothing for backup tasks; it returns immediately. This is expected and it does NOT mean that your backup task is broken. You will have to wait for it to run for real. Yes, it's a bit confusing but the Run Test button was only really designed to work with very short tasks which complete in a single shot, not resumable tasks which run over a long period of time. Backup tasks are resumable tasks exactly because they need to run over a long period of time!

Another thing to note is that when you first create a daily backup task it's scheduled to run the upcoming (next) day, at the time you specified. This is pretty much the case with all execution rules, even if you use an interval e.g. once every 30 minutes. The next task run date and time is calculated with the date and time you click on the Save & Close as the base of calculation. So, a task set to run on an interval of 30 minutes will only execute for the first time 30 minutes after you save it at the earliest. Yes, it is confusing but there's a good reason Joomla works that way: it prevents mishaps where long running and potentially dangerous tasks run all at once once you save them. In any case, you can see the next task run date and time by editing the task and clicking on the Execution History tab, then look at Next Execution.

If you edit a backup task that's not yet finished you will see that the Last Exit Code is 123 and the Next Execution is in the past. THIS IS NORMAL. The exit code 123 means “I have more work to do”. When Joomla sees that exit code it does not update the Next Execution date and time. This allows Joomla to resume the task as soon as possible.

Setting up your site for scheduling using a URL CRON job
[Warning]Warning

We advise against using the “Web Cron” (URL-based CRON jobs) method for Joomla Scheduled Tasks to take backups of your site. Doing so may result in the backups not starting at the right time or at all, not completing in a reasonable amount of time or at all, or end up with consistency issues.

As a result we can only offer very limited support for taking or restoring backups taken with this method. When it comes to taking backups we can only point you to this documentation. For restoring backups we will evaluate whether there is something we can do to help you restore your site but most likely we will simply point you back to the “DANGER AHEAD” section of this documentation to help you understand why you are experiencing consistency issues.

If you decide to use this method we recommend to test your backups frequently to catch the inevitable issues before they become insurmountable problems leading to data loss.

Backup profile configuration

Unlike backend backups , scheduled backups don't have each backup step run in quick succession to each other. This means that we don't need to have any wait time between them — the nature of the scheduling method adds enough wait time, ranging from several seconds to several hours. Therefore we are going to change the fine tuning options to cram as much work as we can within a given amount of time.

Go to the Configuration page of your backup profile and use the following settings:

  • Minimum execution time: 0 seconds

  • Maximum execution time: 120 seconds

    Depending on your server you may want to modify this value. Setting it higher you can do more work per backup step and your backup finishes faster. However, this means that your server is slower during that time and your backup may fail if you hit the PHP or web server time limit, or if you hit your host's maximum CPU usage time. We recommend trying high values first — but not higher than about half of the Task Timeout set up in Joomla Scheduled Tasks' Options page which is 300 seconds by default — and lower them if you notice your site being too slow or your backups are failing.

  • Execution time bias: 80%

  • Disable step break before large files: Yes

  • Disable step break after large files: Yes

  • Disable proactive step breaking: Yes

  • Disable step break between domains: Yes

  • Disable step break in finalisation: Yes

  • Set an infinite PHP time limit: Yes

Joomla Scheduled Tasks setup for Web Cron (URL) scheduling

In your site's administrator backend go to System, Manage, Scheduled Tasks.

Click on the Options button in the toolbar.

Click on the Configure Tasks tab.

Set the Task Timeout (seconds) to 300. As noted above, this is the time limit beyond which Joomla will kill a task already running. This needs to be at least twice as much as the Maximum Execution Time in your backup profile and no smaller than 60 seconds. The default value of 300 seconds should be enough for most practical purposes and servers. On some servers you may have to lower this to 60 seconds. If you need to lower it even more DO NOT use the Web Cron (URL) scheduling method for Joomla Scheduled Tasks — they won't work right. You will need to use a real CLI CRON job. If your host doesn't offer that option, well, you will have to use a third party service to schedule your backups or consider moving to a decent host (there's only so much anyone can do to work around really restrictive and badly set up hosting environments running atop oversold servers which are permanently on the verge of crashing due to too much load...).

Click on the Web Cron tab.

Set Web Cron to Enabled.

Click on Save & Close.

You are back on the same page. Click on the Web Cron tab again.

Copy the URL you now see in the Webcron Link (Base) field. It's something like:

https://www.example.com/component/ajax/?

plugin=RunSchedulerWebcron&group=system&format=json

&hash=wC9qeUErwcW2mZekDxBh

(line breaks added for clarity; the URL does NOT contain line breaks). You will need this URL in the next step.

Click on Cancel.

Set up the Web Cron (URL) CRON job to trigger Joomla's Scheduled Tasks

You need to set up a URL CRON job in the same way described in the Frontend Backup documentation section.

There are only two differences: when to run this CRON job and what is the URL to execute.

Use the Webcron Link (Base) URL you copied in the previous step, when setting up Joomla Scheduled Tasks for use with Web Cron.

You need to access this URL every minute of every hour of every day. That's because Joomla will run tasks — including starting and stepping through the backup — only when you access that URL. Therefore you need to access that URL very frequently (once a minute).

We only recommend using this method if your host offers real CRON jobs or URL CRON jobs. We DO NOT recommend using this with third party URL CRON services such as WebCron.org. If you need to use a third party service it's much cheaper and much easier using either the front-end backup URL with WebCron.org or a third party service which integrates with Akeeba Backup (such as BackupMonkey.io, mySites.guru or Watchful.net).

Side note: Yes, there is a way to only run the backup task with a Joomla Scheduled Tasks URL. However, it's too convoluted to set up and manage even for us, let alone our clients with much less or outright non-existent experience in systems administration. To make matters worse, it ended up being substantially more expensive than using a third party service which integrates with Akeeba Backup but also offers site monitoring features. This brings us to the old adage of “just because you can doesn't mean you should”.

Set up the scheduled task itself

In your site's administrator backend go to System, Manage, Scheduled Tasks.

Click on the New button in the toolbar.

Choose the “Akeeba Backup – Take a Backup” task type.

Give it a title of your liking, e.g. “Daily Backup”.

Set up the execution rule and it configuration. For example, if you want your backup to run every day at midnight set the Execution Rule to Interval, Days, set the Interval in Days to 1 and set the Execution Time (UTC) to 12:00 AM.

[Tip]Tip

The backup date and time is always expressed in the UTC time zone in Joomla. If you want to convert your local time zone to UTC you can use a free time zone converter.

Under Task Parameters you can see a drop-down list with your backup profiles. By default, the default backup profile (#1) is selected. If you would like your backup to run under a different profile select it in the drop-down.

In the Advanced tab we very strongly recommend setting the Priority to High, making the backup task take priority over other scheduled tasks. You should leave other tasks in the Normal or Low priority. This ensures that the backup completes in as little time as possible.

Regarding the Notifications section we strongly recommend enabling all of the options in there. This will keep you appraised of the execution of all backup tasks, regardless of their status.

You may change the Permissions if you'd like to limit who can edit the backup schedule. We recommend removing all privileges for non-Super User groups who have some editing permissions by default e.g. Editor, Publisher, Manager and Administrator.

Click on Save & Close.

Further steps and caveats

Tempting as it may be DO NOT try to use the Run Test button next to the backup task. It does nothing for backup tasks; it returns immediately. This is expected and it does NOT mean that your backup task is broken. You will have to wait for it to run for real. Yes, it's a bit confusing but the Run Test button was only really designed to work with very short tasks which complete in a single shot, not resumable tasks which run over a long period of time. Backup tasks are resumable tasks exactly because they need to run over a long period of time!

Another thing to note is that when you first create a daily backup task it's scheduled to run the upcoming (next) day, at the time you specified. This is pretty much the case with all execution rules, even if you use an interval e.g. once every 30 minutes. The next task run date and time is calculated with the date and time you click on the Save & Close as the base of calculation. So, a task set to run on an interval of 30 minutes will only execute for the first time 30 minutes after you save it at the earliest. Yes, it is confusing but there's a good reason Joomla works that way: it prevents mishaps where long running and potentially dangerous tasks run all at once once you save them. In any case, you can see the next task run date and time by editing the task and clicking on the Execution History tab, then look at Next Execution.

If you edit a backup task that's not yet finished you will see that the Last Exit Code is 123 and the Next Execution is in the past. THIS IS NORMAL. The exit code 123 means “I have more work to do”. When Joomla sees that exit code it does not update the Next Execution date and time. This allows Joomla to resume the task as soon as possible.

Setting up your site for scheduling using a CLI CRON job

Please note that you can only use this method if your host offers real CRON jobs. If your host only offers URL CRON jobs or does not offer CRON jobs at all use one of the other Joomla Scheduled Tasks methods or another backup automation method such as using a third party service.

We recommend using this method instead of the Native CRON Script if you are on a host which has a maximum CPU usage time limit per process which is lower than the time it takes to run a full backup of your site. In all other cases this method and the Native CRON Script method are functionally equivalent; you can use whichever one feels easier to you. Both methods are fully supported and highly recommended over any other backup scheduling method.

Backup profile configuration

You do not need to make any configuration changes to your backup profiles when using the “Akeeba Backup – CLI-only Backup” scheduling method.

Joomla Scheduled Tasks setup for CLI scheduling

You do not need to make any changes to your Joomla Scheduled Tasks configuration when using the “Akeeba Backup – CLI-only Backup” scheduling method.

Set up the CLI CRON job to trigger Joomla's Scheduled Tasks

You need to set up a URL CRON job in the same way described in the Native CRON Script documentation section.

There are only two differences: when to run this CRON job and what is the URL to execute.

Use the following command:

/usr/local/bin/php /home/USER/webroot/cli/joomla.php scheduler:run --all

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.

You need to have this CRON job run every minute.

Set up the scheduled task itself

In your site's administrator backend go to System, Manage, Scheduled Tasks.

Click on the New button in the toolbar.

Choose the “Akeeba Backup – CLI-only Backup” or the “Akeeba Backup – Take a Backup” task type. Please read the note below.

[Note]Note

We recommend trying to use the ‘Akeeba Backup – CLI-only Backup’ task type first. If you notice that your backup process seems to be terminated prematurely, before it's fully finished, without an error in the log file please use the ‘Akeeba Backup – Take a Backup‘ task type instead.

Here's the reason for this. The ‘Akeeba Backup – CLI-only Backup’ task type tries to run the entire backup process, start to finish, in a single task execution — it works the same as the Native CRON Script method. This is the most efficient way to run a backup as there is no dead time between consecutive backups steps. However, on larger sites this may take several minutes to hours. Many hosts, especially those offering shared hosting, have a maximum CPU time limit per process. If the backup takes longer than that it is terminated prematurely and the backup does not complete.

The ‘Akeeba Backup – Take a Backup‘ task type, however, works differently. It runs a small chunk of the backup (a backup step) and returns, notifying Joomla that it needs to do more work at the first available opportunity. Since each step is contained in its own task execution it is unlikely to run longer than the maximum CPU time limit per process your host has applied. On the other hand, each backup step runs for just a few seconds every minute (the maximum frequency you can call the Joomla Scheduled Tasks CLI script to trigger the execution of tasks). This means that there is a lot of dead time between backup steps which makes the backup take much longer to complete.

Therefore our recommendation is to first try using the faster ‘Akeeba Backup – CLI–only Backup‘ task type. If it fails you can use the ‘Akeeba Backup – Take a Backup‘ task type to work around your server's limitation, something you cannot do with the Native CRON Script!

Give it a title of your liking, e.g. “Daily Backup”.

Set up the execution rule and it configuration. For example, if you want your backup to run every day at midnight set the Execution Rule to Interval, Days, set the Interval in Days to 1 and set the Execution Time (UTC) to 12:00 AM.

[Tip]Tip

The backup date and time is always expressed in the UTC time zone in Joomla. If you want to convert your local time zone to UTC you can use a free time zone converter.

Under Task Parameters you can see a drop-down list with your backup profiles. By default, the default backup profile (#1) is selected. If you would like your backup to run under a different profile select it in the drop-down.

In the Advanced tab we very strongly recommend setting the Priority to High, making the backup task take priority over other scheduled tasks. You should leave other tasks in the Normal or Low priority. This ensures that the backup completes in as little time as possible.

Regarding the Notifications section we strongly recommend enabling all of the options in there. This will keep you appraised of the execution of all backup tasks, regardless of their status.

You may change the Permissions if you'd like to limit who can edit the backup schedule. We recommend removing all privileges for non-Super User groups who have some editing permissions by default e.g. Editor, Publisher, Manager and Administrator.

Click on Save & Close.

Further steps and caveats

Tempting as it may be DO NOT try to use the Run Test button next to the backup task. If you are using the “Akeeba Backup – CLI-only Backup” task type it will not work; that task is set up to only work when tasks are triggered through the CLI. If you are using the “Akeeba Backup – Take a Backup” task type it will also do nothing as this button does nothing for backup tasks; it returns immediately. This is expected and it does NOT mean that your backup task is broken. You will have to wait for it to run for real. Yes, it's a bit confusing but the Run Test button was only really designed to work with very short tasks which complete in a single shot, not resumable tasks which run over a long period of time. Backup tasks are resumable tasks exactly because they need to run over a long period of time!

Another thing to note is that when you first create a daily backup task it's scheduled to run the upcoming (next) day, at the time you specified. This is pretty much the case with all execution rules, even if you use an interval e.g. once every 30 minutes. The next task run date and time is calculated with the date and time you click on the Save & Close as the base of calculation. So, a task set to run on an interval of 30 minutes will only execute for the first time 30 minutes after you save it at the earliest. Yes, it is confusing but there's a good reason Joomla works that way: it prevents mishaps where long running and potentially dangerous tasks run all at once once you save them. In any case, you can see the next task run date and time by editing the task and clicking on the Execution History tab, then look at Next Execution.

If you edit a backup task that's not yet finished you will see that the Last Exit Code is 123 and the Next Execution is in the past. THIS IS NORMAL. The exit code 123 means “I have more work to do”. When Joomla sees that exit code it does not update the Next Execution date and time. This allows Joomla to resume the task as soon as possible.