Archiver engines

ZIP format

The ZIP format is the most well known archive format and is integrated in many operating systems and desktop environments, including Windows™, macOS™, KDE and GNOME.

The ZIP format requires the calculation of CRC32 checksums for each file added in the archive. This is a resource intensive operation which will slow down your backup and may lead to timeouts when archiving big files on slow hosts. If this happens, your only choice is not to use the ZIP format; use JPA instead. Unfortunately, we can't do anything about it: it is a combined limitation of the ZIP specification, how PHP works and how your server is set up.

ZIP Format

Dereference symlinks

Normally, when Akeeba Backup 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, Akeeba Backup 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]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, macOS, FreeBSD and other compatible UNIX-family hosts.

Part size for split archives

Akeeba Backup 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. If you use a value of 0Mb, no archive splitting will take place and Akeeba Backup will produce a single backup archive (default).

If you want to post-process your archive files it is suggested that you use small, non-zero values here. 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.

[Important]Important

Split ZIP archives can not be opened with 7-zip, Linux unzip and other GUI clients. Only WinZIP and PKZIP understand them. If you want to extract them, you must use WinZIP, PKZIP or Akeeba Kickstart. This is not an Akeeba Backup "bug", it's a problem with most free archiver extraction tools.

Chunk size for large files processing

Each file is read in small increments, we call chunks, while being copied in the archive. Larger chunks will result in 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]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, Akeeba Backup 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. Joomla! with a lot of plug-ins might consume as much as 16Mb and Akeeba Backup's engine might consume another 5Mb, so plan this value carefully, or you will run into memory exhaustion errors. Compression is also resource intensive and will increase the time to produce a backup. If this value is too high, you might run into timeout errors.

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 chunks so as 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]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.

JPA format

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]Tip

It is recommended that you use the JPA format for all of your backups. You can extract JPA files using Kickstart.

JPA Format

The settings for this engine are identical to those used in the ZIP engine.

Encrypted Archives (JPS format)
[Note]Note

This feature is only available in the Akeeba Backup Professional release.

The JPS is a further evolution of the JPA format, designed with the major goals of improving compression rations and enhancing the security of your data by encrypting the entire archive's contents with the industry standard AES-128 encryption format. The latter goal ensures that even in the unlikely event of your backup files ending up in the hands of hacker or another untrusted party, they would be useless. As per the strictest security standards, all information in the archive (including file names and file data) are encrypted. Without the password nobody can deduct 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.

In order for JPS to work it 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]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.

[Warning]Warning

The key is case sensitive. This means that Abc, ABC and abc are three completely different keys!

You can omit this configuration option but you will have to enter an encryption key when taking a backup. Please note that this is only possible for backups taken with the backend backup and the CLI backup features. You need to enter the JPS password in the Configuration page for your backup to work when using any other backup method such as legacy front-end backup or Akeeba Backup JSON API.

Dereference symlinks

This setting is only valid on Linux and compatible *NIX hosts. Normally, when Akeeba Backup 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, Akeeba Backup 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]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, macOS, FreeBSD and other compatible UNIX-family hosts.

Part size for split archives

Akeeba Backup 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. If you use a value of 0Mb, no archive splitting will take place and Akeeba Backup will produce a single backup archive (default).

If you want to post-process your archive files it is suggested that you use small, non-zero values here. 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]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).

DirectFTP
[Important]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.

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.

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.

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.

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!

DirectFTP over cURL
[Important]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.

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.

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.

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.

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

DirectFTP over cURL

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.

DirectSFTP
[Important]Important

This feature is only available in the Akeeba Backup Professional edition.

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

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.

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.

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.

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

DirectSFTP over cURL
[Important]Important

This feature is only available in the Akeeba Backup Professional edition.

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

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.

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.

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.

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.

DirectSFTP over cURL

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

ZIP using ZIPArchive class

This engine produces ZIP archive using PHP's built-in ZIP archive class. We have not found any practical use case where this is preferable to Akeeba Backup's own ZIP archiver. This is why we wrote the ZIP archiver in the first place.

ZIPArchiver

PHP's ZipArchiver has several limitations which may make it impractical for most sites:

  1. It does not support archive splitting. This may make it impossible to use on servers which impose a maximum file size limit or when you want to transfer your backup archives to remote / cloud storage.

  2. Files are added to the archive asynchronously. The actual file compression into the archive takes place when we try to close the archive at the end of each backup step. This means that we do not know in advance how much time we will need to back up each file added to the archive. As a result you will end up with PHP timeout error unless you use a very low maximum execution time (between 1 and 3 seconds).

  3. The entire list of content of the backup archive is loaded in memory. When backing up large sites this may cause memory outage issues on servers which are memory constrained.

  4. It only supports whichever compression method is the default in the ZIP library used by the PHP ZipArchiver extension. This is determined when your host or your host's Linux distribution compiled and packaged the PHP ZipArchiver extension. In most cases it's Deflate which is compatible with Kickstart and third party archive utilities. In some rare cases it may be no compression (leading to massive backup archives) or a compression method which is not supported by Kickstart and / or third party archive utilities.

We only wrote this feature to prove that it's not a very good fit for taking site backups, despite what a stark minority of extremely vocal users claimed. Having both this method and our own ZIP archiver it's trivial to demonstrate the practical limitations of ZipArchiver for managing very large archive files and prove that there is indeed a reason of existence for our own ZIP archiver implementation.

In short, its only reason of existence is to prove it shouldn't exist in the first place. So, please, do not use it. If you do, your backups will fail at worst, you will be wasting server resources (especially lots of memory) at best. You have been warned.