Support

If a backup you start in your browser fails after you have switched to another browser tab, browser window or a different application the problem is caused by background tab suspension ("Sleeping tabs") feature in your browser or a third party browser extension with the same effect.

Starting with Microsoft Edge (released in late January 2021) the browser will suspend the JavaScript timers for tabs which have been in the background for a certain period of time. This is a feature meant to save battery life on mobile devices but it will also interfere with your backups if they need more than the configured period of time to complete and you switch to a different browser tab, browser window or application.

The same applies for third party extensions which promise to suspend, put to sleep or otherwise reduce memory and CPU consumption of inactive tabs.

There are two ways to work around this issue.

The simplest and least practical way to address this issue is to start a backup and not switch to a different browser tab, browser window or another application until the backup is complete. Make sure that your computer does not go to sleep or gets disconnected from network while the backup is running. This may be impractical for long running backups.

Alternatively, you can tell your browser not to suspend the background tabs of your own sites.

For Microsoft Edge you need to visit Options, System and click the Add button next to the Never put these sites to sleep label. Enter the domain name of your site like so: [*.]example.com where example.com is the domain name of your site.

For third party extensions you need to consult their documentation or disable them in your browser.

Please note that the nature of these features does not allow web developers, like Akeeba Ltd, to communicate to the browser or the browser extension that the tab should never be put to sleep without involving the user. Doing so would allow every site to do that, even when their use of JavaScript timers is not useful to the user (web trackers, advertisements, ...) or outright malicious (e.g. cryptominers). Please do not report this behavior as a bug. It's a deliberate choice of your browser or the browser extension(s) you are using. We are not in control of any of it; you are.

By default they are stored in administrator/components/com_akeeba/backup under your site's root.

However, you can always set a different Output Directory in the Configuration page of Akeeba Backup. If unsure, click the info icon next to the backup entry. Akeeba Backup will tell you where your backup archive is stored in, relative to your site's root.

Also note that if you are using Akeeba Backup Professional it is possible that your backup archive is stored remotely (e.g. on Amazon S3). In this case the backup record appears with a cloud icon in the status column which is described as "Remote". In this case you can use the Manage Remotely Stored Files button in the rightmost column to manage the remotely stored files.

If you are using Akeeba Backup Professional and your backup is stored remotely as explained in the previous question: you need to use the Manage Remotely Stored Files button. It will allow you to fetch the backup archive back to your web server or download it directly (if supported by the remote storage engine).

If your backup is stored on the same server as your site we very strongly recommend using SFTP, FTPS or FTP to download it from your server. You can use a third party tool such as FileZilla (macOS, Windows, Linux) or CyberDuck (macOS, Windows). If you are using FTP or FTPS please remember to set your tool to download files in Binary transfer mode. If you use ASCII or Auto you might end up with corrupt backup archives. If you are using SFTP you don't need to do that; SFTP always transfers files in binary mode.

If you have no access to your site's files via SFTP, FTPS or FTP you can use the Download button in Akeeba Backup's interface. However, please keep in mind that files over 10MB might end up being corrupt or truncated for reasons that have to do with third party plugins running on your site and / or your server setup. We generally do not recommend this method.

We also do not recommend using your hosting control panel's file manager to transfer files over 10MB for similar reasons. If you find that your backup archives are corrupt please either use SFTP, FTPS or FTP; or upload them to remote storage (e.g. Amazon S3) using Akeeba Backup Professional and download them from the remote storage using any appropriate tool, including your browser. The difference between using your browser to download files from your site's server and downloading from the site of a remote storage provider is that the former is designed for transferring relatively small files while the latter is specifically designed and optimized for large file transfers without random, silent failures.

