The backup files are where you told Akeeba Backup to put them, i.e. in the Output directory you specified in the Configuration page.
If you haven't touched the Configuration yet, the default backup output directory is under your web site's root:
Akeeba Backup for Joomla!:
Akeeba Backup for WordPress:
Do you have Akeeba Backup for Joomla! and prefer a video instead of text? View our Downloading your backup files video tutorial. It's free and educative. Give it a try!
The easiest method is by navigating to the Manage Backups page and using the download links on the far right of each entry, but this is not the recommended method.
There have been reports that some server settings in conjunction with certain browsers may prevent you from downloading a usable archive. We recommend AGAINST using the download feature of the Manage Backups (formerly "Administer Backup Files") page for downloading your backup archive.
The suggested, tested and guaranteed method of downloading your backup files is nothing else than using FTP and its variants, such as FTPS, FTPES and SFTP. We recommend using FileZilla as your FTP client.
When you use FTP you must turn on the Binary transfer type or your backup archives will be corrupt! ALWAYS ENABLE THE BINARY TRANSFER MORE WHEN DOWNLOADING OR UPLOADING YOUR ARCHIVES THROUGH FTP, FTPS, SFTP, etc.
Once more, NEVER, EVER, USE THE "AUTO" OR "ASCII" TRANSFER MODES; ALWAYS EXPLICITLY ENABLE THE BINARY TRANSFER MODE OR YOU WILL NOT BE ABLE TO RESTORE YOUR BACKUP.
If you use FileZilla, you can ensure you are using the correct transfer mode by clicking on, and clicking the menu item before downloading your archives. If you disregard this warning and download your files through your browser, test your backups. Do not ask for support on restoring corrupt archives downloaded through the browser. We warned you for a good reason.
Please keep in mind that the backup archive must exist on your server, not remote storage, in the place where Akeeba Backup had originally stored the file when taking a backup to use the integrated Restore feature from the Manage Backups page. If this is not possible or you have no idea where that place would be you can always put the backup archive and kickstart.php on your site's root to restore your site. Both methods are covered in our video tutorials. Please do watch the video tutorials before jumping into any conclusions about the possibility to restore your backups. Thank you.
If you have changed the Output Directory after you have taken a
backup please remember that your existing backup archives
have not been moved. If you do not remember where
the backup archives used to live you need to go to the Manage Backups
page and find the backup record entry. Click on the Info icon at the
far right hand column. It will tell you the location of your backup
archive on your server. Please keep in mind that on Joomla! this
location is relative to the site's
Another very important clue about your backup archive's whereabouts is the Status column. A checkmark on green background means that the backup archive exists on the same server as your site and Akeeba Backup can find it. This is the only type of backup record you can use with the Restore feature on that page. An X on red background indicates a failed backup. There is no backup archive generated for this failed backup attempt. An orange background with a reload sign means that the backup is in progress. You have to wait until this backup attempt finishes running. A grey background with a trashcan icon means that the record is obsolete, i.e. Akeeba Backup can no longer find the backup archive at the location that's recorded in the database (the file cannot be found on your site's server). This could mean that the backup archive has been moved or deleted. See below for more information. A teal background with a cloud icon means that the backup archive was sent to remote storage and then deleted from your site's server. You may be able to fetch it back to your server if the backup archive still exists on the remote server, at the location recorded in the database. See below for more information. Remember that this kind of remotely stored files have to first be fetched back to your site's server and then be restored. For reasons that have to do with the way PHP works it's not possible to restore directly from a remotely stored file.
If your files are really missing, i.e. they no longer exist on the server one of the following may have happened. If you cannot even find a trace of the backup record the look at II and III.
You have or had set up the automatic transfer of backup archives to external storage and the Delete archive after processing option is enabled (it's enabled by default). Go to the Manage Backups page. Find the backup record you want. Check its Status column. If it's a teal icon with a white cloud (tooltip: Remote) the archive file was sent to a remote storage engine and is no longer available on your server. There should be a button in the Manage & Download column next to it. You can use it to fetch the backup archive back to your server.
If you have changed the storage (post-processing) engine of the backup profile, or its settings, after you took the backup then the Manage Backups feature will NOT be able to fetch your archive back to your server. For example, if you switched the backup profile's Post-Processing Engine from Amazon S3 to Microsoft OneDrive or from Amazon S3 to None, or from None to Google Drive, or from one Amazon S3 bucket to another then Akeeba Backup cannot possibly find your backup archive anymore. This should be self-understood.
Moreover, if you have deleted the backup archive from the remote storage location Akeeba Backup will of course be unable to retrieve it for you. In this case you cannot retrieve it yourself either since the file is forever deleted. You could have done that manually, by explicitly clicking on a button clearly labeled as one to delete remotely stored files, from the Manage Remotely Stored Files feature of the Manage Backup page. Furthermore, backup archives can only possibly be automatically deleted from remote storage if BOTH of the following conditions apply: a. you have set up Quotas in the Configuration page and b. you have checked the optional (not checked by default) Enable remote files quotas option in the same Configuration page. Please remember that in this case Akeeba Backup has done what you have explicitly told it to do, even if it's not what you wanted.
Finally, if you have manually removed the files from the remote storage Akeeba Backup will NOT know about it. If you got confused because you manually removed backup archives kindly remember that Akeeba Backup cannot protect you from yourself, especially when you take actions outside of its interface.
Akeeba Backup has a feature which allows you to automatically remove older backup archives based on various criteria (number of backup archives taken, age or size of the backup archives). These are called Quotas and they can be configured per backup profile in the Configuration page of Akeeba Backup. The default setting is to keep the last 3 (THREE) successful backup archives and delete the older ones. Deleted backup archives no longer exist on your server and cannot be retrieved.
If you are unsure whether this is the case, please go to the Configuration page, scroll down to the Quota Settings and review them.
Please remember that Akeeba Backup also has a feature called Obsolete records to keep. By default its value is 50. This controls how many backup records whose files have been removed from your server will be kept in the database and shown in the Manage Backups page. Older backup records are removed until only this many records are left. This means that some older backups, even those stored on remote storage, will NOT be shown in Akeeba Backup's interface. If you have the backup archives for them you can always restore your backups manually, using Kickstart. Please refer to our video tutorials for restoring a backup on any server.
The Manage Backups page allows you to delete either the files of a backup record (manual. You have to explicitly choose backup records in the Manage Backups page and click on the relevant button in the toolbar yourself. This is NOT an automatic action.) or the entire backup record including its files ( ). Both actions are
In both cases the backup archives for that backup record are forever removed from your server. In the latter case the backup record will also be gone from the Manage Backups page.
It's always possible that the backup archive files have been removed due to an action taken externally to Akeeba Backup, either manually or automatically.
Akeeba Backup has a remote JSON API which can be used by third party tools and services to manage all aspects of your backups. If you are using Akeeba Remote Control CLI, WP-CLI or a third party service (such as Watchful or mySites.guru) it's possible that the backup archive files were removed as a result of an action taken through these external tools. Please bear in mind that in this case the responsibility for the action taken does not lie with Akeeba Backup itself but the external tool. Akeeba Backup will execute commands sent to it from properly authenticated remote clients on the behalf of these clients.
Backup archives are simple, regular files stored on your server. It's possible that you have used FTP, SFTP or even your hosting control panel to remove them. Some hosts may also have automated tools which end up removing backup archives automatically for any reason, be it a false positive of a security scanner (very likely if your backup contains a malicious / hacked file!) or just because the host decided for example that your backup archives take too much space or are of a file type they don't want to host on their servers. This is a kind of action that Akeeba Backup cannot protect you against and it's not to blame for.
We recommend that you ALWAYS keep multiple copies of your backup archives in safe locations. Akeeba Backup can only take backups for you, it cannot guarantee that these backups will be available when you most need them. With so many factors outside the control of Akeeba Backup and its developers it is ultimately your responsibility to make sure that backups are tested and available.