Support

Hello Jenina,

The restore points feature is very hit-and-miss. It was created back in the Joomla! 1.5 days when a few assumptions were mostly true:

• All extensions store their data in their own tables. These days extensions implementing ACLs, categories, tags or content versioning also store data in Joomla! core tables, in a way which doesn't allow us to separate this data from core data – or from third party data.
• Table names have predictable prefixes or can be provided by the extension developers. The developers who didn't follow the "prefix is the same as the extension name" norm never bothered to supply this information and Joomla!, despite initial thoughts to the contrary as can be seen in the sample XML manifest files, never forced developers to explicitly declare the naming pattern of their extension's tables.
• One installation package = one extension = one XML file. Now we have the "package" type extension with multiple extensions inside it and the file, library and language extension types without an actual extension included.
• The installation path is predictable. This was and is still true for (most) templates, components, plugins and modules. It is not true for all of the other extension types.
• All extensions are installed through the Joomla! extensions installer, using a web browser. Nowadays we have the extensions updater and, most importantly, third party services and CLI scripts doing this. There is no way to offer a unified way of taking restore point backups.
• If you replace the files of an extension with those from a previous version the extension will still work. With the advent of autoloaders and RAD frameworks this is simply no longer true.

There is no solution to most of these issues. For those which can be solved, the solution is not consistent. We cannot guarantee that SRPs will work reliably. In fact, we can only guarantee that they will most likely fail. This is despite the amount of time and effort I've put into it. Some things can simply not be done. I think the SRP feature was ahead of its time. Perhaps Joomla! 4 –whenever it's released– will include a similar feature. The last time the Joomla! project discussed the extensions updater we all agreed we need separate staging and deployment steps when installing an update. The staging step could easily be converted to a backup step using a plugin. It remains to be seen if the project will agree to implement this new updater method. Until then, SRPs are pretty much dead in the water...

It comes down to this: when a feature misbehaves and cannot be fixed to conform to our very high standards we have no other option than to remove it. Remember the Akeeba Backup Lazy Scheduling plugin? It's the same story.

As I wrote above, there isn't a reliable way to understand when an extension is installed:

Nowadays we have the extensions updater and, most importantly, third party services and CLI scripts doing this. There is no way to offer a unified way of taking restore point backups.

The best thing you can do is to manually take a backup when you know you are going to install or update any extension.

Well, when SRPs when reliable back in the Joomla! 1.5 days it was a killer feature. Now? Not so much. How many of the SRPs you've taken have you restored? And, most importantly, did it really work? I doubt that you can respond positively to the latter. Some of the most popular extensions (according to JED) we've tried failed to restore properly when using System Restore Points. It's not a reliable feature. For us, this is unacceptable. We want our software to work every time and protect our clients, not play Russian roulette with their data.

As for what you should be doing: take daily (or more frequent) backups. Before updating a bunch of extensions always take a backup. If you are extra paranoid take a backup, restore on a different development site/subdomain, test the extension updates on this clone and when you're satisfied that everything works also install them on the main site.

I have more things to do with my life than make backups - that's why the (apparently false) comfort of restore points was so reassuring.

That's exactly my first major concern. It was a false comfort. However, I agree with you that you do have more important things in life than backing up your site. That's why you can automate the backups. I'd be the last person on the planet to tell you that you need to log in to your sites day in and day out to take backups.

The point is I was under the impression some of the pressure was off with Akeeba Pro - when it isn't/wasn't so I could restore more easily even if I did have another backup. Luckily I've never had to actually do a restore - because I reallly am so careful anyway....

This was the other major concern. What I observed was that when an update goes awry you are very likely to NOT be able to log in at all to your site. What's the point of having a partial backup which may or may not restore if you can't even restore it? Not to mention that it may or may not solve the problem...

Hope somebody somewhere works something out. This is a much needed function in Joomla.

Yes, thank you, that's what I've been saying for the past four years :) A few months ago I wrote a specification on how updates should work. Without going into tiresome details, my concept was based on the idea of having separate upload - extraction - staging - deployment steps. If the deployment fails the installation can roll back. It won't break the site because the extension is disabled before it's deployed and re-enabled afterwards (WordPress is doing that too). If Joomla! has a staging step we can write a new SRP plugin which hooks at the post-staging point and puts the live data into an installable ZIP archive, let's call it the "fall-back ZIP". If the deployment succeeds but the new version breaks the site it will be possible to disable the affected extension and install the fall-back ZIP. Since the fall-back ZIP is an installable package which undergoes the same staging-deployment process the prior state of the site will be preserved.

This is a MAJOR task. It will definitely not be undertaken before Joomla! 4.0 since it breaks backwards compatibility (extensions will have to provide much more information about their installation than they currently do). Will it be implemented? I have no idea. It's not up to me to decide.

BTW, if you have root access on WHM, you can set automatic backup points and restore from there. That's my other fall back. But you stand to lose a couple of day's data when you do that, so you still need some kind of as-close-to-realtime backup as possible.

It's even worse. You will also lose days worth of emails as well and the rabbit hole goes further down. The upside with up-to-date Akeeba Backup archives is that if you are really willing to do some more work to prevent data loss, you can. It has happened to us, it took me about 30' to restore the latest backup on a test server and exclude the database tables with the data I wanted to preserve, but there was no data loss whatsoever on our site. That was extremely important, considering how many subscriptions we have per day and the huge impact losing one or more subscriptions would have.