Output Directory. 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. 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. JoomlaPack will try to detect and report such anomalies in the Control Panel page before you attempt a backup.

Since JoomlaPack 2.3, this setting supports two variables:

JoomlaPack will intelligently detect when it can use this variables and apply them automatically upon saving or applying the configuration changes. The real utility of these variables is that if you use output directories relative to these two predefined locations, you can use JoomlaPack without reconfiguration even if you move your site to a completely different host, e.g. from your live Linux host to your local Windows testing server.

You can use the Reset to default button in order to reset this setting to the factory default location (a subdirectory inside the component's back-end directory) or the Browse... button to launch a visual directory browser which allows you to easily select the output directory without typing a lengthy absolute path manually.

Minimum Access Level. This defines the minimum Joomla! access level a back-end user must have in order to be able to access the component's functions. The default level ("Super Administrator") limits access to JoomlaPack to the Super Administrator group. Choosing "Administrator" allows both Administrator and Super Administrator group members to access the component, useful if you don't make a habit of loging in as a Super Administrator user. The last option, "Manager", effectively allows all back-end users to access the component which is dangerous! Use this option responsibly.

	Warning
	JoomlaPack backups contain all of the files and database records of your site. Anyone who is given access to this component must be absolutely and undisputably trusted because he will be able to clone the site on another - live or local - server, bypassing any restriction you might have implemented.

Store temporary backup data in files, instead of in database. Normally, JoomlaPack stores its engine state information in the database between subsequent steps. If you have a site which has directories with a lot of files and subdirectories or have non-latin and/or accented characters in some file names, or if your database server is old you might experience errors during this operation. As a workaround, you can enable this option so that JoomlaPack can store its engine state information in files inside your site's temporary directory. We strongly suggest that you turn on this option!

Enable front-end backup. Controls the availability of front-end backup. The front-end backup feature allows you to perform a backup operation using any profile you'd like without logging in the Joomla! administrator section. It is primarily used for automating the backup process using cron scripts, or other automated utilities.

Email Super Administrators on successful front-end backup. If enabled, JoomlaPack will send a canned email message to all of the site's Super Administrators once a successful front-end backup has been made. This is useful in order to monitor that your CRON-scheduled backups work and result in successful backups. Please keep in mind that JoomlaPack considers backups performed by JoomlaPack Remote as front-end backups for the purpose of sending email notifications to Super Administrators.

Secret word. In order to prevent DoS (Denial of Service) type of attacks by malicious users flooding your server with front-end backup requests, JoomlaPack implements the "secret word" approach. The "secret word" is an arbitrary string which has to be passed along in the front-end backup request URL in order for the process to begin.

	Important
	We suggest you to use only alphanumeric characters (a to Z and 0 to 9) for the secret word. If you use any special symbols, they will have to be passed URL-encoded for the front-end backup request URL to be valid and work at all. If you don't understand what URL encoding means, just follow our advice!

Note

JoomlaPack will email all Super Administrators whenever a backup attempt is finished successfuly, or with a catchable backup error. If something goes awry and the backup attempt is halted abruptly on the cause of a PHP error, JoomlaPack is unable to report failure. As a result, it is always a good idea to log in periodically to JoomlaPack's administration page to review the backup status of your site.

Backup Type. It defines the kind of backup you'd like to take. The backup types for JoomlaPack are:

Archive Name Template. Here you can define the naming template of backup files. There are a few available macros. Macros are special strings 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 macros and their expansion at backup time are:

Log level. This options controls the verbosity of the JoomlaPack's log file. The available log levels are:

Database export style. This option controls the MySQL version compatibility when creating the database SQL dump file. In fact, it forces JoomlaPack to request the appropriate CREATE TABLE commands from your database server. It is useful when migrating your site to another host with a different MySQL version. The available options are:

Database backup algorithm. This option determines how JoomlaPack will operate in order to try avoiding timing out when it is backing up your database. The available options are:

File packing algorithm. This option determines how JoomlaPack will operate in order to try avoiding timing out when it is scanning your site for files to back up and while archiving these files. The available options are:

File list engine. This option controls how JoomlaPack will scan your site for files to back up during the File Packing process. The available options are:

Database backup engine. This option controls how JoomlaPack will access your database and produce a dump of its contents to an SQL file. It is used during the Database Dump operation and applies to all backup types. The available options are:

Archiver engine. This option controls what JoomlaPack will do with the files to be backed up. The available options are:

Installer included in backup. JoomlaPack will include a restoration script, the installer selected here, in the backup archive in order to make restoring easy. The installers retain the familiar Joomla! installer appearance so that you feel at home! All installers keep 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. The available installers are:

Backup method. This option controls how JoomlaPack will interact with the server both at backup time (for back-end backups) and when setting filter options. The available options are:

	Warning
	If you are using FireBug or any other Javascript debugger you must disable it before using JoomlaPack. FireBug is known to cause adverse effects on JavaScript-intensive web applications like GMail and JoomlaPack. The apparent symptom is that JoomlaPack seems to be sitting idle in the middle of a backup process. In fact, it's FireBug that has unfortunately

Minimum execution time per step (in milliseconds). JoomlaPack accomplishes its backup task by reloading the backup page many times, until the process is over. Under some circumstances this can happen many times per second. Many servers tend to mistake this behaviour with an attempt to bring down the server (a DoS attack), so they "pull the plug" on JoomlaPack. This usually causes server error 403 or 500 pages to appear in mid-process. This is especially true if you are using Joomla! Plugin Sentinelle, mod_security, mod_evasive or any similar anti-DoS security measure. To avoid this, JoomlaPack can artificially "lengthen" the time of very fast steps, ensuring that they last no less than the time you enter here (in milliseconds).

If your server is set up to triger DoS protection at more than one page load per second, the minimum value you should enter here is 1000 (one second). If, however, it is set up to triger a DoS protection at more than one page load per five seconds, you have to enter the value 5000 (five seconds, expressed in milliseconds). Remember: 1 second = 1000 milliseconds. You have to enter milliseconds in this field!

If this setting is less than or equal to 0 or empty then no delay is introduced between subsequent backup page reloads. If you enter a value which is greater than your server's configured PHP max_exec_time, JoomlaPack will automatically and transparently adjust this setting to be at most equal to the max_exec_time PHP directive.

This setting takes effect in all types of backup: Back-end AJAX backup, back-end Javascript Redirects backup, front-end backup, CRON Scripts Manager backup scripts, front-end Light Mode (PDA / cell phone / thin client access) and XML-RPC backup (JoomlaPack Remote).

	Note
	As of JoomlaPack 2.4, this parameter replaces the "Delay between backup steps (in milliseconds)", as it does pretty much the same thing while being more generic and reliable, as well as usable in far more backup types.

Erase old backup files if the total size is over the size quota. When enabled, older backup files will be deleted if the total size of the backup files (including the one being generated) is over the size specified in the option named "Size quota, in Megabytes".

Erase old backup files if they are more than the max. number of files to keep. When enabled, older backup files will be deleted if the total number of backup files (including the one being generated) is over the number of files specified in the option named "Maximum number of backup files to keep".

Size quota, in Megabytes. Defines the maximum aggregated size of backup files to keep, for use with the "Erase old backup files if the total size is over the size quota" option.

Maximum number of backup files to keep. Defines the maximum number of backup files to keep, for use with the "Erase old backup files if they are more than the max. number of files to keep" option.

Tip

The quotas are applied only after a successful backup, at the backup finalization stage. This makes sure that old backup files will not be deleted accidentaly in the case of a failed backup. This also means that archives from failed backup attempts also remain on your server and do not count towards the quota limits! The only way to get rid of the "failed" archives is to delete the failed attempt from the backup statistics, or delete the archive manually (for example, through FTP).

Force database keep-alive during long operations. Some servers irrevocably drop the database connection to scripts running over a predefined period of time without database traffic. This period is usually very small, in the area of 5-10 seconds. Because JoomlaPack spends a lot of time doing file operations without database activity, this measure would be in effect and cause "MySQL server has gone away" errors in the log file, while aborting the backup process. To this end, we have implemented a smart feature which will try to generate database traffic every half a second if you turn this option on.

	Note
	This is far from being a panacea to those problems. It is very possible for database errors to occur on extremely slow hosts, or if the server imposes another constraint, for example limiting the amount of time a database connection can remain open.

Location of gzip executable file. If you use the GZipped Tar archiver, you have to enter in this box the path to the gzip binary. Normally it should be in your system's path so leaving it to the default, "gzip", should be fine. You'll have to check with your host in orer to find out what is the path to your gzip binary.

Dereference symbolic links. This option is only valid on Linux and compatible *NIX hosts. Normally, when JoomlaPack entounters symbolic links ("symlinks"), it follows them and treats them as regular files and directories, backing up their contents. Some site configurations may have symbolic links set up in such a way as to create an infinite loop, causing the backup to fail. When this option is set to No, JoomlaPack will not follow symbolic links, but store their name and their target in the archive. Of course, if your symbolic links use absolute paths, restoring to a different server than the one you backed up from will result in broken symlinks.

	Important
	This option is available on *NIX hosts and for the ZIP packer engine only, in JoomlaPack 2.3 or later.

Part size for archive splitting. JoomlaPack 2.3 and later support the creation of Split Archives. In a nutshell, your backup archive is spanned among one or several files, so that each of these files ("part") is not bigger than the value you specify here. This is a useful feature for hosts which impose a maximum file size quota. The part size must be given in bytes. Useful and frequently used values are 524288 (512 Kilobytes), 1048576 (1 Megabyte), 5242880 (5 Megabytes) and 10485760 (10 Megabytes). If you use a value of 0, no archive splitting will take place and JoomlaPack will produce a single backup archive.

	Important
	This option is only used by the ZIP packer engine. Using it in conjunction with any other packer engine will have no effect.

Maximum database rows dumped per step. This has effect on the default database dump engine and defines the maximum number of rows of a single table which will be extracted in a single step. If you have tables with huge amounts of data per row, it is wise to set this to something significantly lower, let's say 20, in the expense of a slower backup process.

Maximum total size of a single fragment's files, in bytes. Effective in default file list engine. This determines the maximum amount of data to write to the archive in a single step. This defaults to 1Mb, but on very restrictive or slow hosts this might lead to time-outs. You can try setting it to a smaller value in such a case, in the expense of a slower backup process. If you feel adventurous, you can set it to a bigger value to speed things up, but beware of time-outs!

Maximum number of files in a single fragment. Effective in default file list engine. Similar to the above, a single step might be interrupted before the total size is met, as long as the number of files set here is reached. This allows JoomlaPack to efficiently backup large directories with a big number of small files. In such a case, the time spent to put each individual file in the archive - that is, updating the archive's data structures - is more than the time taken to actually read the file. This value is sane enough, but if the process halts with unexpected time-outs, you might want to lower it to something like 20, or even 10. If you have a generous, fast host you could try setting it to 100 or even 200 to speed things up.

Override archiver's chunk size (bytes). Each file is read in small increments, we call chunks. Larger chunks will result in faster backup, in the price of each of them taking longer, therefore preventing the keep-alive feature from working. Smaller chunks lead to slower backups, therefore it's prudent to decrease the previous parameter (Maximum number of files in a single fragment). If you set this option to the default value (0), JoomlaPack will try to allocate a chunk size using as much memory as it possibly can. On very slow hosts which also need the keep-alive feature, this parameter should be set to a low value, for example 262144 (this is 256Kb), or even lower, for example 65536 (64Kb). Values lower than this indicate that your server is too slow and using JoomlaPack on it may not always yield successful results.

Do not use file_get_contents in the archiver. Effective in ZIP and JPA archiver engines. By default, these archivers will use the PHP function file_get_contents() if available, to increase the file processing speed. On a few buggy hosts, or on hosts with weird settings, this might not work as expected. Selecting this options overrides JoomlaPack's default behaviour and always uses a conservative fall back method for reading the files to be archived.

Do not compress files over this size (in bytes). Effective in ZIP and JPA archiver engines. Both formats use the GZip library to compress files before putting them into the archive. However, compression takes a significant amount of time and it won't result into significant space gains when applied to certain file types (e.g. archives, media files, ISO images, etc). In order to save time and avoid timing out, JoomlaPack will store files of size equal or greater to this value uncompressed. If you have a very slow host you might want to reduce it to about a half. Increasing it is not really recommended, unless you are sure timeouts will not happen due to very lax settings.

Maximum chunk size for ZIP Central Directory glueing. Effective in ZIP archiver engine. A ZIP file consists if two parts: the data section, where compressed file data is stored and the Central Directory section where a "packing list" of all files contained in the archive is stored. In order to achieve a speedy operation, JoomlaPack stores these two parts as two physically different files and "glues" them together at the end of the backup process. This value indicates how much data of the Central Directory will be read at a time when "glueing" together these two parts. If you have a very low memory limit you should reduce this value to something much smaller, about a fourth of the default. Increasing it is not recommended.

Maximum execution time allowance [seconds]. Effective for the Smart algorithm. JoomlaPack tries to determine the maximum execution time allowance of PHP before running anything under the smart algorithm. It is possible that your installation does not report this value, or that it has no limit. Imposing no time limit will, on the former case, lead to PHP time-outs, on the latter case it can lead to web server time-outs. This setting defines the maximum execution time JoomlaPack will allow the smart algorithm to use. Of course, if the PHP setting is lower, that value will override the setting here. If you are on a restrictive or slow server, you might want to lower this to a value between 5 and 10.

Minimum execution time allowance to trigger Slow algorithm [seconds]. Effective for the Smart algorithm. If the maximum allowed execution time reported by PHP is lower than this setting, the Smart algorithm will fall back to the Slow algorithm, to avoid potential time-outs. This setting is too conservative per default. If you are on a very slow server, please use the Slow algorithm instead of tweaking this value.

Maximum run time bias (in % of maximum_execution_time). Effective for the Smart algorithm. JoomlaPack knows how much time has elapsed between two individual steps. If the elapsed time is more than a given amount, the AJAX call / page load operation is stopped and execution will resume within a new AJAX call / page load. This amount is calculated by maximum execution time times run time bias divided by 100. So, if your maximum execution time is 10 seconds and you set the runtime bias to 75, the formula yields 10 x 75 / 100 = 7.5 seconds. In other words, if 7.5 seconds has elapsed executing consecutive steps the control will be passed back to the browser and execution will resume in the next AJAX call or page load. If the Smart algorithm fails all the time, you might want to lower this setting to 50, or an even lower value.

Maximum operations per step. This option allows you to strike a balance between the slow and smart algorithms. We are aware of some hosts where the Smart algorithm would fail, but the Slow would work fine. It turns out that these hosts apply some tricks that confuse the Smart algorithm into not working. We also know that the Slow algorithm is slower than a snail on flypaper. This option lets you define the maximum number of the smallest backup steps which can occur during a Smart algorithm's go. Putting a value around 10 made the Smart algorithm work on servers which previously supported only the Slow algorithm. The result was a much faster than the Slow algorithm and much slower the regular Smart algorithm. Finding the "right" value for this option is a matter of trial and error.

	Note
	Remember that for this setting to have any effect you must use the Smart algorithm!

	Tip
	Setting a value of 1 here simulates the behavior of the Slow algorithm.

Tip

If you want to make your backup faster, you can try setting a higher value. On some very fast hosts we were able to raise it to around 2000! Setting it too high will not break your backup on most hosts; the Smart algorithm's timeout avoidance routine will kick in to protect you. However, on some hosts - and depending on the settings of the maximum time allowance and bias - this might be just not possible, causing a backup failure. As stated above, finding the "right" value is subject to trial and error. Think of it as the "overclocking" feature of JoomlaPack.

Absolute path to mysqldump binary. The absolute path to the executable file of the mysqldump command-line utility. You might need to ask your host for that. It is usually /usr/bin/mysqldump on Linux hosts.

Data chunk for database dump post processing. During post-processing, the raw mysqldump raw file is read in small chunks, individual queries are identified and post-processed. This setting defines how many bytes will be read off the file at once. Keep it low to avoid memory exhaustion errors, or set it to a higher value to speed up the execution.

Maximum number of lines a query can have. This determines the maximum number of lines in the raw mysqldump file which can be regarded as part of a single query. This setting is generous enough, unless you have a huge table with dozens of columns and a lot of indices and keys.

Maximum number of lines to process per step. How many queries to post process in a single step. Post-processing requires a significant amount of time. The default value is good for most servers, but if you are on a restrictive host or have some very big database rows (for instance, huge articles), you might want to lower it to 50, or even 20, just to be on the safe side.