Before we go on describing the Backup Now page, we have to discuss something important pertaining to the overall backup and restoration process. In order for the restoration to work properly, the original site must have a readable and valid configuration.php on its root. This means that a 'trick' some very few webmasters use, providing a configuration.php which includes an off-server-root PHP file, is incompatible with the restoration procedure. If the 'trick' has been effective on the original site, the installer will have blanks in its options and if the user proceeds with the restoration/installation procedure the site will not work as expected, as crucial options will have the default or no value at all!
Moreover we would like to remind you that restoring to a temporary URL (something like http://www.yourhost.com/~youruser) will NOT work. This has to do with the way Joomla!, Apache and PHP session management works. It has nothing to do with Akeeba Backup. Even if you install straight up Joomla! on a temporary URL you'll have problems logging in or, at the very least, with SEF URLs.
The initial backup page lets you define a short description
(required) and an optional lengthy comment for this backup attempt.
This information will be presented to you in the backup
administration page to help you identify different backups. The
default description contains the date and time of backup. Both the
description and comment will be stored in a file named
README.html inside your archive's
installation directory, but only if the backup
mode is full backup.
Since Akeeba Backup 3.1.b1 both the description and the
comment support Akeeba Backup's file naming "variables", e.g.
[TIME]. These variables are documented in the
configuration option's description. It goes without saying, but
these variables can also be used in the case of automated backups,
e.g. CRON-mode backups.
There are two more fields which may be displayed on this page:
Encryption key. When you are using the JPS (encrypted archive) format the contents of the archive are encrypted using the AES-256 algorithm and this password. In order to extract the archive you will need to enter this password. If you had entered a default password for JPS files in the Configuration page this field is pre-filled with that password.
The password is case-sensitive. ABC, abc and Abc are three different passwords! Also note that the password is non-recoverable. If you lose or forget your password you will not be able to extract your JPS archive.
ANGIE Password. As of Akeeba Backup 3.7.5 the ANGIE installer (embedded in the backup archive) allows you to password protect it. This means that you will have to enter this password before you can restore your site. This feature is designed to prevent unauthorised users from "stumbling" on your site while it's still undergoing restoration and copy your database passwords or obtain other information about your site.
We STRONGLY advise that you always use an ANGIE Password if you intend to restore your site on a live server. This is the only way to prevent accidental information leak.
The password is case-sensitive. ABC, abc and Abc are three different passwords! Unlike the JPS password, setting an ANGIE password will not prevent anyone from extracting the archive and looking at its contents. It will only prevent people attempting to browse your site while you're restoring a backup from seeing potentially confidential information in the installer.
Whenever you are ready to start the backup, just click thebutton. Do note that above the description field, there might be one or more warnings. These are the same warnings appearing in the Control Panel's right-hand pane and act as a reminder.
Default output directory is in use is not an error message! It's just a reminder that the default output directory is a well known location on your site. In theory, a malicious user could figure out the name of the backup archive and download it directly over the web. In order to deter that, Akeeba Backup places a .htaccess file (compatible with virtually all Apache installations) and a web.config file (compatible only with IIS 7) to deter that. If you are using a host which doesn't support the directives of those two files, the contents of that directory may be inadvertently available over the web to malicious users. If in doubt, ask your host. Do not ask us, please, we are not your host.
Our recommendation: consult your host about the proper way to create a backup output directory above your site's root and make it writable by PHP. Then, use that directory as the Output Directory in all of your backup profiles. This method offers the best protection.
Backup progress page
Once you click on the Akeeba Backup disables the Joomla! menu during backup to prevent accidentally switching to a different page.button, the backup progress page appears. You must not navigate away from this page or close your browser window until the backup is complete. Otherwise, the backup process will be interrupted and no backup file will be created (or you'll end up with an incomplete backup file).
The backup progress page consists of a large pane. The top section of the pane lists the steps Akeeba Backup has to take in order to complete your backup. Steps in gray background have not been dealt with yet. Steps in green background have been successfully completed. The step in blue background is the one being currently processed.
Below that, you will find two lines. The first line will show you which table or directory has been backed up in the previous step. This is very important. When the backup crashes, it hasn't necessarily crashed backing up the table or directory you see on the screen. Most likely that the table/directory which has been successfully backed up. The real problem appears in the log file and this is why we are adamant in asking for a backup log to be posted with your support request. The line below is normally used for messages of lesser importance, such as noting the percentage of a table already completed (especially useful when backing up huge tables) and the name of the archive part which was processed by a data processing engine.
The big bar is the overall progress bar and displays an approximation of the backup progress. Do note that during file backup you may see this bar jump back and forth. This is normal and, please, do not report it as a bug. It is exactly how it is supposed to behave. The reason is rather simple. Before your site is backed up, Akeeba Backup doesn't know how many files and directories it contains. As a result, it tries to do an educated guess and display an approximate backup progress. Guesswork is never accurate, which causes some jumping back and forth. Nothing to worry about, your backup is working without a problem.
The next thing you see is time elapsed since the last server response. This resets to 0 when a new backup step is started. If you see a last server response over 300 seconds –except when the application is uploading your backup archives– you can assume that your backup has crashed. Only in this case you should navigate away from the backup page and take a look at the log file for any error messages. Always try different configuration options, especially changing the minimum and maximum execution time, before filing a support request.
Should a minor (non fatal) error occur, Akeeba Backup displays a new Warnings pane with yellow background. This box holds the warnings which have occurred during the backup process, in chronological order. These are also logged in the Akeeba Backup Debug Log and marked with the WARNING label, that is if your log level is at least Errors and Warnings. Usual causes of warnings are unreadable files and directories. Akeeba Backup regards them as minor errors because, even though the backup process can go through, what you get might be a partial backup which doesn't meet your expectations. In case warnings appear on your screen you are advised to review them and assess their importance.
Sometimes your backup may halt with an AJAX error. This means that there was a communications error between the browser and your server. In most cases this is a temporary server or network issue. Depending on your configuration preferences, Akeeba Backup may try to resume the backup after a while. By default, Akeeba Backup will retry resuming the backup at most three consecutive times and after waiting 10 seconds after each error. If the backup cannot be resumed you will receive an error page, at which point your backup has positively failed.
Backup completion page
After the whole process is complete, Akeeba Backup will clean up any temporary files it has created. Akeeba Backup will also clean temporary files and delete incomplete archive files upon detecting a backup failure. Please note that log files are not removed by default. You will have to go to the Manage Backups page, select the failed backup attempt(s) and then click on Delete Files or Delete to have it remove the log files of failed backups.
By that point, your site backup file has been created. You can now navigate out of the backup page and possibly into the backup administration page, clicking on the handy button which appears below the backup completion message.
We have compiled a list of frequently asked questions and their answers, as well as the basic troubleshooting instructions for a backup which appears to not be working. Please do read and follow these instructions. If you need to ask for support because these instructions didn't help you please let us know what you have already tried so we don't waste your time by asking you to do what we've written here and you've already tried.
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.
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
button next to the Never
put these sites to sleep label. Enter the domain name
of your site like so:
example.com is the domain name of your
For third party extensions you need to consult their documentation or disable them in your browser.
By default they are stored in
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 thebutton 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 thebutton. 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.
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
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
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 . Scroll down to the Sharing &
Permissions slider and expand it if it's not already
expanded. Find the row where the Name
everyone and set the
If you are on a Windows use Windows explorer to find your site's root. Right click on it, select and click on the Security tab. Click on the button. If you can't see a user named Everyone, you will have to click on the button, type Everyone in the big text box and click . 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 , then again on .
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 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.
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.
The progress bar you see always tells you the last successful step Akeeba Backup finished executing. That's a very common source of misunderstanding. If the last item you see on a stuck progress bar is some of the last database tables on your site it doesn't necessarily mean that the backup got stuck while backing up the database. It is usually the case that the next step, backing up the files of your site, got stuck. If unsure check the log file.
Are you on Windows, backing up a local site? Some antivirus and backup software may end up locking the backup archive while it's still being created, leading to an error message about the backup archive not being able to be opened for writing. One very notorious case of this kind is WD SmartWare backup software (kudos to our user, Markus, for letting us know). We strongly advise you to turn off or at least temporarily suspend any backup and antivirus software while the backup is in progress.
Another issue on Windows is resource usage, especially on old (Windows XP) and 32-bit versions of Windows. These versions of Windows have a limited capacity of system resources, meaning that they can only keep a very finite number of files open at any time. Combined with a bug in older versions of PHP for Windows this can lead to resource depletion and backup issues, appearing as unreadable files. Please try quitting as many applications as possible, including those running in the background (e.g. those running as system tray icons). It's also a good idea to turn off or temporarily suspend resource-intensive software such as backup and antivirus applications while the backup is running.
Also note that Windows 10 comes with Windows Defender, a combined firewall and antivirus. By default, it will be scanning each and every file that is being read or written by Akeeba Backup. If one of these files is flagged as potentially malicious (for example you have a hacked site that you may or may not know it has been hacked) it might kill the backup. If unsure, please exclude your site's root from Windows Defender's antivirus scanning. Use your favorite search engine to find instructions on how to do that.
Sometimes the backup seems to complete, but it hangs when uploading the backup archive to a remote location (e.g. Dropbox, Amazon S3, an FTP server, ...). If you are not sure, the hang we're describing happens after the progress bar hits 75%. In this case you will need to lower the Part Size for Split Archives setting. Find the Archiver Engine option of the Akeeba Backup's Configuration page and click on the button next to it. The Part Size for Split Archives setting is in the pane which opens below. Try smaller settings until the backup completes. Please note that your backup will now be split in multiple files and you need all of them to be present to restore your backup.
The first thing you must do is to use thebutton in the Control Panel page to automatically adjust a series of configuration parameters to safer settings. The wizard performs benchmarking of your server to determine those values. It is not always 100% accurate, but the settings it creates are at the very least a good starting point for tweaking them manually. If it seems to get stuck for more than three minutes (180 seconds) the first time you run it, reload the page. If it's still stuck try backing up anyway; some server setups don't like the heuristics used by the configuration wizard. However, as soon as you run the wizard it will revert your backup profile settings to safe defaults which means that you should at least be able to use it as a starting point to run a backup.
Make sure that your hosts PHP memory_limit is at least 32MB. Anything lower than that will most likely result to a backup failure. If unsure, ask your host; we can't know this value for sure. If this is an option, ask your host to increase the PHP memory limit. We recommend 128MB or more.
Try visiting the Configuration page and clicking on . This may be necessary if you just upgraded. This simple move will refresh your configuration and pick up the default values for any new parameters which might have been introduced in the new release.
Check your free space. Akeeba Backup is trying to create an archive with your entire database and all of your site's files; it needs adequate free space to do that. If you don't have enough free space, your host will kill the script in mid-process, making Akeeba Backup's interface throw this error. As a rule of thumb, we propose having about 40-50% of your account's allocated quota free.
Some hosts claim to give you "unlimited" space, or an absurd amount like 100GB. According to our experience, they mostly lie. On many occasions the host only gave 100MB or 1GB of space. If unsure, please ask your host about the real free space you have in your account.
If you are using the ZIP archive format it is possible that you run into timeouts. The problem with the ZIP format is that we have to read each file twice. We read it once in order to calculate a "file signature" (properly called a "CRC32 checksum"), then we read it again in order to add it inside the archive. Unfortunately these steps can't be combined and, on top of that, the very slow signature calculation step must be able to run in one go. With larger files and slower hosts this will consistently lead to timeouts. If you suspect this is the case, please use the JPA format setting in the Archiver Engine option of the Akeeba Backup's Configuration page.
Some servers have a very strict limit on the maximum execution time of PHP scripts. By default, Akeeba Backup is configured with a maximum execution time allowance of 14 seconds. In order to work around such hosts, please go to your Akeeba Backup Configuration page and scroll all the way down to the Fine Tuning pane. You will find an option labeled Maximum Execution Time. Select the "Custom..." option and type in 5 in the text box that appears to the right of the drop-down. Click on the button and retry backing up your site. WARNING! NEVER SET THE Minimum execution time TO A VALUE HIGHER THAN 2 SECONDS UNLESS EXPLICITLY ASKED TO DO SO BY THE SUPPORT STAFF, OR YOU WILL GET A BACKUP FAILURE.
We have heard of hosts which require settings even lower than that. If in doubt, ask your host what their PHP maximum_exec_time setting is, then subtract one second and use this value in Akeeba Backup's Maximum Execution Time setting.
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.
If your site is hosted on one.com please follow these instructions if the above doesn't work:
Run the Configuration Wizard but do not take a backup yet
Go to Akeeba Backup's Configuration page and set the following parameters:
Logging Level: Only errors (however, if you want to ask for support in our ticket system you must switch it back to All Information and Debug and try taking a new backup before posting us your log file)
Click the Configure button in the Archiver Engine and set the "Part size for split archives" to 127Mb or less.
Minimum execution time: 10 seconds
Maximum execution time: 7 seconds
Execution time bias: 50%
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.
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 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
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 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
button next to it. A new pane
opens below. Find the Part size for split
archives option and select the
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.
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.
A clear description of your problem. Tell us exactly what you were trying to do, at what exact operation it failed and any error messages which were output on the page. If you can get a screenshot of the error message that's even better. If you are not sure if you're describing the issue adequately, read what you wrote to someone who is not familiar with your issue. If they didn't understand you chances are we won't either. If you do not feel comfortable with your level of English try to provide screenshots or a short (less than 1 minute) video.
Exact version of Akeeba Backup. It's visible on the right-hand pane in Akeeba Backup's Control Panel page.
Exact Joomla, MySQL and PHP version. You can find all of these version numbers in Joomla site's System, System Information page.
A copy of the debug log taken with log level set to
All Information and Debug when the problem
happened. You can download a copy of the log from within the
page. Please do not copy
and paste directly from the log viewer, this will not help
us. Please remember to put the log file inside a ZIP archive
and attach the ZIP archive to your support ticket. If the
ZIP file is over 2MB please upload it to Dropbox, Google
Drive or OneDrive and paste a share URL to it in your
ticket. We kindly request that you do NOT try to attach the
raw log file with a .php extension or a ZIP file containing
it; these files will be automatically rejected by our site
for security reasons.
If you are writing about an error related to the restoration process do not forget to tell us how you extracted the archive file, i.e. using Kickstart or using Akeeba UNiTE. Also do tell us about the method you used to download the backup file to your PC - if applicable - and the method you used to upload the backup file to your host, for example "I used FTP in Binary mode", "I just clicked on the Download button in Akeeba Backup". Remember to mention the exact version of Kickstart you are using; it's printed with very big letters on the top of Kickstart's page.
Finally, do not tell us that "Kickstart x.y.z stuck in the database restoration page" because such a thing is impossible ;) Kickstart extracts the archive. Then it launches ANGIE, the restoration script included in your archive. It's ANGIE restoring the database. Since ANGIE is in the archive, we need to know which version of Akeeba Backup produced the archive. The Kickstart version is completely irrelevant in this case. We need the ANGIE version which is printed in large type at the top of the restoration script's page.
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!