Akeeba Backup



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.
Joomla! 2.5/3.0 only. We have older versions for Joomla! 1.5/1.6/1.7 on our site.
Features:
- 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 desktop software (Akeeba SiteDiff 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 (starting at EUR 7.79) to request support. However, its documentation, the troubleshooting wizard and searching the forum is free.
*** IF YOU CAN'T FIND HOW TO ENABLE A FEATURE LISTED HERE, PLEASE READ THE (FREE) DOCUMENTATION! ***
I cannot recommend this extension highly enough.
Thanks for a truly worthwhile extension
You can configure whether .zip or .jpa (own archive system).
I would have needed it before my website crash though ^^
Thanks for this extension.
Seven stars for this.
It's not only for backing up a website from online server to local computer server, but it's work also the other way around. I used to work and complete a website on my local computer first, before transferring it manually to online server trough ftp, it's took times and sometimes error happen resulted in fail. but when I got this extension no more problem :) is so easy, fast and no more error.
Thanks to Akkeba Team for this free extension...
This has to be welcome news for all of us that are all too familiar with the Joomla upgrade "dance".
Congratulations to the Akeeba team .. they deserve Joomla Oscars!
The installation was simple, the set-up is easy as well given all the explanation, tool tip an guides. Sure there are many settings as you would expect from a professional extensions. But not too many that you are discouraged looking at the config page.
The restoration process is a breeze! so simple.
It's definitely worth getting the pro version. I used to always go for free extensions. But what you get for such small price is no doubt valuable. And when you think about it, just factor the cost in your next project(s), and basically, your extension will be paid for by clients, and will benefits you for all sites.
And since time is money, you will save a lot of money with this extension. A very good ROI is you ask me.
Let alone providing additional service to your client by providing them with peace of mind knowing that their entire site is backed up frequently and ready to be restored very quickly.
Great work Akeeba team !
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!!!
Joseph
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?







