The options page is split in sections by means of standard Joomla! slider panes. The page itself contains two areas entitled "Common Settings" and "Profile Settings". The former contains the configuration options which are common among all profiles, while the latter contains the profile-specific settings.
The Basic tab options on the Common Settings section are:
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
|
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. |
The Frontend tab options on the Common Settings section are:
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.
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. |
The Basic tab options on the Profile Settings section are:
Backup Type. It defines the kind of backup you'd like to take. The backup types for JoomlaPack are:
Full site 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 options which creates a full backup of your site.
Database only which backs up only the Joomla! database. It results in a single SQL file which can be used with any MySQL administration utility (e.g. phpMyAdmin) to restore only your database should disaster strike. This option is recommended for advanced users only.
All databases, no files which creates an archive file containing SQL files with dumps of your main site's database and all the defined multiple databases. The database dumps can be restored by either any MySQL administration tool (for example phpMyAdmin) or by JoomlaPack itself.
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:
The configured host name of your site
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 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.
This is a nice security measure, as it generates a 64 character semi-random string (the MD5 hash of the server's time, accurate up to the millisecond). This is almost impossible to guess, unless you know the exact millisecond the template name was processed by the server. Yes, the chance to find this is very, very slim indeed! Please note that some hosts impose a limit on the maximum length of a file's name. On such hosts using RANDOM will most probably result to backup failure for no other apparent reason.
Log level. This options controls the verbosity of the JoomlaPack's log file. The available log levels are:
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 recommended setting, reports fatal errors as well as warnings. JoomlaPack 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!
All information. As "Error and Warnings" but also includes some informative messages on JoomlaPack'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 JoomlaPack's operation. This is what we need to help you in case of a problem.
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 directory instead of using this log level!
The Advanced tab options on the Profile Settings section 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:
Default compatibility. JoomlaPack will not try to enforce MySQL compatibility mode. Recommended if you are making a backup for security reasons, or if you are migrating to a host with MySQL 5 or greater.
Force MySQL 4 compatible. JoomlaPack will request from your database server to provide table definitions (CREATE TABLE commands) in a MySQL 4 friendly format.
![]() | Important |
---|---|
This option will take effect in MySQL 4.1 or greater database hosts. If you use it on older MySQL version the backup might fail! |
![]() | Warning |
---|---|
Do not use this option if your site is already running on MySQL 4.x or if both your site and the target host run on MySQL 5.x. Otherwise, crucial information about the database's encoding might be lost in the process, causing broken text on sites using non-ASCII character sets. |
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:
JoomlaPack will only perform a single step at a time. This is the fail-safe setting, but it is also slowing the backup down because a new HTTP request has to be made for every step. Use this option only if the Smart algorithm doesn't work for you.
JoomlaPack will try to group together and perform many steps in a single go. The success of this algorithm depends on the availability of certain server configuration information to JoomlaPack. Since it tries to be a best compromise between speed and efficiency, it is possible that it fails. You can control this algorithm's behaviour through the Magic Numbers configuration options.
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:
JoomlaPack will only perform a single step at a time. This is the fail-safe setting, but it is also slowing the backup down because a new HTTP request has to be made for every step. Use this option only if the Smart algorithm doesn't work for you.
JoomlaPack will try to group together and perform many steps in a single go. The success of this algorithm depends on the availability of certain server configuration information to JoomlaPack. Since it tries to be a best compromise between speed and efficiency, it is possible that it fails. You can control this algorithm's behaviour through the Magic Numbers configuration options.
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:
Pure PHP file system scanner. This is the classic default engine available since the first versions of JoomlaPack. It uses standard PHP functions to read the contents of the directories and determine the files to be backed up.
Joomla!-powered file system scanner. This engine uses the Joomla! Framework functions for accessing the file system and reading the contents of the directories. It is somewhat more efficient for sites with large directories than the Pure PHP engine.
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:
Joomla!-powered database dump. This is the classic default engine available since JoomlaPack 1.1. It uses the Joomla! database connectivity library to access the database and produce the SQL dump.
mysqldump-powered database dump. This is a new, hybrid mode engine. It should be used by advanced users only! The command line utility mysqldump is used to produce an SQL dump of your database. Afterwards, PHP code post-processes the resulting file, taking it into a form suitable for use with the restoration script (JoomlaPack Installer).
![]() | Warning |
---|---|
This option is only compatible with JoomlaPack Installer 3. Even though it is possible to select it together with JoomlaPack Installer 2, the resulting backup archive will not restore! This is due to peculiarities of that restoration script and it is not considered a bug. JoomlaPack will not warn you of such an erroneous combination either. |
![]() | Important |
---|---|
In order to use this option the
mysqldump utility must be available on your
system, the |
Archiver engine. This option controls what JoomlaPack will do with the files to be backed up. The available options are:
JPA JoomlaPack Archive. JoomlaPack will produce a backup archive in the JPA format. JPA is a renowned archive format, optimised for efficiency, developed in order to combat problems pertaining to ZIP files created by PHP.
ZIP, using PHP functions. JoomlaPack will produce a backup archive in the standard ZIP format. The ZIP format is compatible with PKZIP and is natively supported by all modern operating systems, including but not limited to Windows and Linux.
![]() | Warning |
---|---|
Depending on server configuration, it is possible that the resulting archive might appear corrupt during extraction. This is a limitation originating from how PHP works and trying to avoid the risk of timing out during archiving. For this reason, if this option is selected, JoomlaPack will issue a warning in the Control Panel page with a link to more information on this matter. |
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:
JoomlaPack Installer 2 (JPI2). This is the older incarnation of the restoration script. It behaves generally well, but it can't check the validity of FTP settings nor use them during restoration for writing to the configuration.php. It also has issues with error reporting should a database error occur. Finally, it won't work with the SQL dump produced by mysqldump. It is included partly for historical reasons and partly for convenience, should the JPI3 won't work for you.
JoomlaPack Installer 3 (JPI3). JPI3 is the recommended restoration script. It is build upon the Joomla! Framework, just like the original Joomla! 1.5.x installer. It is very powerful, behaves excellently with huge SQL dumps and supports writing to your configuration.php using FTP access functions, should this be necessary. This is the default option.
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:
AJAX (Refreshless). When set, this option forces JoomlaPack to use the AJAX (Web 2.0) method for contacting with the server. All server communication happens in the background, using specialised JavaScript code to perform server requests and process the results. It is the fastest method. However, this option requires a compatible browser (IE6+, Firefox, Konqueror 3.5.9+, etc.). It is also possible that it won't work on certain hosts, for example free hosts with forced pop up advertisements or with certain proxies and/or firewalls which modify the server response before it reaches the browser. For these cases, we recommend using JavaScript redirects.
JavaScript Redirects. This is the fail-safe method. Instead of using background server requests, JoomlaPack will reload the page every time it needs to contact the server. Since the amount of data transferred is much higher than that with AJAX, it is slower, but because the server data is parsed mostly on server-side it is bound to work in the broadest spectrum of server-proxy-firewall-browser combinations imaginable.
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. |
The Magic Numbers options allow expert users to fine-tune the internal workings of JoomlaPack's backup engine. Modifying the default values should not be necessary for normal operation. We discourage using this options unless you know what you are doing or you are instructed to do so by our support personel. The available options are:
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. |
The mysqldump tab options on the Profile Settings section define the operation of the homonymous database dump engine and are:
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.