In either case please note that your backup archive may consist of multiple files with the same name and different, sequentially numbered extensions. For example, a JPA archive may consist of a file with a .jpa extension and zero or more files with the extensions .j01, .j02 and so on. A JPS archive may consist of a file with a .jps extension and zero or more files with the extensions .j01, .j02 and so on. A ZIP archive may consist of a file with a .zip extension and zero or more files with the extensions .z01, .z02 and so on. Whether this happens depends on the size of your site's backup and the Part Size for Archive Splitting in the Configuration page of the backup profile you are using. If you see multiple files you need to download all of them. You cannot restore a site if one or more of these files is missing. These are NOT separate archives; these are archive parts. Think of it as taking a printed page and cutting it in for vertical strips. If any of the strips is missing you cannot read the content of the page. You need all strips to figure out the content. An archive is like a page, a backup archive part file is like a strip of the page.

You get a list of warnings during backup stating "Unreadable file /some/file; check permissions" or "Unreadable directory /some/directory; check permissions". This means that when Akeeba Backup asked PHP to list the contents of the directory or read the contents of the file, PHP replied that this was impossible. Here we will attempt to find out why and fix it.

DOUBLE CHECK A BACKUP IF YOU GET THIS KIND OF WARNINGS ! These warnings mean that files or whole directories have not been backed up. It is very likely that some overly important files of your site (or even all of the files of your site!) did not make it into the archive. This will cause the restored site to be broken. That's why we call them warnings: they warn you that something may be broken so that you can investigate and make sure you fix it - or be 100% that you can safely ignore them.

Unreadable directories

