Support

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 a SQL file. This is also where your backup log file will be stored. The output directory must be accessible and writable by PHP.

	Important
	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. The application will try to detect and report such anomalies in the main page, before you attempt a backup.

You can use the following variables to make your setting both human readable and portable across different servers - or even different platforms:

Is this over your head? No problem! Just click on the button which looks like an open folder to the right of the text field 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 Use. Click on it to make the current directory the selected one and close the pop-up. To make it even easier for you, the application displays a small icon next to the Use 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.

Warning

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. Be security conscious, always use a directory that's not publicly accessible for storing your backups. The default backup output directory is inaccessible to the public if you are using IIS, Apache or any other server which understands .htaccess or web.config syntax. If you are using NginX, however, you need to supply a directory of your own which is located outside your public web root.

This option determines the verbosity of the application's log file:

Our testing 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 convention of backup files. There are a few variables available. 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 date and time options are expressed in the timezone selected in the System Configuration 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 are:

Akeeba Solo 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 Solo will have to wait.

When this box is unchecked (default) Akeeba Solo 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.

	Important
	This option only applies to backups taken using the graphical web interface of Akeeba Solo. Front-end, JSON API (remote) and Command-Line (CLI) backups always implement the wait at the server side.

Normally, the application is using AJAX postbacks to perform the backup process without timing out. Its ability to do so depends on how well your server plays along with your browser's Javascript engine. Sometimes, this is just not possible at all and you'll experience the backup stalling at random points through the backup process. If modifying the other options doesn't help, enable this feature. When enabled, instead of using AJAX calls, the application will create a hidden IFRAME in the page and perform all server communications through it. Since IFRAMEs load the backup URL as if it were a regular web page, it minimizes the probability of conflicts. The major drawback is that this method is about 50% slower than the AJAX one, so your backup will take substantially longer.

Normally, the application 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 the application 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-powered. Moving to a faster, more reliable host can benefit your site in many more ways than just being able to run a backup.

Only for Akeeba Solo (standalone). This is where you can give the application a few more hints about the script / CMS your site is using, allowing it to optimise the backup process. Your options are:

Only for Akeeba Solo (standalone). The root directory of the site to back up. It's the same thing that you defined in the Configuration Wizard.

Only for Akeeba Solo (standalone). Select the database server technology you are using with your site. Akeeba Solo only supports MySQL database servers.

Please note that there are two options: MySQLi and MySQL (with or without the i at the end). Most servers allow you to use the newer, better, faster MySQLi (with the i at the end) option. If this doesn't work, you can also try using the one without the i at the end. This is discouraged as that option is the older, slower one which may have a performance impact on your backups.

Only for Akeeba Solo (standalone). The host name or IP address of your database server. It is usually localhost or 127.0.0.1 which are very different as far as the database connection is concerned. If localhost doesn't work, try 127.0.0.1 (note: these are dots, not commas, between the numbers). Otherwise please ask your host. Some hosts require something different in there, e.g. database123.example.com.

Only for Akeeba Solo (standalone). The user name you use to connect to your database. This is provided by your host.

Only for Akeeba Solo (standalone). The password you use to connect to your database. This is provided by your host.

Only for Akeeba Solo (standalone). The name of your database. This is provided by your host.

Only for Akeeba Solo (standalone). This is the common prefix of all database tables used by your site. This is usually visible in your site's administrator pages (e.g. in Joomla! it's under Global Configuration) or in your site's configuration files (e.g. for WordPress it's in the wp-config.php file). If you are unsure open your site's database and check the common prefix of the tables in there. It's usually very obvious what the prefix is: most or all of your tables start with the same few letters and numbers followed by an underscore. These letters and numbers and the trailing underscore are the "database table name prefix".

Only for Akeeba Solo (standalone). If you have installed Akeeba Solo inside the root of the site being backed up, by default Akeeba Solo is excluding its files, folders and database tables from the backup. By selecting this option you instruct Akeeba Backup to lift this restriction and allow its files, folders and database tables to be backed up.

	Warning
	If you have installed Akeeba Solo outside the root of the site you are backing up selecting this option will NOT result in the inclusion of Akeeba Solo's files. You will have to do that manually through the Off-site Directories Inclusion feature from the main page of Akeeba Solo.

This option controls how the application 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 the application 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 the application. The available options for this setting are discussed in the Archiver engines section of this document.

The application 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 the safety of your data. The available options for this setting are discussed in the Data processing engines section of this document.

By selecting this option you instruct the application 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.

The application 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 site's configuration, modifying only those necessary (for example, the database connection information), allowing you to create pristine copies ("clones") of your site to any host.

	Important
	It is very important to choose the right archiver engine for the script / CMS used by your site. Choosing the right script makes your life much easier when restoring your site. For further information please take a look at the documentation of the Configuration Wizard.

Using the off-site directories inclusion of the application, the application 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 exist on the server at the time of the backup, it only exists inside the backup archive. The restoration script will allow you to move these files and directories from the "virtual directory" (extracted inside your site's root) to their correct, off-site location at restoration time.

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.

	Important
	You have to set your server's timezone in the System Configuration page for this feature to work reliably. If you get strange results, try editing the System Configuration.

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.

Warning

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 “Transfer to Remote Storage Name” button to complete the transfer. 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, the application 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".

	Warning
	Enabling this option causes the size and count quotas to be ignored.

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 during the last month and keeping the backups taken on the first of each month.

When the locally stored files of a backup 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 page. This option instructs the application 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 record from the application's interface.

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. This setting is ignored when maximum backup age quotas are enabled.

Defines the maximum total size of backup archives under the current profile to keep. Only has an effect if the previous option is activated.

	Warning
	When you are uploading backup archives to remote storage and have enabled the Process each part immediately then Size Quotas will not work correctly. Due to the internal workings of the backup engine when Process each part immediately is enabled the size of each backup cannot be determined correctly.

When checked, old backup archives will be erased when the number of backup archives stored under this profile exceed the Count quota setting. This setting is ignored when maximum backup age quotas are enabled.

Defines the maximum number of backups under the current profile to keep. Only has an effect if the previous option is activated.

This option is currently ignored and has no effect in Akeeba Solo / Akeeba Backup.

Some servers deploy anti-hacker measures (such as mod_evasive or mod_security2 for Apache) which will deny connections to the server if the same URL is accessed multiple times in a limited amount of time. The application has to call its backup URL multiple times to step through the backup process without timing out, therefore it runs the risk of being treated as a potential hacker and denied connection to your server, resulting in backup failure.

In order to work around this issue, the application 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.

If you want to speed up the backup try decreasing it to zero. If the backup fails inexplicably, try increasing it. If you are in doubt and don't know what to do, please leave this to the default setting of 2 seconds, or whatever the Configuration Wizard found out works the best on your server.

The application has to divide the backup process in to individual small steps in order to avoid server timeouts. However, it has to know how small or big they have to be; that's why this setting exists. The application 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 configurations.

When the application 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 lower this setting is, the more conservative the application gets. It is suggested not to use a value over 75%, unless you have a high-end, high performing server. If you experience server timeouts, you may want to lower this setting to a value around 50%.

When this option is unchecked Akeeba Solo 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 Solo 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.

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