Some of the options discussed below may be only available in the Professional edition which is only available to paying subscribers.
The Configuration page controls how Akeeba Backup works at a very fine detail level. Due to the substantial number of options they are organised in different groups. Each option has a label on the left hand side. You can hover your mouse over the label to see a quick reference (tooltip) for that option. Click on the label to make the quick reference sticky. Click again to let it disappear after you move your mouse away from it.
Some of the settings feature a button at the right had side. These buttons either do some action on the setting's field, like browsing for a folder and testing connection parameters.
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 of that range, or an invalid number, they will automatically revert to the closest value which is within the preset range.
The top of the Configuration page
The top of the page is Joomla's toolbar area. The new backup profile. The button aborts all unsaved changes and takes you back to the Control Panel page.button will save the backup profile settings and get you back to the Configuration page. The button will save the backup profile settings and take you to the Control Panel page. The button will save the backup profile settings, create a new profile which is an exact copy of the saved settings and return to the Configuration page of the
Thebutton will launch the Configuration Wizard. This is useful if you want to initialize your backup profile or reset any settings you are not sure about.
Thebutton will take you to the page where you can find out how to automate your backups.
On the top of the main page you can see a reminder of whether you're using encryption for your backup profile settings (something that you can change in the component's Options, accessible from thebutton in the toolbar). We recommend only saving passwords in the configuration when encryption is enabled.
Encryption is not a panacea. The configuration is stored in the database encrypted and the decryption key is stored in a file. This is meant to protect you from a vulnerability which allows the attacker to only access the database. If the attacker can read or, worse, write to your site's files your settings can be reasonably considered compromised: the attacker has all the information they need to retrieve both the encrypted data and the decryption key.
Furthermore, whenever you export a backup profile the resulting file is unencrypted. This is on purpose. The decryption key is site-specific, generated whenever you do a clean installation of Akeeba Backup on your site. If the settings were exported encrypted you'd be unable to import them on a different site.
Below you can find 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.
Further down 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 One-click backup icon box, if checked, will result in a quick icon for this backup profile being displayed in the Control Panel page. Clicking on that icon will start a backup using that profile, without waiting for your confirmation.
Below you'll find a reference for all the options, grouped by the section they belong in.
This is the directory where the result of the backup process goes. The result of the backup - depending on other configuration options - might be one or more archive or SQL files. This is also where your backup log file will be stored. The output directory must be accessible and directly 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
open_basedir restriction which only
allows certain paths to be used for writing files from
within PHP. Akeeba Backup will try to
detect and report such anomalies in the
page before you
attempt a backup.
The output directory, all of its subdirectories and all files contained therein are automatically excluded from the backup. Do not use a folder that contains files you want to back up as your backup output directory. Most importantly, do not use your site's root as your output directory! This will lead to a backup that does not have any of your site's files, making it useless! Akeeba Backup will attempt to warn you in this case.
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)
You can always click on thebutton to open a directory picker interface. Inside that interface and 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.
When you save the Configuration page Akeeba Backup will automatically try to convert the Output Directory to use the three variables explained above. This is intentional. By using variables, your backup profile definition becomes portable across different servers and hosting accounts. Therefore if you restore your backup on a development site hosting account on the same server and take a backup on the restored site its files will be placed in the restored, development site's folder, not your original site's folder.
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. We do not recommend using this setting.
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. Please take a backup using this log level before requesting support from us.
None. This log level is not recommended. It disables logging altogether.
We recommend using Errors and Warnings after you have confirmed that your backup is running properly and All Information And Debug when you need to request support.
Here you can define the name of your backup files. You must not enter an extension, it's added automatically.
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.
Whenever you visit Akeeba Backup's Control Panel we store the host name in the database and try to use it when you take a backup from the command line. If this value cannot be stored or if your site's host name changed since the last time you may get an incorrect host name when taking a backup from the command line, i.e. when you are using the akeeba-backup.php script, typically from a CRON job.
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 16-character random string.
Using this variable makes it outright implausible that an attacker can successfully guess the filename of your backup archive and access it over the web if you are using a backup output directory that's under your site's root and which is unprotected from direct web access, either because you have not put a .htacces or web.config filename or because your web server does not understand (e.g. NginX) or is not configured to honor such files.
Please note that -[RANDOM] will be appended automatically to the Backup archive name if you are using the default backup output directory and you are not already using the [RANDOM] variable in your Backup archive name. This will happen automatically at backup time. You cannot override this behavior because it is a security feature.
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 current server time, in the format HHMMSSGMTOOOO (hour as two digits, minutes as two digits and seconds as two digits followed by GMT and the the offset to the GMT timezone as four digits), for example 221520GMT+0300 for 10:15:20 pm in Nicosia, Cyprus (which is 3 hours ahead of GMT).
We strongly advise using this instead of [TIME] to remove any ambiguity on which timezone is being used. This is especially important if you rely on the filenames to understand which is the backup you are looking for or when you have multiple people taking and restoring backups in different timezones.
The timezone all dates and times are expressed in. This variable gives you the timezone in a manner that is safe for use in filenames, even on Windows. For example, asia_nicosia for Nicosia, Cyprus.
The timezone all dates and times are expressed in. This variable gives you the timezone as an offset to the GMT timezone. For example +0300 for Cyprus (3 hours ahead of GMT), +0530 for India (5 hours 30 minutes ahead of GMT) or -0600 for Chicago (6 hours behind GMT).
The timezone all dates and times are expressed in. This variable gives you the raw timezone, e.g. Asia/Nicosia for Nicosia, Cyprus. Kindly note that this results in invalid filenames on Windows.
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. 1.2.3.
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.
The date and time options are expressed in the timezone selected in the component's Options page under Backup Timezone. By default this is GMT. You are advised to change this to the timezone your site administrators are most familiar with.
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 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 stores the database dump in a more detailed format and 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 the database dumps of your site's database and an installer script to restore them. It's like a full backup without the files.
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.
Full site, incremental files. This backup is a combination of Full site backup and Incremental. It works like a full site backups except for the site files. The site files are treated the same as an Incremental backup, i.e. only modified files are included. This backup type is intended for sites with frequently changing database contents and infrequently changing files. The same warnings about restoration as an Incremental backup apply.
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.
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 your browser. 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, allowing you to transfer sites without using a laptop or desktop computer and without using up a lot of bandwidth on your device.
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.
If you are using the ANGIE embedded installer script you can optionally password-protect it, preventing unauthorised access to the installer. When you run the installer you will be asked to enter this password. Please note that the password is case sensitive, i.e. ABC, abc and Abc are three different passwords.
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.
These optional filters allow you to exclude files or database tables without having to manually select them in the respective exclusion filter pages.
Tick the checkbox to activate this filter. 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.
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.
Automatically exclude error log files, e.g.
error_log, no matter where they are on the
site being backed up. These files change their size while
the backup is in progress which may lead to corrupt
Please note that your host may be using a different
naming convention for error logs, e.g.
fatal.log instead of
error_log. You will need to exclude
these files yourself. This filter won't work on
When enabled, Akeeba Backup will automatically exclude the most common host-specific folders for storing access statistics for your site. These folders are read-only by your web site user, causing restoration issues if they are backed up
Skips over the contents of the Joomla! User Actions Log. The database table holding these records can get quite big on a busy site, slowing your backup down and bloating its size. Skipping over this data does not have an adverse impact to the functionality of the site.
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.
The quotas apply per backup profile. They will only take into account backup records in the same backup profile.
Finally note that the quotas are only being applied at the end of a successful backup, even if post-processing (transferring it to remote storage) failed. It is therefore recommended that you keep an eye out for failed transfers – appearing as warnings in the backup logs and the CLI backup script's output – to avoid an over-zealous quota setting from removing your last full, good backup.
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.
Please keep in mind that remote file quotas, just like local file quotas, only apply to backup records in the database. Akeeba Backup cannot and will not consider files present in the remote storage which do not have a corresponding backup record in the same backup profile. Furthermore, if you manually delete the files from the remote storage but leave behind the backup record in Akeeba Backup, these backups will still participate in quotas, even though their files no longer exist.
When enabled the backup which is in progress participates in the remote quotas. Please note that the backup currently in progress always participates in quotas calculated for files stored locally, on the web server the backup is being taken on.
Enabling this option may lead to a situation where you are left with no valid backup archives to restore your site from. We VERY STRONGLY recommend that you DISABLE this option.
A backup archive may consist of more than one part
files, e.g. files with the same name but extensions such
as .j01, .j02, …, .jpa for the JPA format (or the
equivalent for JPS and ZIP format). It is possible that
only some, but not all, of these files are uploaded to
the remote storage. For example, you may have ran out of
available space on the remote storage, or a temporary
network issue prevented further uploads from taking
place. This is NOT considered an error; some of the
files are in remote storage and some are in local
storage. Normally, you would have to rectify the issue,
then go to the Manage Backups page and click on the
However, let's say that you have enabled the Remote Quotas option and set up quota settings such that would result in all backup archive files previously uploaded to the remote storage being deleted. In this case your remote storage does NOT hold a complete, valid backup you can restore your site from.
If at this point something catastrophic were to happen to your site, before you could go to the Manage Backups page to complete the transfer of the partially uploaded backup archive, and completely lost access to the not yet uploaded backup archive parts still sitting on your web server you will find yourself in the dire position of having a non-functional site and no backup to restore the site from.
Please note that disabling this option will result in at least two (2) backups taken with this backup profile being present in your remote storage: the backup you last took (which did NOT participate in remote quota management) and the backup or backups which have not been deleted yet by the remote quota management.
If you have disabled this option and either set Count Quota to 1 or set Size Quota to something that is less than twice the size of a full backup taken with this backup profile you will see that there are two (2) backups stored remotely instead of only one. This is normal and expected. In fact, there is no way to only have one backup stored remotely except enabling this option. This is another way of telling you that only keeping the last backup in remote storage is dangerous and can indeed lead to a situation where you are left without a backup.
Please weigh the pros and cons of this option very carefully. We advise you to always err on the side of caution, storing several backups of your site in remote storage, ideally with some kind of planned redundancy. Paying a few cents or dollars more every month to ensure that you can recover your site if something goes awry with your server is far less expensive in the long run than risking your site being completely gone and unrecoverable in an unlikely —but not impossible!— cascade of events. Taking backups is risk mitigation which is itself an integral part of risk management. Risk management is not about what happens when everything goes according to plan; it's about surviving the worst case scenario, the unknown, when nothing goes according to plan.
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 makes Akeeba Backup completely ignore 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.
A quota value of zero means "Keep all obsolete records" rather than "delete all obsolete records". To make it abundantly clear: if you set the "Obsolete records to keep" setting to 0 then Akeeba Backup will NOT remove ANY obsolete records EVER.
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.
Normally, Akeeba Backup forces the current backup step to finish when it's about to move to a different backup domain, e.g. after finishing backing up the database and getting ready to backup the files of your site. This gives the backup engine the chance to do garbage collection and free up resources.
You can enable that option to make the backup 1-2 seconds faster, risking a backup failure in resource-restricted servers. We consider it a generally unsafe option and we advise against using it.
Normally, Akeeba Backup forces the current backup step to finish when it's about to move to a different finalization operation e.g. after finishing considering quotas and it's about to start post-processing a backup archive. This gives the backup engine the chance to do garbage collection and free up resources.
You can enable that option to make the backup 1-2 seconds faster, risking a backup failure in resource-restricted servers. We consider it a generally unsafe option and we advise against using it.
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.