Do not use the Manage Backups page to download backup archives
In the vast majority of use cases the backup archive filenames are relatively easy to guess as they contain known items (your site's domain name) and easily guessable facts (the time and date of the backup — there are only 86400 seconds in a day). Between that and most users making use of the default location for storing the backup archives would make for a very predictable download URL that anyone, including malicious actors who want to subvert your site or exfiltrate data from it, could use to download the backup archives of your site. Moreover, even if when the filename itself isn't easily predictable —like when using the [RANDOM] variable which adds a long string of randomly generated characters to the filename— it is still possible that the download URL can be subverted.
To protect your site's security and the privacy of its users we apply a number of security measures, including the following:
-
By default, we append a long, random string which makes guessing filenames impractical.
-
The default backup output directory is not accessible from the web when using most Apache and IIS servers.
-
We warn you not use the default backup output directory, using a different one which is ideally outside the web root.
-
If you use a different backup output directory we check that it's either outside the web root, or otherwise inaccessible from the web. If neither is true we warn you about it.
As a result, you cannot download the backups directly through your browser. To make downloads from the Manage Backups page possible we “proxy” the download of the file through PHP code in our software. This download "proxy" only works when you are logged in, thereby protecting you from a malicious adversary subverting this URL to download the backup archives. In short, if they can't log into your site as a privileged user they can't download the backup archives. Conversely, if they can log into your site as a privileged user your site is already hacked which is why no further protection is necessary.
However, even this approach this has a few drawbacks.
It is possible that other software running inside the CMS (in the case of Akeeba Backup) or the server (in the case of Akeeba Solo) may output its own text, or cause PHP to emit notices and warnings. This data will appear before the start of a backup archive, therefore corrupting it.
Moreover, large backup archives may fail to download in full (they will get truncated). This happens because both PHP and the web server have timeout limits, i.e. they will stop responding after a while. While on most servers we can reset the PHP timeout limit, there is no way to do the same for the web server. It is, therefore, possible that you will end with a truncated backup archive if you have a restrictive server, the backup archive is big enough, your download speed is slow enough, or a combination of these factors.
For this reason we warn you to NOT use the Manage Backups page to download the backup archives and, in fact, disable this feature by default. If you decide to follow the instructions appearing in the Manage Backups page to enable downloads you do so at your own risk, keeping in mind that we have warned you that this method will most likely fail, and we won't be able to provide assistance.
![[Note]](/media/com_docimport/admonition/note.png) | Note |
|---|---|
|
Other backup software do offer download links for backup archives. They do that at the expense of security and privacy. They always place backups in a web-accessible folder and rely solely on appending a long string of randomly generated characters to the end of the filename to make the download URLs harder to guess. This is NOT enough for realistic security! It is possible that an attacker can find out the download URL using malware, such as malicious browser extensions, inspect your traffic to your site if you're not using HTTPS, or otherwise trick you or another administrator into disclosing the download URL of the backup archives. This is why we decided to NOT reply on this kind of security theatre for our backup archives. We do security the right way, even if it's at the expense of convenience. In the end of the day, a backup archive downloaded by an attacker will most likely result in a fine from your local data protection authority. In Europe these files can be as high as 4% of the total global turnover of the company, or 20 million Euros, whichever is higher. We reckon that mild inconvenience is much more desirable than costing you 20 million Euros. |
The recommended way to download backup archives is using FTP or SFTP.
Finding where your backup archives are stored
If you are using the default backup output directory, i.e. if you have not explicitly changed its location, your backup archives are stored in the following directory relative to your site's public web root folder:
-
Akeeba Backup for Joomla, versions 3 to 8:
administrator/components/com_akeeba/backup -
Akeeba Backup for Joomla, versions 9 and later:
administrator/components/com_akeebabackup/backup -
Akeeba Backup for WordPress:
wp-content/plugins/akeebabackupwp/app/backupsNote The path on WordPress may be different.
By default, plugins are installed in
wp-content/plugins. If you have customised this path please change this in the path above.By default, the plugin folder for Akeeba Backup for WordPress is
akeebabackupwp. This, however, can be different if you installed the plugin by manually uploading to a different folder, or if WordPress decided to append something like-1,-2etc to it if it found a previous, deactivated installation it could not overwrite. In this case, please change this in the path above. -
Akeeba Solo:
app/backups
It is also possible that you have selected a different directory altogether. Please activate the backup profile used to take a backup in the main control panel page of Akeeba Backup / Akeeba Solo and click on the Configuration button. Look at the Output Directory option. If it reads [DEFAULT_OUTPUT] you are using the default output directories documented above. In any other case please check what you have configured.
Finally, please note that you can see the output folder in the Manage Backups page by clicking the info icon on the right-hand side column of the backup row. It tells you which directory the backup archive is stored in.
Which backups can you download
Please keep in mind that the Manage Backups page lists all backup attempts, regardless of whether they succeeded or whether their backup archive are still on your server.
You can only download the backup archives of the backup records which appear with an OK (green checkmark) in the Status column of the Manage Backups page.
If a record appears with a blue cloud icon (Remote) the backup archive is stored remotely, not on your server. You will need to either download it directly from the remote storage, or use the Manage Remotely Stored Files button to fetch the backup archive files back to your server.
Which files you need to download
Go to the Manage Backups page and click the info icon next to the backup record you want to download. You will see its name, something like site-www.example.com-20221231-0123-foobar.jpa, site-www.example.com-20221231-0123-foobar.jps, or site-www.example.com-20221231-0123-foobar.zip.
This is one of the files you need to download but possibly not the only one.
Depending on your configuration options and the size of your site's backup your backup may consist of multiple files. For .jpa and .jps archives the additional files have the same base name but extensions .j01, .j02, .j03 and so on. For .zip archives the additional files have the same base name but extensions .z01, .z02, .z03 and so on. You need to download all of these files. These are called archive part files. With the default settings, only backups which are over 2000 MiB long will be split into multiple files. (This can be changed with the Part Size for Split Archives setting in the Configuration page).
Think of archives with multiple archive part files (called split archives) like a really big book, like War and Peace. It is too large to print in a single printed volume; it would be too big and difficult to handle. What happens is that publishers break it down to two or three volumes (individual printed books). You cannot read the book if you are missing a volume. You cannot make sense of the book if you read the volumes in random order. You need all volumes and read them in the right order to figure out the story. That's exactly what happens with split archives: you need all of the backup archive part files and read them in the correct order to extract the backup archive when restoring the site.
To make your life easier, make sure that you order the display of files by name. All archive part files will appear listed one below the other, making it easy for you to locate them.
If you are unsure how many backup archive part files there are, go to the Manage Backups page and click on the info button of the backup you want to download. On that popup, look for the “What's it called?” label. It will tell you how many files your backup consists of and what these files are called.
Using FTP or SFTP to download the backup archives
We strongly recommend that you use a real FTP or SFTP client application, such as CyberDuck (Windows, macOS) or FileZilla (Windows, macOS, Linux). If you are on Linux note that most file managers, e.g. those used in GNOME and KDE, also support FTP and SFTP but may be more complicated to use.
If you do not know how to connect to your site with FTP or SFTP and/or how to navigate to the backup output folder please ask your host. Helping you with that is their responsibility; you are paying them for this help service. Kindly note that we cannot possibly know how to connect to your server; we are not your host, we do not have a way to find this information out.
If you are using FTP please make sure that you have set up your FTP client software to always use Binary transfer for downloaded files. If unsure, please refer to the documentation of your FTP client. Using ASCII (sometimes called Text) mode for downloading backup archives will corrupt them, making it impossible to restore them.
SFTP always transfers files in binary mode. It is also much more secure. Whenever you have a choice, we very strongly recommend using SFTP to download backup archives.
After downloading the backup archives please check their sizes on your local computer and compare them to the sizes reported by the FTP/SFTP server. They must be identical down to the byte count. If the sizes are different it's very likely that your FTP/SFTP transfer failed even if you did not receive an error. We have spotted some particularly egregious hosts (like OVH) which terminate an FTP download before the file is fully downloaded, without raising an error. Users think their files are downloaded and only discover the bitter truth when they try restoring those files, usually when their site is no longer accessible.