Support

Akeeba Backup for WordPress

#29051 Automatic backups for WP

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

WordPress version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by westiefan on Friday, 26 January 2018 09:41 CST

westiefan
Hi Guys,

In Akeeba Backup for Joomla when carrying out an update to the Joomla CMS core, Akeeba automatically takes a backup before the Joomla update starts.

Are there any plans to update the Akeeba Backup for WP to do the same as it is a real pain to have to manually take a backup before any WP updates, particularly as WP has an auto update feature not found in Joomla, so when W updates it does so and then notifies us after the event, so it is then too late to take any backups before updating.

Essentially my questions are:

1. Is the auto backup functionality included in the plugin, and if so how do I enable it?
2. If not already included, are there plans to include it soon?

There are other backup plugins available that do an auto backup in WP, but as all my sites currently use Akeeba I would prefer to use it for all sites, but the auto backup is really important for us, so please advise us of your plans towards this functionality.

Regards

John R.

nicholas
Akeeba Staff
Manager
Hello John,

The executive summary is that we're working on something like this with a caveat: it will only work if you do not use automatic updates.

Let's simplify a bit what's going in behind the scenes. When WP detects there's an update available it downloads the update file, puts the site to maintenance mode, extracts it on top of the current site, runs maintenance / upgrade code and then sets the site back to live mode. While the site is in maintenance mode you cannot run plugins. This means Akeeba Backup cannot run at this point. We could only do something before it downloads the update file.

The problem is that this hook only allows you to do something fast which can complete inside a single page load. Taking a backup takes a substantial amount of time and requires mulitple page loads. So the time limitation alone is not looking good for taking backups.

Further to that, WordPress may trigger the automatic update at any random point in time, even in the public frontend of your site when a visitor (or a search engine!) is browsing the site. This makes it quite risky running a backup. We had tried that approach with Joomla! with our Lazy Scheduling Plugin back in 2011 but within two years we had identified fourteen (14) failure modes which were not under our control and could not be worked around. Repeating past mistakes does not a wise man make.

I know that other plugins claim to take backups on WP update. However, what they don't tell you, is that they just take a mysqldump of your database and a tar of your site IF you are on a Linux server, IF these commands are available, IF you have enough disk space, IF you have plenty of CPU time and RAM, IF you can run PHP scripts for an unlimited amount of time without timing out, WITHOUT applying exceptions to what gets backed up. It works for small sites on at least passable hosting. But, you know, these are the kind of sites which only get modified once every few weeks or months so it'd make more sense to manually back them up after each content update instead of whenever WordPress updates itself.

The only way we could make this feature work -and which we are currently looking into- is only if you disable automatic updates. Then we can do exactly what we do with Joomla!. You, the Administrator, initiate a WordPress update. We hook to an event e.g. the download update package and redirect to Akeeba Backup. A backup is taken. Then we redirect back to the WP updater code, after setting a temporary variable which says "backup already taken for WordPress version X.Y.Z, let WP continue the update". Therefore we don't redirect again and WP finishes its update.

If you want to use automatic updates you are relinquishing control of the update timing. In this case your only defense against a broken site is frequent, automated, off-site backups. Luckily, Akeeba Backup Professional is explicitly designed to do exactly that. Make sure you are taking daily backups with the CLI script and you ought to be safe.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

westiefan
Hi Nicholas,

I take on board your comments, and it makes perfect sense. By default we have already disabled automatic WP updates (with a plugin specifically for this purpose) for any of our clients having a support contract with us, as this is the only way that we can guarantee taking a backup first, so in these cases what you are proposing would be perfect for us.

For our unsupported client sites, they are set to use the auto update features (otherwise the clients would never update their sites at all!!). For these clients I take your point regarding the limitations of the potential backups, but from the clients perspective that would be better than nothing at all, so we will need to take a view for those clients.

Do you have a timescale for implimenting the auto backup function (for our supported sites where auto WP updates disabled)?

Thank you

John R.

nicholas
Akeeba Staff
Manager
My best guess would be Q2 2018.

To cut a long story short, Davide is currently occupied with converting our Joomla! extensions to the new CSS framework which is a prerequisite for supporting Joomla 4 - where the majority of our income comes from. I have a 2-week-old girl at home. I do manage to squeeze 6-8 hours of very productive work every day - instead of 10-12. So, even though I could probably promise you March 2018 and be most likely truthful, I'd rather say May 2018 and be much safer. Fair enough? :)

As for your sites with automatic updates, I do recommend frequent automated backups anyway. If your clients do daily updates then do run twice daily backups. If your clients are only likely to visit their site once every month do twice monthly backups. Keep the last 6 or more backups if possible. I keep at least the 30 latest backups and one backup from each past month. This way if poo hits the proverbial fan you can restore their site, fast.

Also, WordPress is a bit better than Joomla when it comes to overwriting newer versions with older ones, mostly because it's written like it's 2001 with direct includes and hard dependencies. If it comes to this, you can always install an older version on top of the new one and then take a backup of the site to fix it up locally, then backup the local site and restore on top of the live to perform the (working!) update.

Don't think about the One Way to do something. Think about the outcome you want to achieve and then work out which process and which tools to use.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

westiefan
Hi Nicholas,

No problem ref timing, the sooner the better for me, but better to be stable before release.

Ref the other issue with backups, we need to look into how we deal with this for unsupported clients, as your suggestion encroaches on areas that we only deal with for supported clients, so that is something we need to look at from a business perspective.

Thank you as always for your insights, they are much appreciated (good luck with your daughter, as this is precious time to spend with them!!).

regards

John R.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!