When the application is taking a backup, it needs to do something with the files it creates (e.g. your database backup) and the files it reads from your server. This is the job of the archiver engine. Typically, it creates a compressed archive in a supported format. Some archiver engines do away with the archive file altogether and transfer the files directly to a different server. Here you will find their configuration parameters in detail.
The ZIP format is the most well known archive format and is integrated in many operating systems and desktop environments, including Windows™, Mac OS X™, KDE and GNOME.
Please note that due to the way the ZIP format is structured and the limitations of PHP and web servers, it is possible that archives generated by the application will appear to be corrupt when opened with a third party extraction utility. They are not. You can either try to configure your third party archiver tool to ignore CRC32 checksums or use our Akeeba Kickstart or Akeeba eXtract Wizard software to perform the extraction.
Furthermore, a lot of third party archive extraction software based on the InfoZIP library such as unzip (Linux, *BSD, Mac OS X), WinRAR and 7-Zip will always report ZIP archives generated by the application as corrupt. This is a bug in their software, as they do not support the official split archive ZIP standard. PKZIP (written by the inventor of the ZIP format) and WinZIP, however, do support the official standard and can extract archives generated by the application.
ZIP Format
- Dereference symlinks
-
This setting is only valid on Linux and compatible *NIX hosts. Normally, when the application encounters 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, the application 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.![[Note]](/media/com_docimport/admonition/note.png)
Note Even though Windows 7 and later supports symbolic links on NTFS formatted drives (the default format for hard drives), it does so in a way that it's not possible for PHP to make use of this feature. As a result, this setting will only work on Linux, FreeBSD, Solaris and other compatible *NIX hosts.
- Part size for split archives
-
The application supports the creation of Split Archives. In a nutshell, your backup archive is spanned across 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 or when transferring the backup archive to remote storage. If you use a value of 0Mb, no archive splitting will take place and the application will produce a single backup archive (default).
![[Warning]](/media/com_docimport/admonition/warning.png)
Warning If you want to transfer your archive files to remote storage automatically it is strongly recommended that you use small values here. Usually 2 to 20Mb work best. The time it takes the post-processing engine to transfer an archive from your server to the remote server equals the part size divided by available bandwidth. Since the available execution time is finite and the available bandwidth is constant, the only way to avoid a timeout is by creating small parts.
- Chunk size for large files processing
-
Each file is read in small increments, we call chunks, while being backed up. Larger chunks will result in a faster backup, at the price of taking longer to process each one of them and risking a timeout. Smaller chunks lead to slower but safer backups. On very slow hosts, this parameter should be set to a low value, for example 256Kb, or even lower - especially true if you constantly get timeout errors when backing up large files. On fast hosts you may want to increase this value in order to speed up your backup operation.
- Archive permissions
-
This options lets you choose the permissions the generated backup archive files will have.
Note This option only applies on LInux, macOS, FreeBSD, Solaris and other UNIX-based server environments. It does not apply to Windows servers.
The default option is 0666 which allows any user on the server to read and modify / delete the archive. This is intentional. Many servers, especially the ones set up by using prepackaged LAMP server virtual machine images on public cloud providers, are set up to run Apache and PHP as an unprivileged user which is different to the user the site is hosted under / you log in with. Backup archives are created by the user PHP runs under (the former) whereas FTP / SFTP runs under the user you are logging into as (the latter). This disparity means that any other permissions would make it impossible for you to download and/or delete backup archives via FTP or SFTP. Hence the default value being 0666 which allows both users (the one Apache/PHP runs under and the one FTP/SFTP runs under) to read and write to the backup archive files.
Another option is 0600 which only allows the user PHP runs under to have read and write access to the backup archives. This is very strongly recommended on properly set up servers where the effective PHP user is the same as the user of your hosting account, therefore the same as the FTP and SFTP user. Commercial hosting environments using PHP-FPM, PHP under FastCGI, chroot jails or one virtual machine per site fall under this category. If unsure try using 0600 and check whether you can download and delete the backup archive via FTP or SFTP. If you can't you may want to use one of the other two permissions options.
The 0644 option sits somewhere in between the two previous options and is meant for the misconfigured servers with different effective users. Unlike 0666, the 0644 permissions will allow you to download the backup archives via FTP / SFTP but not delete them. You can still delete the leftover files from your server using Akeeba Backup or your hosting control panel's file manager (if one is provided).
- Big file threshold
-
Files over this size will be stored in the archive file uncompressed. Do note that in order for a file to be compressed, the application has to load it in its entirety to memory, compress it and then write it to disk. As a rule of thumb, you need to have free memory equal to 1.8 times the size of the file to compress, e.g. 18Mb for a 10Mb file. Furthermore, compression is resource intensive and will increase the time to produce a backup. If this value is too high, you might run into timeout errors. On most servers a value between 1 and 5Mb works best.
- Chunk size for Central Directory processing
-
At the end of the ZIP archive creation we have to attach a lookup table containing the names of all included files to the end of the archive file. This table is called the Central Directory. We have to do this in small pieces, called chunks, to avoid timeout or memory exhaustion errors. It is recommended that you leave the default value (1Mb) unless you know what you're doing.
About the ZIP file format and its compatibility with third party software
The ZIP archive format needs to store CRC32 checksums for
each file placed into the archive. We use PHP's hash_file
function to calculate the CRC32 checksum of all files (for those
curious, the corresponding algorithm in PHP is called
crc32b). If this built-in PHP function is not
available, or the crc32b algorithm has not been compiled into
PHP, or it fails to produce a checksum for any reason we use a
fake CRC32 value of 000000. This will be reported as a checksum
error or CRC32 error by most third party archive extraction
tools such as 7-zip, WinZIP etc.
| Note |
|---|---|
|
The CRC32 checksum calculation for each file is also resource intensive. Producing ZIP files takes longer and consumes more memory than producing JPA archives. If unsure, use the JPA format. |
Further to that, all ZIP archives produced by Akeeba Backup are designated as spanned (a.k.a. split or multipart) archives, even when they consist of a single file. This is intentional; we do not know in advance if we need to create multiple archive part files and we cannot retroactively apply the spanned archive designation when we need to do that. This designation is part of the official ZIP specification, sections 4.3.3, 4.4.1.5, and the entirety of the 8. sections. Unfortunately, not all third party archiver tools claiming compatibility with the ZIP format properly support it. All archiver tools based on the Info-ZIP library —such as the unzip command which is part of Info-ZIP itself, present in virtually all Linux distributions and used by the hosting control panels' file manager feature— do NOT support spanned archives. They will fail to extract them even if you have all of the archive parts present. The same applies for the built-in ZIP support in Windows, macOS and of course Linux desktop environments such as KDE, GNOME, Mate, Cinnamon, etc. You will need to use PKZIP or 7-Zip. Linux users will have to drop to the command-line and do some file manipulation. Alternatively, you can use Akeeba Kickstart on any web server —even a local web server created with a prepackaged tool such as MAMP, WAMPserver, or XAMPP— or the command-line.
As you can understand, using the ZIP archive format does NOT really make it easier for you to manage archive files. If anything, it introduces complications because of how some servers are misconfigured and the fact that most of the popular ZIP extraction tools only implement a subset of the ZIP specification which is not enough to extract backup archives correctly.
The JPA format was conceived as an alternative to ZIP, designed to be extremely suitable for PHP scripts. The trick is that the JPA format doesn't store a checksum for each file - therefore it reduces the processing overhead during archiving - and it doesn't use a "lookup table" (central directory) as ZIP does. Both of these design decisions lead to extremely fast, low resource usage archiving processes.
![[Tip]](/media/com_docimport/admonition/tip.png) | Tip |
|---|---|
|
It is recommended that you use the JPA format for all of your backups. You can extract JPA files either on your server using Akeeba Kickstart, or on your desktop using Akeeba eXtract Wizard. |
JPA Format
The settings for this engine are identical to those used in the ZIP engine.
The JPS is a further evolution of the JPA format, designed to improve compression rates and enhance the security of your data by encrypting the entire archive's contents with the industry standard AES-128 encryption format. This ensures that even in the unlikely event of your backup files ending up in the hands of a hacker or another untrusted party, they would be useless. All information in the archive (including file names and file data) are encrypted. Without the password nobody can deduce any information about your site by examining a JPS archive. The contents of all files in the archive are compressed and encrypted in 64Kb blocks, allowing for better compression ratios over the JPA format.
![[Important]](/media/com_docimport/admonition/important.png) | Important |
|---|---|
|
The JPS format requires that both the zlib and mcrypt or OpenSSL PHP extensions are installed and activated on your server. Please keep in mind that even if your site is using HTTPS this doesn't mean that you have the OpenSSL PHP extension installed. You usually have to ask your host to enable it for you. Moreover, the mcrypt or openssl library installed on the server must support AES-128 in CBC mode. If any of these conditions is not met, the backup process will halt with an error mentioning that encryption is not enabled on your server. In this case, please contact your host with the information in this paragraph so that they can perform the necessary server-side changes. |
| Important |
|---|---|
|
JPS archives can only be extracted on hosts fulfilling the same prerequisites (zlib and mcrypt or openssl PHP extensions installed and activated). |
| Important |
|---|---|
|
We STRONGLY recommend using long (64 or more characters), completely random passwords which make use of lowercase and uppercase Latin letters, numbers and special characters (top row on US-format keyboards). Use a password manager to generate and store these passwords. Taking these precautions make password brute forcing with conventional technology highly impractical in the foreseeable future. |
JPS Format
The settings for this engine are:
- Encryption key
-
This is the password to be used for encrypting the archive. For the sake of security, you are encouraged to enter a long passphrase which is hard to guess. You can always leave it blank; the application will ask you for a passphrase before taking a backup. If you want to automate your backups please note that only the native CRON method allows you to specify a passphrase in the command line. All other methods require you to enter your passphrase here.
Warning The key is case sensitive. This means that Abc, ABC and abc are three completely different keys!
- Dereference symlinks
-
This setting is only valid on Linux and compatible *NIX hosts. Normally, when the application encounters 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, the application 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.Note Even though Windows 7 supports symbolic links, it does so in a way that it's not possible for PHP to make use of this feature. As a result, this setting will only work on Linux, FreeBSD, Solaris and other compatible *NIX hosts.
- Part size for split archives
-
The application supports 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 or when transferring the backup archive to remote storage. If you use a value of 0Mb, no archive splitting will take place and the application will produce a single backup archive (default).
Warning If you want to transfer your archive files to remote storage automatically it is strongly recommended that you use small values here. Usually 2 to 20Mb work best. The time it takes the post-processing engine to transfer an archive from your server to the remote server equals part size divided by available bandwidth. Since the available execution time is finite and the available bandwidth is constant, the only way to avoid a timeout is creating small parts.
- Archive permissions
-
This options lets you choose the permissions the generated backup archive files will have.
Note This option only applies on LInux, macOS, FreeBSD, Solaris and other UNIX-based server environments. It does not apply to Windows servers.
The default option is 0666 which allows any user on the server to read and modify / delete the archive. This is intentional. Many servers, especially the ones set up by using prepackaged LAMP server virtual machine images on public cloud providers, are set up to run Apache and PHP as an unprivileged user which is different to the user the site is hosted under / you log in with. Backup archives are created by the user PHP runs under (the former) whereas FTP / SFTP runs under the user you are logging into as (the latter). This disparity means that any other permissions would make it impossible for you to download and/or delete backup archives via FTP or SFTP. Hence the default value being 0666 which allows both users (the one Apache/PHP runs under and the one FTP/SFTP runs under) to read and write to the backup archive files.
Another option is 0600 which only allows the user PHP runs under to have read and write access to the backup archives. This is very strongly recommended on properly set up servers where the effective PHP user is the same as the user of your hosting account, therefore the same as the FTP and SFTP user. Commercial hosting environments using PHP-FPM, PHP under FastCGI, chroot jails or one virtual machine per site fall under this category. If unsure try using 0600 and check whether you can download and delete the backup archive via FTP or SFTP. If you can't you may want to use one of the other two permissions options.
The 0644 option sits somewhere in between the two previous options and is meant for the misconfigured servers with different effective users. Unlike 0666, the 0644 permissions will allow you to download the backup archives via FTP / SFTP but not delete them. You can still delete the leftover files from your server using Akeeba Backup or your hosting control panel's file manager (if one is provided).
| Important |
|---|---|
|
This feature is not meant for everyday users. It is designed for web professionals. If you don't understand the rest of this section, please do not use it. Akeeba Backup is equally useful as a site migration tool without using DirectFTP. |
| Note |
|---|---|
|
This engine uses PHP's native FTP functions. This may not work if your host has disabled PHP's native FTP functions or if your remote FTP server is incompatible with them. In this case you may want to use the DirectFTP over cURL engine instead. |
The DirectFTP engine allows power users to directly export a website from one server to another, without the need to download the backup file to their PC, upload it and extract it on the other server. In order to do so, instead of backing up to an archive, it directly writes the backed up files to the remote server using FTP, hence the name.
Do note that when using the DirectFTP engine, the post-processing engine will not run, as there is no archive produced.
In a nutshell, when this option is activated, Akeeba Backup operates as usual, backing up your database and files. Instead of putting the site files, installer files and database dump inside a backup archive, it transfers them to a remote server using FTP. You can then visit the installation URL on the remote server to complete the site transfer progress.
| Warning |
|---|---|
|
This is considered an advanced feature. Since there are many things which might go wrong in the process and due to the fact that the success of the operation depends on the server configuration of both the originating and target servers, you are advised not to use it unless you know what you're doing. Moreover, bear in mind that the target server must not contain any files! If it does, it may not be possible to overwrite them, leading to an incomplete site transfer. Finally note that due to the backup process being split in several steps (to avoid web server timeouts) a new FTP connection has to be created on each backup step, i.e. for every few files uploaded to your remote server. At best this makes the transfer extremely slow. At worst, your remote FTP server will decline further connections because it sees the same remote IP opening and closing FTP connections in rapid succession. We strongly recommend uploading entire backup archives using the post-processing engines instead of using this feature. |
Your originating server must support PHP's FTP extensions and not have its FTP functions blocked. Your originating server must not block FTP communication to the remote (target) server. Some hosts apply a firewall policy which requires you to specify to which hosts your server can connect. In such a case you might need to allow communication to your remote host.
Normally, remote FTP connections consume a lot of time, therefore DirectFTP is very prone to time-outs. Theoretically, Akeeba Backup can automatically estimate the time required for transferring each file and avoid timing out. However, this is not always technically possible. In such a case you might want to lower the maximum execution time allowance and bias in the Configuration. Do note that large files have to be transferred in a single step, as most PHP and FTP configuration combinations disallow resuming uploads (chunked uploads). This means that a very large file, or a very large database dump may cause the process to fail with a timeout error.
DirectFTP
The available configuration options are:
-
Host name. The hostname of your remote (target) server, e.g.
ftp.example.com. You must NOT enter the ftp:// protocol prefix. If you do, Akeeba Backup will try to remove it automatically and issue a warning about it. -
Port. The TCP/IP port of your remote host's FTP server. It's usually 21.
-
User name. The username you have to use to connect to the remote FTP server.
-
Password. The password you have to use to connect to the remote FTP server.
-
Initial directory. The absolute FTP directory to your remote site's location where your site will be cloned to. This is provided by your hosting company. Do not ask us to tell you what you should put in here because we can't possibly know. There is an easy way to find it, though. Connect to your target FTP server with FileZilla. Navigate to the web server's root (usually it's a subdirectory named httpdocs, htdocs, public_html, http_docs or www). Above the right-hand folder pane you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.
-
Use FTP over SSL. If your remote server supports secure FTP connections over SSL (they have to be explicit SSL; implicit SSL is not supported), you can enable this feature. In such a case you will most probably have to change the port. Please ask your hosting company to provide you with more information on whether they support this feature and what port you should use. You must note that this feature must also be supported by your originating server as well.
-
Use passive mode. Normally you should enable it, as it is the most common and firewall-safe transfer mode supported by FTP servers. Sometimes, you remote server might require active FTP transfers. In such a case please disable this, but bear in mind that your originating server might not support active FTP transfers, which usually requires tweaking the firewall!
| Important |
|---|---|
|
This feature is not meant for everyday users. It is designed for web professionals. If you don't understand the rest of this section, please do not use it. Akeeba Backup is equally useful as a site migration tool without using DirectFTP. |
| Note |
|---|---|
|
This engine uses PHP's cURL functions. This may not work if your host has not installed or enabled the cURL functions. In this case you may want to use the DirectFTP engine instead. |
The DirectFTP over cURL engine allows power users to directly export a website from one server to another, without the need to download the backup file to their PC, upload it and extract it on the other server. In order to do so, instead of backing up to an archive, it directly writes the backed up files to the remote server using FTP, hence the name.
Do note that when using the DirectFTP engine, the post-processing engine will not run, as there is no archive produced.
In a nutshell, when this option is activated, Akeeba Backup operates as usual, backing up your database and files. Instead of putting the site files, installer files and database dump inside a backup archive, it transfers them to a remote server using FTP. You can then visit the installation URL on the remote server to complete the site transfer progress.
| Warning |
|---|---|
|
This is considered an advanced feature. Since there are many things which might go wrong in the process and due to the fact that the success of the operation depends on the server configuration of both the originating and target servers, you are advised not to use it unless you know what you're doing. Moreover, bear in mind that the target server must not contain any files! If it does, it may not be possible to overwrite them, leading to an incomplete site transfer. Finally note that due to the nature of the cURL library a new FTP connection has to be created for each and every file uploaded to your remote server. At best this makes the transfer extremely slow. At worst, your remote FTP server will decline further connections because it sees the same remote IP opening and closing FTP connections in rapid succession. We strongly recommend uploading entire backup archives using the post-processing engines instead of using this feature. |
Your originating server must support PHP's cURL extension. Your originating server must not block FTP communication to the remote (target) server. Some hosts apply a firewall policy which requires you to specify to which hosts your server can connect. In such a case you might need to allow communication to your remote host.
Normally, remote FTP connections consume a lot of time, therefore DirectFTP over cURL is very prone to time-outs. Theoretically, Akeeba Backup can automatically estimate the time required for transferring each file and avoid timing out. However, this is not always technically possible. In such a case you might want to lower the maximum execution time allowance and bias in the Configuration. Do note that large files have to be transferred in a single step, as most PHP and FTP configuration combinations disallow resuming uploads (chunked uploads). This means that a very large file, or a very large database dump may cause the process to fail with a timeout error.
The available configuration options are:
-
Host name. The hostname of your remote (target) server, e.g.
ftp.example.com. You must NOT enter the ftp:// protocol prefix. If you do, Akeeba Backup will try to remove it automatically and issue a warning about it. -
Port. The TCP/IP port of your remote host's FTP server. It's usually 21.
-
User name. The username you have to use to connect to the remote FTP server.
-
Password. The password you have to use to connect to the remote FTP server.
-
Initial directory. The absolute FTP directory to your remote site's location where your site will be cloned to. This is provided by your hosting company. Do not ask us to tell you what you should put in here because we can't possibly know. There is an easy way to find it, though. Connect to your target FTP server with FileZilla. Navigate to the web server's root (usually it's a subdirectory named httpdocs, htdocs, public_html, http_docs or www). Above the right-hand folder pane you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.
-
Use FTP over SSL. If your remote server supports secure FTP connections over SSL (they have to be explicit SSL; implicit SSL is not supported), you can enable this feature. In such a case you will most probably have to change the port. Please ask your hosting company to provide you with more information on whether they support this feature and what port you should use. You must note that this feature must also be supported by your originating server as well.
-
Use passive mode. Normally you should enable it, as it is the most common and firewall-safe transfer mode supported by FTP servers. Sometimes, you remote server might require active FTP transfers. In such a case please disable this, but bear in mind that your originating server might not support active FTP transfers, which usually requires tweaking the firewall!
-
Passive mode workaround. Some badly configured / misbehaving servers report the wrong IP address when you enable the passive mode. Usually they report their internal network IP address (something like 127.0.0.1 or 192.168.1.123) instead of their public, Internet-accessible IP address. This erroneous information confuses FTP information, causing uploads to stall and eventually fail. Enabling this workaround option instructs cURL to ignore the IP address reported by the server and instead use the server's public IP address, as seen by your server. In most cases this works much better, therefore we recommend leaving this option turned on if you're not sure. You should only disable it in case of an exotic setup where the FTP server uses two different public IP addresses for the control and data channels.
| Important |
|---|---|
|
This feature is only available in the Akeeba Backup Professional edition. |
| Important |
|---|---|
|
This feature is not meant for everyday users. It is designed for web professionals. If you don't understand the rest of this section, please do not use it. Akeeba Backup is equally useful as a site migration tool without using DirectSFTP. |
| Note |
|---|---|
|
This engine uses the PHP extension called SSH2. The SSH2 extension is still marked as an alpha and is not enabled by default or even provided by many commercial hosts. In this case you may want to use the DirectSFTP over cURL engine instead which uses PHP's cURL extension, available on most hosts. |
The DirectSFTP engine allows power users to directly export a website from one server to another, without the need to download the backup file to their PC, upload it and extract it on the other server. In order to do so, instead of backing up to an archive, it directly writes the backed up files to the remote server using SFTP (Secure File Transfer Protocol over SSH), hence the name.
Do note that when using the DirectSFTP engine, the post-processing engine will not run, as there is no archive produced.
In a nutshell, when this option is activated, Akeeba Backup operates as usual, backing up your database and files. Instead of putting the site files, installer files and database dump inside a backup archive, it transfers them to a remote server using SFTP. You can then visit the installation URL on the remote server to complete the site transfer progress.
| Warning |
|---|---|
|
This is considered an advanced feature. Since there are many things which might go wrong in the process and due to the fact that the success of the operation depends on the server configuration of both the originating and target servers, you are advised not to use it unless you know what you're doing. Moreover, bear in mind that the target server must not contain any files! If it does, it may not be possible to overwrite them, leading to an incomplete site transfer. |
Your originating server (where you are backing up from) must a. support PHP's SSH2 extensions, b. allow outbound TCP/IP connections to your target host's SSH port and c. not have the SFTP functions of the SSH2 extension blocked. Please note that some hosts apply a firewall policy which requires you to specify to which hosts your server can connect. In such a case you might need to allow communication to your remote host.
Normally, remote SFTP connections consume a lot of time, therefore DirectSFTP is very prone to time-outs. Theoretically, Akeeba Backup can automatically estimate the time required for transferring each file and avoid timing out. However, this is not always technically possible. In such a case you might want to lower the maximum execution time allowance and bias in the Configuration. Do note that large files have to be transferred in a single step, as most PHP and SFTP configuration combinations disallow resuming uploads (chunked uploads). This means that a very large file, or a very large database dump may cause the process to fail with a timeout error.
DirectSFTP
The available configuration options are:
-
Host name. The hostname of your remote (target) server, e.g.
sftp.example.com. You must NOT enter the sftp:// or ssh:// protocol prefix. If you do, Akeeba Backup will try to remove it automatically and issue a warning about it. -
Port. The TCP/IP port of your remote host's FTP server. It's usually 22.
-
User name. The username you have to use to connect to the remote SFTP server. This field must always be used, even when you're using certificate authentication.
-
Password. The password you have to use to connect to the remote SFTP server. If you are using certificate authentication please enter the encryption key of your private key file. However, if you're using certificate authentication and your private key file is not encrypted please leave this field blank.
-
Private Key File (advanced). Only use this field when you want to perform certificate authentication. Enter the absolute path to your private SSH key file. If your private key file is encrypted with a password please provide the password in the Password field above.
Important If the libssh2 library that the SSH2 extension of PHP is using is compiled against GnuTLS (instead of OpenSSL) you will NOT be able to use encrypted private key files. This has to do with bugs / missing features of GnuTLS, not our code. If you can't get certificate authentication to work please try providing an unencrypted private key file and leave the Password field blank.
-
Public Key File (advanced). Only use this field when you want to perform certificate authentication. Enter the absolute path to your public SSH key file.
-
Initial directory. The absolute FTP directory to your remote site's location where your site will be cloned to. This is provided by your hosting company. Do not ask us to tell you what you should put in here because we can't possibly know. There is an easy way to find it, though. Connect to your target FTP server with FileZilla. Navigate to the web server's root (usually it's a subdirectory named httpdocs, htdocs, public_html, http_docs or www). Above the right-hand folder pane you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.
| Important |
|---|---|
|
This feature is only available in the Akeeba Backup Professional edition. |
| Important |
|---|---|
|
This feature is not meant for everyday users. It is designed for web professionals. If you don't understand the rest of this section, please do not use it. Akeeba Backup is equally useful as a site migration tool without using DirectSFTP. |
| Note |
|---|---|
|
This engine uses the PHP cURL extension. If your host has disabled the cURL extension but has enabled the SSH2 PHP extension you may want to use the DirectSFTP engine instead which uses PHP's SSH2 extension. |
The DirectSFTP engine allows power users to directly export a website from one server to another, without the need to download the backup file to their PC, upload it and extract it on the other server. In order to do so, instead of backing up to an archive, it directly writes the backed up files to the remote server using SFTP (Secure File Transfer Protocol over SSH), hence the name.
Do note that when using the DirectSFTP engine, the post-processing engine will not run, as there is no archive produced.
In a nutshell, when this option is activated, Akeeba Backup operates as usual, backing up your database and files. Instead of putting the site files, installer files and database dump inside a backup archive, it transfers them to a remote server using SFTP. You can then visit the installation URL on the remote server to complete the site transfer progress.
| Warning |
|---|---|
|
This is considered an advanced feature. Since there are many things which might go wrong in the process and due to the fact that the success of the operation depends on the server configuration of both the originating and target servers, you are advised not to use it unless you know what you're doing. Moreover, bear in mind that the target server must not contain any files! If it does, it may not be possible to overwrite them, leading to an incomplete site transfer. |
Your originating server (where you are backing up from) must a. have PHP's cURL extension installed and activated, b. have the cURL extension compiled with SFTP support and c. allow outbound TCP/IP connections to your target host's SSH port. Please note that some hosts provide the cURL extension without SFTP support. This feature will NOT work on these hosts. Moreover, some hosts apply a firewall policy which requires you to specify to which hosts your server can connect. In such a case you might need to allow communication to your remote host.
Normally, remote SFTP connections consume a lot of time, therefore DirectSFTP is very prone to time-outs. Theoretically, Akeeba Backup can automatically estimate the time required for transferring each file and avoid timing out. However, this is not always technically possible. In such a case you might want to lower the maximum execution time allowance and bias in the Configuration. Do note that large files have to be transferred in a single step, as most PHP and SFTP configuration combinations disallow resuming uploads (chunked uploads). This means that a very large file, or a very large database dump may cause the process to fail with a timeout error.
The available configuration options are:
-
Host name. The hostname of your remote (target) server, e.g.
sftp.example.com. You must NOT enter the sftp:// or ssh:// protocol prefix. If you do, Akeeba Backup will try to remove it automatically and issue a warning about it. -
Port. The TCP/IP port of your remote host's FTP server. It's usually 22.
-
User name. The username you have to use to connect to the remote SFTP server. This field must always be used, even when you're using certificate authentication.
-
Password. The password you have to use to connect to the remote SFTP server. If you are using certificate authentication please enter the encryption key of your private key file. However, if you're using certificate authentication and your private key file is not encrypted please leave this field blank.
-
Private Key File (advanced). Only use this field when you want to perform certificate authentication. Enter the absolute path to your private SSH key file. If your private key file is encrypted with a password please provide the password in the Password field above.
Important If cURL is compiled against GnuTLS (instead of OpenSSL) you will NOT be able to use encrypted private key files. This has to do with bugs / missing features of GnuTLS, not our code. If you can't get certificate authentication to work please try providing an unencrypted private key file and leave the Password field blank.
-
Public Key File (advanced). Only use this field when you want to perform certificate authentication. Enter the absolute path to your public SSH key file. This is optional: some versions of the cURL library allow you to not provide a public key file, using the information of the private key file to derive this information. If in doubt, always provide both private and public key files to perform certificate authentication.
-
Initial directory. The absolute FTP directory to your remote site's location where your site will be cloned to. This is provided by your hosting company. Do not ask us to tell you what you should put in here because we can't possibly know. There is an easy way to find it, though. Connect to your target FTP server with FileZilla. Navigate to the web server's root (usually it's a subdirectory named httpdocs, htdocs, public_html, http_docs or www). Above the right-hand folder pane you will see a text box with a path. Copy this path and paste it to Akeeba Backup's setting.
This engine produces ZIP archives using PHP's built-in ZIP archive class. It is only recommended for extremely small sites hosted on very slow hosts. If you have a larger site or quite big files you can expect that this engine will time out, crash the backup or throw a memory outage error. Also note that this engine has absolutely no options and is bound to fail on hosts which impose limitations on the maximum size per file.
Frankly, this is the worst archiver engine. It was added because some users thought that it would be faster (really, it is not). Well, try it out if you want. As soon as it causes backup errors do not ask for support, just switch to the classic ZIP engine or, even better, the JPA engine.