Manage Backups
This page is the single place you can review all your Akeeba Backup backup history, as well as administer the backup files. The bulk of the page consists of a standard Joomla!™ list table. Each row represents a backup attempt and displays a whole lot of information:
- The check box column
-
Clicking the check box on the leftmost cell of a row selects this backup for an operation to be applied to it. Operations are activated by clicking on tool bar buttons. In case of an operation allowing a single row to be selected, the topmost selected row is considered as the sole selection.
- Frozen indicator
-
You can mark important backups as "frozen", creating a protected record. Once a record has been marked as frozen, the following will happen:
-
Its files cannot be deleted with the Delete Files button
-
It cannot be deleted with the Delete button
-
For remote backups, you cannot delete the remotely stored archives
-
It doesn't participate in any quotas, local or remote including the obsolete records quotas
-
- Description
-
Displays the description you have set when you started the backup. If your backup has a comment attached to it, an info icon will also appear. Hovering your mouse over the info icon will show you a preview of that comment.
To the left of the description there's an icon indicating the backup origin, e.g. Backend, Frontend, JSON API, CLI and so on. Hover over it to see what each icon means.
Below the description you will see the date and time of the backup. The date / time format, timezone and timezone suffix are configured in the component's Options page.
- Profile
-
Displays the numeric identifier (and description, if available) of the backup profile used during the backup. It is possible that since the time of the backup the profile may have been modified or even deleted!
Below it you will see the backup type. It indicates the backup type. A backup type may not be provided if the backup profile has been deleted in the meantime.
- Duration
-
The duration of the backup in hours : minutes : seconds format. This information is not available for failed backups!
- Status
-
Indicates the status of the backup. Hover over the icon to see what it means. It will be one of:
- OK (Green)
-
A complete backup whose backup archive is available for download.
- Obsolete (Gray)
-
A complete backup whose backup archive is either deleted, or was overwritten by another backup attempt.
![[Note]](/media/com_docimport/admonition/note.png)
Note If you move your backup output directory's location, all your previous backups will appear as "Obsolete", even though you might have moved these backup files as well. This is not a bug. Akeeba Backup internally stores the absolute path to the backup files. When you move the output directory its absolute path changes, so Akeeba Backup is unable to locate the old backup files.
![[Important]](/media/com_docimport/admonition/important.png)
Important If your host uses MySQL 4.0 the status will always appear as Obsolete and you will be unable to download the backup archive through your browser, as the result of limitations of this ancient, obsolete and unsupported MySQL version. You can still use your favorite FTP client to download the backup archives, though.
- Remote (Blue)
-
Indicates a complete backup which has been uploaded to remote storage (e.g. Dropbox, Amazon S3, CloudFiles and so on), but it is no longer stored on your server. You can fetch the backup archive backup to your server any time (as long as you haven't manually removed the file from the remote storage) in order to restore it, clicking the Manage Remote Files link on the right-hand column.
Note Not all remote storage engines support fetching back backup archives. Currently, only FTP, Amazon S3, CloudFiles and Dropbox support this feature.
- Pending (Yellow)
-
A backup attempt which is still running. You should not see any such record, unless a backup attempt started while you were loading this page. In this case, you should not navigate to the Control Panel page! Doing so would invalidate the backup and wreck havoc. You have been warned! Another reason to see such an entry is a backup attempt which failed with a PHP fatal error, or which was abruptly interrupted (by the user or a PHP error). In this case, you can safely delete the entry and get rid of the backup file as well.
- Failed (Red)
-
A backup attempt which failed with a catchable error condition.
- Size
-
The total size of the backup archive in MB. If the files are not available on your server, i.e. the record is marked as "obsolete" or "remote", the size appears inside parentheses to let you know that the files are not available for download.
- Manage and Download
-
Depending on the status of the backup it will show two or more buttons:
-
. Opens a popup which allows you to download the backup archive file(s) directly from your browser. However, this is NOT recommended. The only guaranteed method of downloading your backup archives error-free is using FTP or SFTP in BINARY transfer mode. Anything else has the potential to CORRUPT your backup archives for reasons beyond our control!
Important Some backup archives may consist of more than one files. These are called multipart backup archives.
You MUST download all part files to have a backup archive set which can be used to extract all files and restore a site.
All files have the same base name, for example site-www.example.com-20220925-105300-abcdef012345, but different extensions. JPA archives have the extensions .jpa, .j01, .j02, …; JPS archives have the extensions .jps, .j01, .j02, …; ZIP archives have the extensions .zip, .z01, .z02, …
The part files of a multipart backup archive are NOT separate archives; you cannot extract its one of them individually. The are all parts of the same archive and they all need to be present for the archive to be able to be extracted. The order of the parts is .j01, .j02, …, .jpa for JPA archives; .j01, .j02, …, .jps for JPS archives; and .z01, .z02, …, .zip for ZIP archives. That is to say, the numbered part files come first in the numeric order defined by their extension, the file with the .jpa, .jps or .zip extension comes last.
You can extract multipart archives using the integrated restoration but also Akeeba Kickstart Core, our free of charge archive extraction tool. It can run on a web server — even a local web server created with MAMP, WAMPserver, XAMPP etc — or, for expert users, on the command line.
-
. If the file is stored on a remote storage location, e.g. Amazon S3 or a remote FTP server, you will also see this button. Clicking on it will allow you to transfer the files back to your server, download them directly from the remote location or remove them from the remote storage.
-
>. If Akeeba Backup failed to upload your backup archive to remote storage you will be shown this button. Clicking it will have Akeeba Backup retry the upload to remote storage.
-
. If your backup archive has a backup ID you will also see this button. Clicking it takes you to the View Log page to see the backup log file. If the backup status is anything other than OK this button will be grayed over as Akeeba Backup can't guarantee that the log file is present. Hover your mouse over the button to get the Log file ID which you'll need in the View Log page to look for this log file.
-
. Clicking this button tells you if the backup archive is currently present on your server, where to find it (relative to your site's root directory) and what is the name of the backup archive file. This allows you to download the backup archive over FTP/SFTP as discussed above.
-
Clicking on the label of each column allows you to sort the backup entries by the contents of that column. By default, Akeeba Backup sorts the records by the time of backup descending, so that the newest backup attempts will appear on top. Below the header there are four filter boxes. The first one allows you to filter by the backup description. The other two allow you to select a date range so that only backups attempted within this date range will be displayed. You can leave either of these boxes empty to allow an open start or end date respectively. The final box allows you to filter by backup profile.
On the top of the page you can find a tool bar with operations buttons. The Delete button will remove the selected backup attempt entries along with their backup archives (if applicable), whereas the button will only remove the files (if found on your server). The button (Akeeba Backup Professional only) will run the integrated restoration feature for the selected archive file. This feature can be used to restore your backup archive on the same server you backed up from or even a different server (live transfer of your site to another host!). The (available since Akeeba Backup Professional 3.2) allows you to import any ZIP, JPA or JPS file, located anywhere in your server or Amazon S3, in the Manage Backups (formerly "Administer Backup Files") page in order to restore it on this or any other site.
| Note |
|---|---|
|
If you are interested in restoring your backup archives and your site is inaccessible or you're using the free Akeeba Backup Core edition, you can use Akeeba Kickstart to extract the archive and restore it on their server. The procedure is detailed in our Video Tutorials. |
| Important |
|---|---|
|
Integrated restoration is only supported for Full Site and Files Only backup archives. Trying to use it with any other type of backup files will ultimately result in an error. This feature is available only to Akeeba Backup Professional - the paid version. Users of the Akeeba Backup Core version can follow our video tutorials to easily restore their backups using Kickstart. |
Backup description / comment editor
The View / Edit Comment button will open a page showing the description and comment of the currently selected backup row. You can freely edit both the description and the comment on that page and save your changes using the Save & Close button. The same page will open if you click on a backup record's description (appearing as a link).
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 |
|---|---|
|
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.