Akeeba Backup has won the prestigious Administrator Only Extension J.O.S.C.A.R. Award at J and Beyond 2010. Download it for free to find out why.
Latest Joomla! 2.5/3.x only. We have older versions for past Joomla! 1.5/1.6/1.7/2.5/3.x versions on our site.
- It configures itself for optimal operation with your site. Just click on Configuration Wizard.
- One click backup.
- AJAX powered backup (site and database, database only, files only or incremental files only backup)
- The fastest native PHP backup engine.
- Choose between standard ZIP or highly efficient JPA archive format
- able to exclude specific files, folders
- able to exclude specific database tables or their contents
- Unattended backup mode (CRON job scheduling), fully compatible with Webcron.org
- Backup using any cellphone made after 2007 with a web browser using our exclusive "Lite Mode" (including the cheapest Nokia and Sony Ericsson models!)
- AJAX powered site restoration
- "Kickstart" restore: restore without unpacking backup
- Move your site between hosts without downloading/uploading anything (using the DirectFTP backup engine)
- Archives can be restored on any host. Useful for transferring your site between subdomains/hosts or even to/from your local testing server (XAMPP, WAMPServer, MAMP, Zend Server, etc).
and much much more!
Do not miss out the complimentary companion software (Akeeba Kickstart and Akeeba eXtract Wizard) which are available free of charge from our site. They make working with Akeeba Backup a breeze.
Note: The software is free of charge, its support is not. You need a valid subscription to request support. Its documentation, the troubleshooting wizard and searching the public tickets is free.
*** IF YOU CAN'T FIND HOW TO ENABLE A FEATURE LISTED HERE, PLEASE READ THE (FREE) DOCUMENTATION! ***
However, this one does work and very well too.
Using this package I backed up my 7 year old online site, ftp'd the file to a PC running Windows Vista and Wampserver 2.0 and after using Kickstart (the other neccesary part to this package) was able to have a localhost perfect working copy. Now convinced that any backup would work in the future, and am breathing sighs of relief. All work completed in a very short time span and at no cost. Nicholas deserves the praise given by many users for this work. Many Thanks.
Thank you for your review and your kind words! I would like to take this opportunity to reiterate that an untested backup is not a backup. Meaning, every time you perform a major change on your site (lots of content, restructuring, updating component/modules/plugins/templates) please take a backup and do a test restoration on a local machine, making sure the restored copy works. It only takes an extra 10 minutes and provides you with adequate peace of mind that, should the unthinkable happen, you will be able to recuperate reliably and very fast. And one last thing: you can never have too many backups! Backup, backup, backup - the more often, the better ;)
Akeeba backup is a must have for all Joomla websites. In fact, it's one of a few that live on every website I build.
Thank you Nicholas, Dale and others for all of your hard work. You provide a service to the Joomla Community that is hard to match.
The free version knows everything what is important except cron.
It is extraordinary helpful for me, much thanks!!!
Thank you for your kind words!
You have made a little mistake, though (many people do that, don't worry). The free version of our software (Akeeba Backup Core) does support CRON jobs. In fact, we've been supporting CRON jobs to automate your backups for four years now, ever since the software was called JoomlaPack. You might want to take a quick look at our documentation at https://www.akeebabackup.com/documentation/akeeba-backup-documentation/automating-your-backup.html#frontend-backup
Even if your host supports neither wget nor curl, we still have a solution for you. Very recently, we've cooperated with Webcron.org so that their service could support our web-based automatic backups. Guess what? They made it and they made it super cheap, too. With their current price list, you can backup a medium-sized site every day using Akeeba Backup Core and Webcron.org for less than 10$ per year.
Enjoy your automated backups; they'll certainly help you sleep better at night :)
After having read that the migration process could be somewhat tricky, I decided to simulate the whole work on my local machine first. Then, if it's clear that it can be done and once I know the pitfalls, I'm going to redo the work on the server.
So this is, what I initially used the component for:
1) Creating a backup of a certain website
2) Restoring the website on my local working machine
The installation succeeded without any problems.
The resulting page gave a nice overview of what had been installed (the component, a module and three plugins). Unfortunately, there was no explanation of the purpose of the different plugins (at least not on this page, maybe in documentation). Not a big thing of course, but I preferred to know.
The page went on to give hints to the documentation and the forums, and explained what to do next:
1) configure the component
2) define inclusion/ exclusion filters to define which files to backup
3) creating the first backup
I did what I was told and clicked on the link to the configuration page (link on "successfully-installed-page"). There I got the first warning, which told me that my server was not capable to crypt the settings, and that I was advised not to store any passwords. Since I know better (my server does support crypting!), but it wasn't clear to me if this was probably a "professional only" feature of akeeba backup, I started to search for answers.
Google didn't provide any and support for the component isn't for free. So I decided not to ask, but to take a look at the source. It revealed, that the component does some checks for existing scripts, settings and php functions. Since the scripts and functions are available on my server, it was most likely a missing component setting.
And in fact: After I reviewed the settings and clicked "Save", a post installation wizard showed up. It asked me some questions about which features I liked to use (system restore points, update notifications and a configuration assistant). While I'm not a friend of update notifications, the configuration assistant looked promising. It did some checks for folders and permissions, as well as timeout settings and other stuff. When it finished, I was once more presented a website which let me choose between reviewing settings and doing a backup. This time when I entered the settings, a friendly, greenish message told me, that my settings could be crypted and that it was secure to save passwords (well, as secure as it can be, you know...)
So in the end, the trouble with the encryption capabilities was only due to the fact, that the link on the "successfully-installed-page" skipped the post installation wizard. No problem once you are aware of it.
Most remaining settings were quite self-explanatory, most (if not all of them) provide pop-ups with additional information and examples how to use them.
When selecting a folder for the backups, I really liked to place them somewhere outside my web root. I simply don't like the idea of backups of the site being part of the site themselves (default for backups is [joomla]/administrator/components/com_akeeba/backups/[backup_file]). At least, akeeba is smart enough not to backup existing backups when creating new ones.
However, for some reason it was not possible to define a folder for the backups somewhere outside the webroot. I guess this is related to joomla's FTP-layer, which I have enabled. My website uses an FTP-account, which has its root folder set to the folder of the joomla site. If akeeba relies on this method of file system access, this would explain, why it can't access folders outside this location (it reports they wouldn't exist). It does not explain, why they are shown in the folder selection dialog (I mean: it is kinda pointless to provide locations that can't be used anyways...). It also doesn't explain, why the backup files are created by the user under which apache runs, instead of using the FTP-account. This looks a bit inconsistent to me, but is again only a flaw, not a serious issue. After all, the backups will be created, without trouble, inaccessible to the outside world (.htaccess cares for denying access to the files, even if one could guess the file name).
After creating the backup, I downloaded the .jpa file and restored it on my local machine using "akeeba kickstart". I came across some problems that where related to different PHP versions and error reporting settings, but those are explained in akeeba's documentation, which is quite detailed. Thumbs up for it.
The process included creation of a new database and provided the possibility to reset the password for one super user. You can decide if you want to use the FTP-layer, ... All together very similar to the installation process of joomla itself or other web based installers. Nothing to complain about it.
So after the installation and configuration of akeeba raising some questions, restoring the backup was a breeze. Within a minute, I had a perfect clone of my website running on my local machine. Beautiful! Good Work!
Well, I had to adjust some settings like SEO, mod_rewrite and the like, but maybe that's out of scope for a backup solution. At least, I don't expect akeeba for handling such things.
At this point, I was quite impressed. The product was well documented, wizards helped finding correct settings, every step provided good feedback, even the code which I looked at was well structured and documented. And akeeba allowed me to clone my website within no time, allowing me to do simulate the migration without touching my running site.
The problems I came across so far hadn't been severe, so I was quite confident.
The first step of my migration was to remove components, that were installed, but never used. Reducing work during actual migration.
Sadly, many components concentrate on the installation process only, and leave some garbage in your joomla installation after you uninstalled them. So it's quite common, that you need to drop DB tables yourself or end up manually removing some folders here and there. One component I uninstalled tried to delete the files it installed (at least!), but had a bug in its uninstall routine. It tried to change to one of its directories, then to delete all the files in there. To make a long story short: The chdir failed, the component didn't check the success of the operation and instead of deleting its own files, it deleted all the files in [joomla]/administrator. Goodby backend.
So why do I write this down? Not a problem related to akeeba, is it? Not really, but wouldn't it be nice if it was? ;)
Akeeba provides a feature called "system restore points". It hooks into the joomla installer, and whenever you install anything, it creates a backup first. So if the installation process fails, you can always restore to the point before installation. Great idea, isn't it?
If such "system restore points" would also be provided for uninstall operations, akeeba could even protect you from deinstallaion problems (maybe not from this special one - without a backend, well... hard one). I think such a feature would be important, because in my experience, uninstalling will much more likely cause trouble than installing something.
So why do I only rate the component as "average"?
It's not due to the minor inconveniences when setting it up. It's also not some additional features I feel it could provide. At this point I would still rate it as good, maybe even as excellent.
But when I upgraded one other component, things went totally wrong. Akeeba created the system restore point, which made me feel safe. The component upgrade failed, my gallery was broken. "Not a problem any more" I thought, tried to restore to the point before the upgrade, akeeba provides me with a success message, but my gallery is still broken...
I didn't yet investigate what exactly happened, what data is saved with the restore points and why the backup didn't work. But I'm very happy, that I simulated everything locally and didn't screw up the gallery on my server!
Creating backups and restoring them properly is the single most important use case for a backup solution. Leaving me with a broken system after "successfully" restoring a "system restore point" is probably the worst scenario that could have happened.
I still rate "average", because of the good feedback of the component, because cloning my site worked very well and thus saved me a lot of work, and because akeeba's documentation is reputable enough to advises you to test backups before relying on them. This is maybe the most important advice one can give you: Security doesn't come with the installation of a backup system, but only with verifying that it actually works. That it does not only create backups, but that it can also properly restore them!
Thanks for reading this lengthy review till the final end. ;)
Thank you for the detailed review! Let me explain the rationale behind the points you mentioned and you'll understand what is going on.
The installation overview page is in line with other major components (K2, Tienda, ...). What it's plugin does is documented the Joomla! way, I.e. you can look it up in the Plugins Manager. Moreover, our extremely detailed documentation does mention what everything does.
Regarding the encryption detection, this is a known issue when you first install the component. Unless you click the Save button in the configuration page the AES128 key -specific to your site- is not created and we can not tell if the encryption support is enabled. Any ideas are welcome on our free forum section (Pre-sales) or through our contact information page.
The Post-Configuration page lows you to enable the optional plugins (the ones you mentioned in the beginning) as well as run the automatic configuration wizard if you click the last checkbox. Each checkbox has a lengthy description text, so if you read these instructions everything you said so far is irrelevant - the component will automatically remove all confusion for you. So, I guess, the installation page should only contain one link, to the post-installation wizard. Good to know that, I will fix that in the next release!
When selecting a backup destination directory, there is an icon on the top right. If the directory is writable it's a green check mark, a red X otherwise. I think you missed that. Why do I allow you to select non writable directories? What if you have a directory with wrong permissions and you want to select it, then fix the permissions later? Or what if you have an open_basedir restriction and disabled ini_get on your server? Would you rather have the component disallow you to select a directory or throw a blank page? Hardly so. Moreover, if you select an unwritable directory you get a warning before backup in a very strong and hard to miss way. I don't see that as a problem.
As you said, server settings -like mod_rewrite- are well beyond the scope of backup and restoration. And, as you said, I do provide step-by-step instructions for carrying out these steps for the benefit of the less experienced users.
Automatic removal of extensions is something I really want to have, but it's not entirely possible unless all of a sudden Joomla! enforces database table naming standards. Right now, each component follows its own standard and it's impossible to know what it's tables are. If you have a good idea, contact me! I am very open to suggestions.
System Restore Points are not a perfect solution and that's because of how Joomla! works. Let's say that a component's version 1.0 used a file named admin.foobar.php and version 2.0 uses foobar.php instead. Since the SRP restoration does not remove files, after the restoration the latter file will be left behind and it will take precedence due to the way Joomla! works and you still have a broken component. Again, unless Joomla! enforces strict standards for where components are supposed to store user-generated content I can not remove files before restoration of an SRP backup, so you will have to bear with this issue.
Also note that SRPs are a more or less experimental feature. The core functionality of Akeeba Backup is full site backup and restoration. If you erased your site you could easily restore it entirely from a backup - and that's the whole point of having Akeeba Backup! Moreover, SRPs are archive files which can be extracted, so you could also perform a manual restoration should you wish to do so and investigate what went wrong.
Regarding the paid support, I used to have free support. What that lead to was everyone asking me the same questions over and over again, despite having replied at least two hundred times to them and document them since months or years ago. I can either waste my time replying to the same questions, or put a low barrier (7.79€ is not that high) to let me have time to improve the component. I bet you wouldn't want an outdated, buggy component, would you?
I am new to joomla and have a need to move my site to a new server with new paths etc. I installed the free version, read the quickstart guide, did what it said, backup failed, followed the troubleshooting section (my host's PHP file size limitation was the issue) resolved the issue from the documentation, whole site backup succeeded.
Tested the "successful" backups by following the quickstart guide and managed to get a fully working version of my website running on my laptop.
I cannot praise this enough as it is painless and will be a lot quicker when I come to migrate it to it's new server and will certainly have faith when I use Akeeba as the regular backup application.
Fantastic and a must for all joomla sites that I create.
This is my first review on here :o)
From your description it is not clear if you did have a problem with Akeeba Backup or Joomla!.
If you restored the backup on the *same site* as you backed up from and Akeeba Backup lost your memcached settings that is a bug and I could help you (and fixed the bug, and give you a free subscription as per our Bug Bounty policy which is posted on the top of our publicly readable support forum) should you have contacted me. But you didn't and I can neither reproduce this issue nor solve it, or even figure out if it *is* an issue.
If, however, you are restoring to a different site, the problem is not with Akeeba Backup. Akeeba Backup is only responsible for backing up and restoring your site's files and database contents. In the process it reconfigures Joomla!'s db connection information, FTP information, site information and Super Administrator logins but that's all. We can not possibly replicate Joomla!'s entire configuration page. If you have such a Joomla! configuration issue it's your responsibility to reconfigure your site.
BTW, I don't think that anyone would find it logical that a Joomla! newbie should ever use memached. This is advanced stuff, which is only required for heavy traffic websites. I suppose that no Joomla! newbie would ever have to manage such a site, but I digress.
Akeeba is the most rock solid component in ANY category on JED. It is the ONLY component that I install literally on EVERY site that I build. I install it before the first article or module. The support is absolutely second to none, though I only needed it once (and it was not even a technical issue, but rather a billing question). This component is absolutely dead simple to use. In fact the user manual (which every complainer here needs to read) is actually the most complicated part of the program (not that it is complex, but the component is really brainless - My 6 year old can use it). If I could only have one Joomla extension, this would be the one (though Akeeba Admin Tools are almost as useful).
Anyhow, to the point...For the lazy people on here that don't feel compelled to read the manual, here are the restore instructions in 2-3 easy steps (the 3rd is not always needed):
#1 - Upload the .jpa or .zip backup file, kickstart.php, and en-GB.kickstart.ini (if your language is English)
#2 - go to the URL that you are restoring and click through the "Next" prompts
#3 - If you are restoring to a different server than the one the backup was made on (i.e., moving your site to a different server), then create a blank database and enter that info when plainly prompted to do so during the restoration
That is literally all you have to do.
Here are a couple of tips:
1 - You can use the same kickstart.php and en-GB.kickstart.ini file every time so. for convenience, I just keep those files extracted and on my computer ready to upload
2 - If you don't know your admin password, you can change it during restore
3 - You can use Remote Control to automate the backup process from your PC or Mac (thanks for adding Mac Nicholas)
Ok, so here are my two requests:
1) Anyone getting free software should get a life and stop criticizing anything at all when it does not work for them (I have successfully used this several dozen times). If it does not work for you, believe me it is something YOU are doing wrong
2) Anyone that counts on this software to save their butt or for any other reason other than testing should buy the paid version. It adds very useful features and supports future development. Even if you don't need the extra features, you should support this developer. Everything I have used that he has made is AWESOME.
Ok, that's my piece. Again, I want to mention I have absolutely no association to the developer in any manner other than as a paying customer - nothing I said reflects his opinion.
I am using now the Admin Tools Pro from Akeeba as well. It is an other core part of a Joomla pro tool-kit - especially if you are security conscious. When I subscribed, I even got a discount for having two subscriptions.
Cudos to Akeeba and Nicho!