A directory becomes unreadable because of its permissions. Please note that some directories are supposed to be unreadable. For example, on a live host, it is common to have directories such as cgi-bin, awstats, etc which are not part of your Joomla installation and are there to provide some service offered by your host. If you are not sure, ask your host about that. These directories MUST NOT be backed up, or restoration will be impossible. If one of those directories appears as an unwritable directory, please go to Akeeba Backup, click on Files and Directories Exclusion and exclude those directories from the backup (the leftmost icon next to the folder's name must be yellow).

If you get that kind of warning for <root>, it means that your site's root is not readable. This will cause Akeeba Backup to be unable to backup your site. In this case, using your favourite FTP application, connect to your site and look for your site's web root. It is usually a directory named public_html, httpdocs, htdocs, www or something like that. If unsure, ask your host. Change its permissions to 0755. If you can not do that yourself, ask your host to do that for you. If they refuse on the grounds of security, explain to them that a. it is necessary to backup your site and b. they are probably doing something wrong if other users are allowed to browse your site's files (and swiftly change to a more secure host!).

If you are on a Windows server, there is no notion of permissions. Instead, you have to edit the Windows ACLs to allow PHP to be able to list the contents of your site's directories. Since this procedure is highly dependent on the server setup, please ask your host to do it for you. If you are on a local server, please read on.

If you are on a Linux machine, change the permissions of the root of your website to 0755. For example, if you're trying to restore to /var/www/mysite you have to issue a command like chmod -Rf 0755 /var/www/mysite

If you are on a Mac OS X machine, use the Finder to find your site's root. Right-click or Control-click on it and select Get Info. Scroll down to the Sharing & Permissions slider and expand it if it's not already expanded. Find the row where the Name column reads everyone and set the Privilege to Read & Write.

If you are on a Windows use Windows explorer to find your site's root. Right click on it, select Properties and click on the Security tab. Click on the Edit... button. If you can't see a user named Everyone, you will have to click on the Add... button, type Everyone in the big text box and click OK. Now click on the Everyone user and then take a look at the list of checkboxes below. Click the Accept checkbox on the Full Control row (the topmost one). Click on OK, then again on OK.

The same instructions apply for any other directory which may appear to be unwritable. Instead of your site's root, do this procedure to the directory which appears unwritable.

Unreadable files

Unreadable files are not accessible by PHP for reading. The fact that you can access them with FTP or that you can view them in your browser DOES NOT mean that they are readable by PHP. This is a common misconception. If you feel that this can't be true, please read the Security Information chapter of this documentation. We are not responsible about how your web server and UNIX-based Operating Systems work, but we can help work around the problem!

All you have to do is to find the file referenced by the warning message and give it 0644 permissions (read & write for the user, read only for the group and everyone). That's all there is to it.

Please note that some files (e.g. .ftpquota on your site's root) are not supposed to be readable. These are special files that do not belong to your Joomla installation and are put on your site by your host. These files must not be backed up, otherwise restoration will fail. Go to Akeeba Backup and click on Files and Directories Exclusion to find those files and remove them from the backup. If you are unsure whether a file is put in there by your host, Joomla or one of its extensions please ask your host. If it is a file put there by the host, exclude it. If it is not, change its permissions to 0644.

Before you do anything else, make sure that your server fulfils the minimum requirements of the version of Akeeba Backup you are trying to use. The PHP and Joomla! version compatibility matrix is published on our site.

	Tip
	If you have tried all of the above and your site is hosted on one.com, check out the special instructions at the bottom of this answer.

The most usual backup issues manifest themselves by means of an "AJAX Loading Error" message. This error message by itself means pretty much nothing. All it tells us is that the backup failed. Normally, you should post your log file to our ticket system so that we can take a look at it to figure out what went wrong. However, there are some common issues you can work around yourself, without looking at the log file. You should follow the following troubleshooting steps one by one until your backup works.

If you still have issues and you are a paying subscriber with an active subscription to Akeeba Backup Professional please file a support ticket. For your convenience, please make sure you indicate that you have gone through the steps on this page when posting your support request to avoid a canned reply that you should check this page first. Thank you.

Special notes for one.com customers

If your site is hosted on one.com please follow these instructions if the above doesn't work:

Please note that the above settings do cause the backup to run at half speed, but this is required for your backup to run under smoothly on one.com. We'd like to thank one.com's tech support for testing and providing these safe settings.

Before you even begin thinking why the upload failed, please make sure that you have the PHP cURL extension installed and activated in your server's php.ini. If you are unsure, please check the System, System Information page of your site. If you see a cURL section in the PHP Information tab then cURL is installed and all is fine. If you don't see anything about cURL being mentioned in there, well, you have to install and enable it on your server. Ask your host or server administrator about it.

The next thing you should do is a sanity check. Make sure that you have copied your Access Key and Secret Key correctly. Especially the latter, may have up to two equal signs at the end. These are required. Then, check your bucket name. The bucket must already exist; Akeeba Backup can not create it for you. The bucket must also be writable by the user whose Access and Secret Keys you're using; you can check that in the Amazon S3 Console. Moreover, do note that the bucket name is case sensitive. This means that Abc, ABC, abc and AbC are four different bucket names, as far as S3 is concerned.

	Warning
	Amazon warns AGAINST using uppercase letters in your bucket names. If you use an uppercase or mixed case bucket name it is possible that you will get an error message stating that the signatures don't match, or that the bucket does not exist. If this is what you get, please try creating a new bucket with lowercase-only letters BEFORE trying any of the following instructions.

If you are using the V2 signature and only then, let's try making sure that the SSL setting doesn't cause the problem. First go to Akeeba Backup's Configuration page and find the Data Processing Engine drop down. Click the Configure button next to it. A new pane opens below. Find the Use SSL checkbox and make sure it is not checked. Try a new backup. If your bucket name contains dots you MUST disable the Use SSL checkbox. This is a limitation of the Amazon S3 service due to the way their SSL certificate is set up. It is best to have a bucket name which consists of only lowercase letters (a-z), numbers (0-9) and dashes and which does not begin with a dash.

The other thing you have to check is that your host's firewall allows access to Amazon S3. Ask them if they have a firewall which blocks outgoing connections. In this case, please tell them to allow TCP/IP connections to ports 80 and 443 of s3.amazonaws.com. If they request an IP, please tell them that this domain name is a multicast one and they have to run host s3.amazonaws.com from their server to obtain the IP. It doesn't matter if this sounds like Chinese to you, your host's support technicians will understand (or should, at the very least).

Finally, some hosts do not play very well with Amazon S3's multi-part upload feature which allows us to upload a very big archive file in 5MB chunks. In this case you will have to follow Plan B which is to have Akeeba Backup split the archive file in small chunks, one file per chunk, and then upload each of those chunks in one go. This is a two-legged solution.

For the first leg of the solution, please go to Akeeba Backup's Configuration page and find the Data Processing Engine drop down. Click the Configure button next to it. A new pane opens below. Check the Disable multipart uploads option and make sure that the Process each part immediately option is not checked.

Now, for the second leg, we have to do some trial and error. Still in Akeeba Backup's Configuration page, find the Archiver Engine drop-down and click on the Configure button next to it. A new pane opens below. Find the Part size for split archives option and select the 49.99 option. Try a new backup. If it crashes while uploading files to Amazon S3, go back to this option and try smaller values, i.e. 20, 10, 5, 2 or even 1, trying a new backup after setting each one of those values.

In very rare cases (less than 3 tickets a year) we have seen hosts which have a transparent proxy in front of the web server. This proxy gets in the way of Akeeba Backup connecting to Amazon S3. There are two distinct problems with such a setup. If the proxy caches the responses from Amazon S3 – it should NEVER cache them due to their headers, i.e. that's a proxy configuration problem – the proxy responds instead of Amazon S3. From Akeeba Backup's perspective the file transfer went through but in reality nothing was uploaded. There is objectively no way for Akeeba Backup to detect the proxy and the proxy should never be caching those requests. Contact your host and ask them to fix their proxy. The other possible problem is that the proxy is stripping some of the request headers such as the Content-Length which is mandatory for uploading files to Amazon S3. You will get an error from S3 claiming the header is missing. No, it's not a bug in Akeeba Backup. We do send the header but your host's proxy is stripping it. It's a bug in your hosting setup. Again, please do contact your host to fix it.

Do remember that the overwhelming majority of the problems you will ever experience with any kind of upload to remote storage with Akeeba Backup are not issues in Akeeba Backup itself but something in your hosting or server setup. Thank you in advance for understanding that we objectively have no control over it and working with us so we can get your host to fix their infrastructure.

As the saying goes, the proof in the pudding is in eating it.

In fact, we very strongly recommend testing your backup files, at least the first time you produce a backup and whenever you make major changes/upgrades to your site. Testing the backup archives is relatively easy. Download and install a local web server package on your computer to create a local testing server environment. Then try restoring your backup file on the local testing server environment.

You can consult our video tutorials and our documentation for information on restoring your backups.

If you run into problems please consult our documentation first. We distill our experience in providing support in our documentation to make it easier for you to find solutions and for us to point you out to tested procedures to identify and address problems without having to type everything from scratch every time someone has a problem. If you are unable to find a solution to your problem you may need to file a support ticket. Filing a support ticket is only possible if you are a paying subscriber with an active subscription to Akeeba Backup.

If you file a support ticket we need the following information from you to provide fast and accurate support. Please remember that we're not sitting behind your shoulder nor can we read your mind. Our replies are based on the information you provide.

Please try to give us raw information, what you did, what happened, what you saw; not your interpretation of what happened. In most cases it follows that had your interpretation of what happened been correct you would already know how to solve the issue and you wouldn't be filing a ticket. If we have to reverse engineer the facts from your interpretation of what happened it's more than likely that we'll make arbitrary assumptions which are wrong, leading to a mutually frustrating support experience.

Finally please bear in mind that support is provided by the same developers who have written and maintain the software. On the upside this means that you get to talk with people who really know what they are doing. On the downside this means that replies come slower since we manage both the code and the support. We kindly ask for your patience and understanding while we work on your and other's issues and our software. Also bear in mind that we are humans and do need to eat, sleep, bathe and take time off to be with our families. We post our working hours on our site. If you file a ticket outside these hours it will take a bit longer to get a reply. Thank you for your understanding!