Support

Akeeba Backup 3.4.x is designed to run only on Joomla! 1.5 and 2.5. It's not tested on Joomla! 1.7 and I don't know if it will work or not. Also note that since April 1st we have dropped support for Joomla! 1.6 and 1.7. Right now, these Joomla! versions have known very high priority security vulnerabilities and they are not supported by the Joomla! project (they are end of life). We can not support insecure, outdated, end-of-life releases of Joomla!. If you want, you can install version 3.3.13 on your site, but please note that both this version of Akeeba Backup and this version of Joomla! are not supported.

That said, I can reply regarding the System Restore Points (SRP) feature's design goal and its pros and cons. SRPs are supposed to be small backups of just an extension (module, plugin, component or template), taken automatically whenever you update that extension. The major problem is that there is no official convention on the naming of the database tables used by each extension, or where it stores all of its files. As a result, it is impossible to create an 100% accurate SRP solution. Our SRP feature will try its best to take a backup, in hope that if the extension update fails you can restore this "mini backup". It may or may not work. It is advisable to always have a full site backup and rely on it.

In other words, restoring an SRP backup should be your first attempt to resolving a broken extension. If that doesn't work, you should restore a full site backup. Restoring an SRP can be done through the Akeeba Backup, Administer Backup Files, Restore Points page. The procedure is documented and it consists of pretty much clicking on the Restore button in the right-hand column of the SRP backup.

Please always keep in mind that SRP backups should not be relied upon as your one and only backup policy. They are not designed to fulfil such a role. At all times, I strongly recommend having regular, off-site stored, tested full site backups. SRPs are like airbags: they can provide additional protection, but you should not use them without a seatbelt expecting them to save you from a crash (in this analogy, full site backups being the seatbelt).

Hi,

Hm, the text on that page actually referred to an older version. With the rate new versions of Joomla! are released it's impossible to update all of our text throughout our site, documentation, component, Joomla! Extensions Directory and so on :( The version support policy is clearly stated in the release announcements, though.

Further to that, you have an insecure Joomla! version. If you give me the URL to your site I can hack it in 5 minutes: I can create a new Super Administrator account, log in to your site, disable your account and then ask you for "ransom". Unfortunately, I'm not the only person capable of doing that. The instructions to hack Joomla! 1.6 and 1.7 sites are now out in the wild and I personally know of a non-developer (he's just a site integrator) who was able to carry out those instructions in 3 minutes and effectively hack one of his own sites. Why do you want to stick with a Joomla! version which makes it certain that you will be hacked?

In any case, if you do get stuck somewhere I will try to help you. But if it comes down to a known bug, I won't attempt to fix it. In all fairness, 3.3.13 is a rock solid release. The only thing in it which is broken is Dropbox integration (because in the meantime Dropbox changed some aspects of their service, a change integrated in 3.4.1). Apart from that, any issues you may experience will most likely have to do with configuration, not a bug. The reason I dropped J! 1.6/1.7 support is that these versions are now insecure and not supported by the J! project. You know what usually happens when a developer provides support for a vulnerable version of Joomla!? When the client gets hacked, the developer somehow takes the blame, even though his software had nothing to do with the hack. That's why I don't want to provide support for those outdated J! releases.