Some options discussed below may be only available in the for-a-fee Professional edition!
The Configuration page is split in many sections - or panes, if you like - each one serving as a group for closely related options. Each of those panes displays a title and below it you can find all of the options. Hovering your mouse of the label - the left hand part of each row - you will be presented with a quite big tooltip providing short documentation of the setting and its available options. This way you won't have to refer to this document constantly when configuring Akeeba Backup.
Some of the settings also feature a button. They can either do some action, like browsing for a folder and testing connection parameters, or it may be labeled. This latter case is mostly interesting, as pressing the button will toggle the display of a sub-pane which contains options pertaining to this specific option. This GUI pattern is primarily used for "engines" type settings.
Another interface element worth mentioning are the composite drop-downs. Whenever you are supposed to enter a number, Akeeba Backup presents you with a drop-down menu of the most common options. You can either select a value from the list, or select "Custom...". In the latter case, a text box appears to the right of the drop-down. You can now type in your desired value, even if it's not on the list. Do note that all of these elements have preset minimum/maximum values. If you attempt to enter a value outside those boundaries, or an invalid number, they will automatically revert to the closest value which is within the presents bounds.
If you had been using earlier releases of Akeeba Backup, you will remember that these values used to use a draggable slider. Since the slider was rather "jumpy" and hard to configure, we reverted to using composite drop-downs in order to make entry of settings easier and faster.
The top of the Configuration page
On the top of the page you can see the numeric ID and title of the active backup profile. This acts as a reminder, so that you know which profile's settings you are editing. The toolbar also contains abutton. Clicking on it will launch the profile-independent, component-wide parameters editor. It's the same as clicking the button in the toolbar area of the Control Panel page.
The toolbar also has the following buttons:
. Saves all changes and comes back to the same configuration page.
. Saves all changes and returns to the main Control Panel page of the component.
. Saves all changes and creates a new backup profile with the new (saves) changes. Then it switches to this new backup profile and opens its Configuration page. This allows you to create multiple variations of the same backup profile very easily. It is equivalent to using Copy in the backup profiles page and then clicking on the profile's Configuration button, only with less clicks.
Below the toolbar you will find the Profile Description area. You can view and change the backup profile's description here, without having to go through to the backup profiles page.
The rest of this document is separated into sub-sections. The first sub-section describes the settings of each of the main configuration panes, whereas the rest of the sections discuss the settings made available to you through sub-panes.
This is the directory where the result of the backup process goes. The result of the backup - depending on other configuration options - might be an archive file or an SQL file. This is also where your backup log file will be stored. The output directory must be accessible and writable by PHP.
Providing a directory with adequate permissions
might not be enough! There are other
PHP security mechanisms which might
prevent using a directory, for example the
You can use the following variables to make your setting both human readable and portable across different servers - or even different platforms:
[DEFAULT_OUTPUT] is replaced by
the absolute path to your site's
directory. This is assigned as the default location of
output files unless you change its location. If you
leave it as it is, you are supposed to make sure that
the permissions to this directory are adequate for
PHP to be able to write to
[SITEROOT] is automatically replaced by the absolute path to your site's root
[ROOTPARENT] is automatically replaced by the absolute path to the parent directory of your site's root (that is, one directory above your site's root)
Is this over your head? No problem! Just click on the Browse... button and a pop-up directory navigator will allow you to find the proper directory. Next to the folder's location there is the button labeled. Click on it to make the current directory the selected one and close the pop-up. To make it even easier for you, Akeeba Backup displays a small icon next to the button. If it's a green check mark the directory is writable and you can use it. If it's a red X sign, the directory is not readable and you either have to select a different directory, or change this directory's permissions.
NEVER, EVER, UNDER ANY CIRCUMSTANCES SHOULD YOU USE YOUR SITE'S ROOT AS YOUR OUTPUT DIRECTORY! This will usually lead to corrupt backup or backup failure. The reason is that the output directory and all of their contents are automatically excluded from the backup set. However, even if your backup succeeds due to a bug (remember, it's supposed to fail!), using your public, web accessible site root as your output directory is like a party invitation to hackers worldwide. If you come to our forum with such a setup and a broken backup we can't help you.
This option determines the verbosity of Akeeba Backup's log file:
Errors only. Only fatal errors are reported. Use this on production boxes where you have already confirmed there are no unreadable files or directories.
Errors and warnings. The minimum recommended setting, reports fatal errors as well as warnings. Akeeba Backup communicates unreadable files and directories which it wasn't able to backup through warnings. Read the warnings to make sure you don't end up with incomplete backups! Warnings are also reported in the Backup Now page GUI irrespective of the log verbosity setting as a convenience.
All information. As "Error and Warnings" but also includes some informative messages on Akeeba Backup's backup process.
All Information and Debug. This is the recommended setting for reporting bugs. It is the most verbose level, containing developer-friendly information on Akeeba Backup's operation. This is what we need to help you in case of a problem. This will also create a 2-5Mb log file on most sites, so you should only use this until you have achieved consistently valid backup archives creation.
None. This log level is not recommended. You should only use this if you are paranoid and want no log files written on the server. However, if you are truly concerned about security, you should protect the backup output directory instead of using this log level!
Our servers usually run on Errors and Warnings or All Information levels. When we are testing new releases or change our server setups, we switch to All Information and Debug until we are sure everything is flowing smoothly.
Here you can define the naming template of backup files. There are a few available variables. Variables are special pieces of text which will be expanded to something else at backup time. They can be used to make the names of the files harder to guess for potential attackers, as well as allow you to store multiple backup archives on the output directory at any given time. The available variables and their expansion at backup time are:
The configured host name of your site.
This doesn't work in the native command-line CRON mode, i.e. using akeeba-backup.php for producing automated backups. In such a case, it will be replaced with an empty string (no text).
The current server date, in the format YYYYMMDD (year as four digits, month as two digits, day as two digits), for example 20080818 for August 18th 2008.
The year of the current server date, as four digits
The month of the current server date, as two digits (zero-padded)
The day of the current server date, as two digits (zero-padded)
The current week number of the year. Week #1 is the first week with a Sunday in it.
Day of the week, i.e. Sunday, Monday, etc. The full name is returned in your current Joomla! language. Front-end, remote and CRON backups may return this in English or your default Joomla! language. This is not a bug, it is how Joomla!'s translation system is supposed to work.
A 64-character random string. Use sparingly, it can cause backup failure due to the file name being too long for your server
The current server time, in the format HHMMSS (hour as two digits, minutes as two digits and seconds as two digits), for example 221520 for 10:15:20 pm.
The version of Akeeba Backup. Useful if you want to know which version of Akeeba Backup generated this archive file.
The name of the platform Akeeba Backup is currently running under. This always returns "Joomla!".
The version of the platform Akeeba Backup is currently running under. This always returns the current Joomla! version, e.g. 2.5.4.
The name of the site, lowercased and transformed into a format which guarantees compatibility with all filesystem types commonly found in modern Operating Systems. Please note that the site name will be trimmed at 50 characters if it's longer.
It defines the kind of backup you'd like to take. The backup types for Akeeba Backup are:
Full site backup which backs up the Joomla! database, any extra databases you might have defined and all of the site's files. This produces a backup archive with an embedded installer so that you can restore your site with ease. This is the option 90% of the users want; it is the only option which creates a full backup of your site, capable of producing a working site if everything is wiped out of your server.
Main site database only (SQL file) which backs up only the Joomla! database. It results in a single SQL file which can be used with any database administration utility (e.g. phpMyAdmin for MySQL, pgAdmin3 for PostgreSQL etc) to restore only your database should disaster strike. This option is recommended for advanced users only.
Site files only which backs up nothing but the site's files. It is complementary to the previous option.
Having one "main site database" backup and one "sites files only" backup is not equal to having a full site backup! The full site backup also includes an installation script which, just like Joomla!'s web installer, allows you to effortlessly recover your site even if everything is wiped out of your server. It acts as the glue between the two pieces (files and database).
All configured databases (archive file) which creates an archive file containing SQL files with dumps of your main site's database and all of the defined multiple databases. The database dumps can be restored by any database administration tool (for example phpMyAdmin for MySQL). The difference to the second option is that it produces an uncompressed SQL file and doesn't include any extra databases which you might have defined.
Extra - or "multiple" - database definitions are only available in the Professional edition of the component.
Incremental (files only). This is the same as the Site files only option, but instead of backing up all of your site's files, it only backs up the files which changed since the last time you performed a backup. The only comparison made is between the file's modification time and the last successful backup's time. The "last successful backup" refers to the last backup made using this backup Profile and which has a status of "OK", "Remote" or "Obsolete".
Restoring an incremental backup set is a manual process. You have to manually extract the files from your "base" backup (an archive made with a Full Site Backup profile), then extract all incremental archives on top of it. Finally, used this collection of extracted files to restore your site. This process should only be used if you really know what you are doing. Do not trust that Akeeba Backup can sort out the collection of incremental backups and help you restore them. It won't.
Akeeba Backup splits the backup process into smaller chunks, called backup steps, to prevent backup failure due to server time-out or server protection reasons. Each backup step has a minimum and maximum duration defined by the Minimum Execution Time, Maximum Execution Time and Execution Time Bias parameters in this Configuration page. If the step takes less time to complete than the minimum duration Akeeba Backup will have to wait.
When this box is unchecked (default) Akeeba Backup will have the server wait until the minimum execution time is reached. This may cause some very restrictive servers to kill your backup. Checking this box will implement the waiting period on the browser, working around this limitation.
This option only applies to back-end backups. Front-end, JSON API (remote) and Command-Line (CLI) backups always implement the wait at the server side.
Normally, Akeeba Backup stores temporary information required to process the backup in multiple steps inside files in your Output Directory. Sometimes, especially on low-end hosts with ancient versions of PHP, this causes backup issues such as the backup restarting all the time. In those cases, you can check this box and Akeeba Backup will use your site's database to store this temporary information.
Do note that on some hosts this will cause the backup to fail with a "MySQL server has gone away" error message. That is a problem with the host's configuration. In those cases, nothing can be done. Our suggestion: if you receive such an error, migrate your site to a new host as the one you are using is most likely very restricted and severely under-performant. Moving to a faster, more reliable host can benefit your site in many more ways than just being able to run a backup.
This option controls how Akeeba Backup will access your database and produce a dump of its contents to an SQL file. It is used with all backup types, except the files only type. The available options for this setting are discussed in the Database dump engines section of this document.
This option controls how Akeeba Backup will scan your site for files and directories to back up. The available options for this setting are discussed in the File and directories scanner engines section of this document.
This option controls which kind of archive will be produced by Akeeba Backup. The available options for this setting are discussed in the Archiver engines section of this document.
Akeeba Backup allows you to post-process the backup archives once the backup process is over. Post-processing generally means sending them somewhere off-server. This can be used, for example, to move your backup archives to cloud storage, increasing your data safety. The available options for this setting are discussed in the Data processing engines section of this document.
By selecting this option you instruct Akeeba Backup to also upload kickstart.php on the remote storage alongside your backup archive. When used with the Upload to Remote FTP Server and Upload to Remote SFTP Server you can perform easy site transfers without leaving the comfort of your browser. Just enter the new site's (S)FTP information in the Data Processing Engine configuration and select the Upload Kickstart to Remote Storage option, then take a new backup. When the backup is complete just open the new site's kickstart.php URL (e.g. http://www.example.com/kickstart.php) in your browser to begin the restoration on the new site's server. This even works with mobile devices (we strongly recommend using a tablet or phablet with a display size of at least 7"), allowing you to clone sites even you are on the go!
When enabled Akeeba Backup will go through the archive extraction process without writing anything to the disk. This makes sure that the archive is not corrupt. If the archive is found to be corrupt an error is raised and the backup process stops.
This feature will NOT work when the Process each part immediately option is enabled in the Post-processing Engine configuration. When you are processing each part immediately the backup archive parts are transferred away from your server before the end of the backup is reached. As a result it is not possible to do a test extraction (the archive file parts are no longer there, so there's nothing to try and extract). It WILL however work when you are simply using a post-processing engine (e.g. Upload to Amazon S3) without the process each part immediately option. Please bear in mind that the integrity check runs BEFORE post-processing (uploading) the backup archive parts to remote storage because there's no reason to put a broken archive for safe-keeping in remote storage.
This feature will only work if you are using an Archiver Engine which creates backup archives. This is typically the case with most Archiver Engines. Notable exceptions are, of course, the DirectFTP and DirectSFTP engines which do not produce backup archives. If you enable this feature on a backup profile using either of these Archiver Engines you'll get a warning.
Enabling this feature will increase the time required to complete the backup process and use substantially more memory and CPU resources. Akeeba Backup goes through the same archive extraction process as Kickstart with the only difference that it does not write anything to the disk.
Finally do keep in mind that this feature only makes sure the archive can be extracted, it does not test whether the database data can be restored or if the restored site works correctly. It's still up to you to do a periodic, complete test restoration of your site.
Akeeba Backup will include a restoration script inside the backup archive in order to make restoration easy and the backup archive self-contained. You do not need anything else except the archive in order to restore a site. Restoration scripts honour the settings in your configuration.php, modifying only those necessary (for example, the database connection information), allowing you to create pristine copies ("clones") of your site to any host. You can find more information about restoration scripts in the next Chapter.
Using the off-site directories inclusion of Akeeba Backup Professional, the component will be instructed to look for files in arbitrary locations, even if they are outside the site's root (hence the name of that feature). All the directories included with this feature will be placed in the archive as subdirectories of another folder, in order to avoid directory name clashes. We call this folder the "virtual directory", because it doesn't physically exist on the server, it only exists inside the backup archive.
These settings are all optional and only available in Akeeba Backup Professional. They allow you to back up a different site than the one Akeeba Backup is currently installed. Essentially, you can install Akeeba Backup on one site and have it back up all sites on the server.
You do not need to set anything up in this section if you only intend to backup or transfer your site. This is only required when you want Akeeba Backup to backup a different site than the one it is installed in.
When not checked (default), Akeeba Backup will back up the files and folders under the root of the site it is installed. When this option is checked, it will use the site root in the Force Site Root option below. Use this when you want to backup a different site than the one Akeeba Backup is installed in.
The root of the site to back up. This is only necessary if you have checked the Site root override option above.
When not checked (default), Akeeba Backup will back up the database tables inside the database to which the site Akeeba Backup is installed in connects to. In other words, when this option is not checked, Akeeba Backup will back up the current site's database.
On the other hand, if this option is checked, Akeeba Backup will backup the database whose connection information you specify in the settings below. Use this when you want to backup a different site than the one Akeeba Backup is installed in.
Choose between the database driver.
For MySQL databases you can choose between the MySQL and MySQLi driver. If you do not know the difference between the two, MySQLi (with the trailing "i" which stands for "improved") is the best choice.
The hostname or IP address of the database server.
127.0.0.1. If unsure, ask your host.
If your database server uses a non-standard port, enter it here. If you have no idea what this means, you most likely need to leave that field blank.
The username to connect to your site's database.
The password to connect to your site's database.
The nae of your database.
The prefix of the tables of the site you're backing up. That's the common part of their names up to and including the first underscore.
Since Akeeba Backup 3.2 this section contains optional inclusion and exclusion filters which can be activated to customize your backup procedure. The available filters are:
It allows you to backup only files modified after a specific date and time. This is different than the incremental file only backup. It allows you to backup files newer than the specified date no matter which backup mode (full site backup, files only backup, incremental files only backup) you are using. The available options are:
Tick the checkbox to activate this filter
Files before this date and time will be skipped from the backup set. The format for the date and time parameter is YYYY-MM-DD HH:MM:SS TIMEZONE. This means that you have to specify the year as four digits, followed by a dash, then the month as two digits (e.g. 09 for September), followed by a dash, then the day as two digits (e.g. 01 for the 1st day of the month). For example, September 1st, 2010 is written as 2010-09-01. If you want to specify the time, leave a space after the date and write down the time as the hour using two digits (00-23, no a.m./p.m. is supported!), then a semicolon, then the minutes as two digits, followed by a semicolon, then the seconds as two digits. For example 59 seconds after 11:05 p.m. is written as 23:05:59. You can optionally leave a space after the time and specify the timezone as GMT+/-time. For example, GMT-6 is Dallas time which is six hours behind the GMT and GMT+2 is two hours ahead of GMT which is the Eastern Europe Time. If you do not specify a timezone the GMT timezone is assumed.
You have to set your server's timezone in Joomla!'s Global Configuration for this feature to work reliably. If you get strange results, try editing your site's Global Configuration before asking us for support.
Since Joomla! 2.5, the Joomla! CMS ships with a feature called "Smart Search", also known as "Finder". This is a mini search engine built into the CMS. It works by scanning your content and keeping a complex database structure linking potential search terms (words) with content items in compatible components. Due to its nature it stores an immense amount of information in the database. This information takes a very long time to back up. Moreover, this information doesn't need to be backed up as it can be regenerated by using the "Reindex" button in Smart Search's back-end interface. In the interest of speeding up your backups and not including redundant information in the backup Akeeba Backup by default has this option enabled. This instructs the database backup portion of our backup engine to skip backing up the contents of Finder's (Smart Search's) tables. If for some reason you want to back up this content please uncheck this box.
Quotas let you automatically remove backup archives and / or backup records based on specific criteria. Quotas are always calculated against the backup records, not the backup archives on disk on or on remote storage. In other words, if you do not see a backup record in the Manage Backups page it is NOT taken into account when applying quotas.
Furthermore, quotas will take into account only the backup record, without checking if the file exists. If a backup is listed as OK or Remote in the Manage Backups page it participates in the quotas.
Finally, the quotas apply per backup profile. They will only take into account backup records in the same backup profile.
When checked, the quota settings will also be applied to remotely stored files. This option only works with the cloud storage engines which support remote file deletion.
When checked, Akeeba Backup will only apply quotas based on the date and time the backup was started. This allows you to easily do something like "keep daily backups for the last 15 days and always keep the backup taken on the first of each month".
Enabling this options DISABLES the size and count quotas.
Only applies when the Enable maximum backup age quotas option is enabled.
Backups older than this number of days will be deleted. Newer backups will not be deleted.
Only applies when the Enable maximum backup age quotas option is enabled.
Even when a backup is older than the Maximum back age, in days setting, it won't be deleted if it was taken on this day of the month. For example, if you set this to 1, backups taken on the first day of each calendar month will not be deleted. Setting this option to 1, the backup age to 31 and enabling the maximum backup age quotas you end up keeping all backups taken the last month and keeping the backups taken on the first of each month.
When the locally stored files of a backup record are deleted (either manually or automatically after uploading it to a remote storage) the record is marked as Obsolete or Remote. Some users prefer to limit the number of the backup entries showing in the Manage Backups (formerly "Administer Backup Files") page. This option instructs Akeeba Backup to keep at most that many obsolete/remote records and automatically delete older obsolete/remote entries. This is different than the rest of the quotas because it doesn't remove files from your server, it removes the backup entry from Akeeba Backup's interface.
Backups marked as "Remote" are also considered obsolete records: the backup archive does not exist on your server, it only exists on the remote storage. Therefore this setting will also remove the backup records for the Remote backups. Since you are removing the backup records they WILL NOT participate in remote file quotas! Therefore the Obsolete records to keep setting MUST be higher than the total number of backups you will keep before the quotas kick in plus one.
For example, if you are taking 4 backups a day and you have enabled a maximum backup age quota of 30 days you need to set the Obsolete records to keep to at least 121 (4 backups / day x 30 days + 1 = 120 + 1 = 121). Otherwise the maximum backup age quotas will NOT work as expected.
When checked, old backup archives will be erased when the total size of archives stored under this (and only this) profile exceed the Size quota setting.
Defines the maximum aggregated size of backup archives under the current profile to keep. Only has an effect if the previous options is activated.
When checked, old backup archives will be erased when there are more backups stored under this (and only this) profile exceed the Count quota setting.
Defines the maximum number of backups under the current profile to keep. Only has an effect if the previous options is activated.
Some servers deploy anti-hacker measures (such as mod_evasive or mod_security) which will deny connections to the server if the same URL is accessed multiple times in a limited amount of time. Akeeba Backup has to call its backup URL multiple times, so it runs the risk of being treated as a potential hacker and denied connection to your server, resulting to backup failure.
In order to work around this issue, Akeeba Backup can throttle the rate of server requests using this setting. A minimum execution time of 2 seconds means that calls to the backup URL will happen at most once every two seconds. You are suggested to keep the default value.
Akeeba Backup has to
divide the backup process in individual small steps in
order to avoid server timeouts. However, it has to know
how small they have to be; that's why this setting exists.
Akeeba Backup will try to avoid
consuming more time per step than this setting. You have
to use a number lower than the
maximum_execution_time setting in your
host's php.ini file. In fact, we suggest using 50% of that
value here: if your host allows up to 30 seconds in the
php.ini, you have to enter no more than 15-17 seconds
here. If unsure, 7 seconds is a very safe value under most
When Akeeba Backup calculates the available time left for performing operations within the current backup step a number of external settings may skew this result and lead to timeout errors. This setting defines how conservative the backup engine will be when performing those calculations and is expressed as a percentage of the Maximum execution time parameter. The less this setting is, the more conservative Akeeba Backup gets. It is suggested not to use a value over 75%, unless you have a very fast server. If you experience timeouts, you may want to lower this setting to a value around 50%.
When this option is unchecked Akeeba Backup will completely stop the backup when the server responds with an error or the communication with the server is cut short. When this option is enabled (default), Akeeba Backup will try to resume the backup by repeating the last backup step. This will not let you successfully resume all backups which result in an error: only backup attempts temporarily blocked by server CPU usage restrictions or network outage issues can be resumed. If the backup fails due to a timeout error, memory outage, incompatible server software etc the backup resumption will result in the same error until it leads to a permanent backup failure.
This feature only applies to back-end backups. This feature will not be taken into account when you have enabled the Process each part immediately option in the configuration of the Data processing engine since it's impossible to retry backing up to a backup archive which may have already been transferred to remote storage and removed from the server.
How many seconds to wait before resuming the backup. It is advisable to set this to 30 seconds or more (120 seconds is recommended in most cases) to give your server / network the necessary time to recover from the error condition which caused your backup to fail.
How many consecutive times should we retry resuming the backup before finally giving up and throwing a permanent error (backup failure). 3 to 5 retries work best on most servers.
When the application detects a large file (see the filesystem scanner engine configuration) it will try to break the execution of the current backup step and start backing up the large file in its own backup step. This is a conservative behaviour that increases the likelihood of being able to backup large files but makes the backup slower. If you check this box the backup will become faster, but it might fail backing up larger files.
When the application finishes backing up a large file (see the filesystem scanner engine configuration) it will try to break the execution of the current backup step and continue the backup process in a step. This is a conservative behaviour that decreases the likelihood of the backup engine timing out after backing up a large file but makes the backup slower. If you check this box the backup will become faster, but it might fail after backing up larger files.
The application tries to guess how much time it will take it to backup each file. If it believes that backing up the next file in its queue will take too long it will break the backup step and continue the backup in a new step. This decreases the likelihood of server timeouts, at the expense of making the backup a little slower, especially if you have lots of tiny files. If you check this box the backup will become faster, but it might fail in some cases.
Do not check this box unless you are instructed by our support staff. The possibility of needing this option has been found to be less than 0.1%.
Do not check this box unless you are instructed by our support staff. The possibility of needing this option has been found to be less than 0.1%.
If your server is using the CGI or FastCGI interface to PHP, checking this option will make it less likely that the backup dies due to a PHP timeout issue. We consider it generally safe checking this box as we have never observed or got reports of any side-effects.