The Joomla! Extensions Directory ™


bybwoester, September 5, 2011
Akeeba Backup
I'm currently in the process of migrating a website from J1.5 to J1.7. Since this website is hosted on a virtual server, which allows me to take and reload snapshots very easily, I didn't feel like I needed a product bound backup system. Instead, if anything went wrong, I could always restore the whole machine within seconds.

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. ;)
Owner's reply

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?