Support

Documentation

Automating your backup

Taking backups automatically

Even though Akeeba Backup makes it very easy to take a backup of your Joomla!™ site, doing so manually is boring. Moreover, experience tells us that if you don't take backups automatically the chances are that when you need one you'll have not taken a backup for a long period of time. To this end, Akeeba Backup offers multiple methods to let you run backups automatically, without further human interaction.

[Tip]Tip

Go to Akeeba Backup's Scheduling Information page. You will get a condensed version of these instructions, personalized -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.

Front-end backup, for use with CRON

[Tip]Tip

This option is available in both the Akeeba Backup Core and Akeeba Backup Professional releases. You don't need to subscribe to the Professional edition to use it.

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_akeeba&

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_akeeba&

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_akeeba&

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_akeeba&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_akeeba&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.

Native CRON script

[Tip]Tip

This option is only available in Akeeba Backup Professional.

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 file cli/akeeba-backup.php can be executed from the command-line PHP interface (PHP CLI). It doesn't require the front-end backup in order to work; it is a self-contained, native backup 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/akeeba-backup.php

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 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 Akeeba Backup's file naming "variables", e.g. [SITE], [DATE] and [TIME]. These variables are documented in the Output Directory configuration option's description. 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.

  • --quiet will suppress all output except warnings and error messages. If the backup runs successfully you get no output at all. Note: this option was added in Akeeba Backup Professional 3.3.4.

The akeeba-backup.php script 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/akeeba-backup.php
  2. Backup with profile number 2 and default description:

    usr/local/bin/php /home/johndoe/httpdocs/cli/akeeba-backup.php --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/akeeba-backup.php --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/akeeba-backup.php --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 a limitation of Joomla's CLI application interface –used by our script– which follows 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), akeeba-backup.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/php5-cli /home/myusername/public_html/cli/akeeba-backup.php --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/php5-cli. This is the default location of the correct executable file for cPanel 11 and later. 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.

Special considerations for HostGator
[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.

The location of the PHP CLI binary is /usr/bin/php-cli. This means that your CRON command line should look like:

/opt/php53/bin/php /home/myusername/public_html/cli/akeeba-backup.php --profile=YourProfileID
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 INI files throughout the component's back-end. The first location you should look at is administrator/components/com_akeeba/engine/core, where you will find four INI files with general settings. Inside the administrator/components/com_akeeba/engine subdirectories you will find one INI file per engine.

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 .ini files under administrator/components/com_akeeba/BackupEngine/Postproc.

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

usr/local/bin/php /home/johndoe/httpdocs/cli/akeeba-backup.php
--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 option is only available in Akeeba Backup Professional.

This script 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. The alternative CRON script is located in cli/akeeba-altbackup.php, and must be run from the command-line PHP interface (PHP CLI).

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/akeeba-altbackup.php

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.

  • --no-verify Only applies to HTTPS connections. If you have a plain HTTP site you can ignore this setting. Since Akeeba Backup 5.5.2 this script will check that the SSL certificate presented by the server is issued by a known, trusted Certification Authority and that the domain name included in the certificate matches the domain name of your site. If you want to disable this verification, e.g. because you're using a self-signed certificate or a certification authority internal to your organization you need to pass the --no-verify option. This will disable the verification, emulating the way this script worked in Akeeba Backup 5.5.1 and earlier.

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/akeeba-altbackup.php
  2. Backup with profile number 2

    usr/local/bin/php /home/johndoe/httpdocs/cli/akeeba-altbackup.php --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 fsockopen() method

    3. 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.

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/php5-cli /home/myusername/public_html/cli/akeeba-altbackup.php --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/php5-cli. This is the default location of the correct executable file for cPanel 11 and later. 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.

Special notes for GoDaddy
[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.

According to our users who have tried this, this laternative script does work with GoDaddy. The command line you have to use is:

/usr/local/php5/bin/php "$HOME/html/cli/akeeba-altbackup.php" --profile=YourProfileID

where YourProfileID is the numeric profile number you want to use for your backup job.

The PHP executable we are using is the CLI rather than the default CGI. This is important; if you use the CGI executable then the script will not run. Don't forget to enable frontend backup and insert your secret word. To enable frontend backup go to Akeeba Backup under components, select configuration, select options from the navigation, then select the front-end backup tab to enable the settings.

If the backup completes successfully but the backup appears as "Failed" in the Manage Backups (formerly "Administer Backup Files") page, you'll have to apply a workaround. Go to Akeeba Backup and select your backup profile from the drop-down list. Then click on the Configuration button. In the configuration page check the Use database storage for temporary data option.