Failure to restore

[Timothy FrankParticipant]

Oh Carolyn – another note. I own all my own servers, and run straight Ubuntu and CentOs server cores so I doubt it is a hosting issue.

[Maria MalukasParticipant]

Following as I’m having the same issue!

[MarkParticipant]

Hi I am back. Does not look like much happened while I was away. Also Updraftplus has not been upgraded so I guess we still have the problem? If that is the case, I can spend some time now to help the support team identify what the problem is now I have returned. Can someone confirm whether any further progress was made under a different ticket or not please?

[MarkParticipant]

I have a second site exhibiting these symptoms now. But equally I have other sites which are not showing the symptoms, so it is a strange case. I have just checked the hosting log and found the following:

Error log when trying to migrate a site to a new location. This is from the hosting.

http://www.wingrove-media.co.uk [Mon Aug 12 12:07:03 2019] [error] [client 146.198.120.150:0] File does not exist: /home/sites/2b/7/73e43ca471/public_html/wp-login.php
http://www.wingrove-media.co.uk [Mon Aug 12 12:07:08 2019] [error] [client 146.198.120.150:0] File does not exist: /home/sites/2b/7/73e43ca471/public_html/wp-login.php
http://www.wingrove-media.co.uk [Mon Aug 12 13:13:25 2019] [error] [client 146.200.45.84:0] PHP Fatal error (Error) has occurred. Error Message: Cannot access empty property (Code: 0, line 1647 in /home/sites/2b/7/73e43ca471/public_html/test/wp-content/plugins/updraftplus/addons/migrator.php)

It is worth pointing out that the destination site was in a subfolder off of public_html called test. Therefore there would have not been any wp-login.php in public_html, it would have been located in : /home/sites/2b/7/73e43ca471/public_html/test/wp-login.php.

The destination wordpress site was functioning ok at public_html/test/ so no idea why this script would have been looking somewhere else. One assumes if you were placing your website in the root of the hosting then this script would run ok, because it would find wp-login.php there. So for those of us with this problem is it related to a relative addressing parameter being hard coded assuming the website is always installed in the root of a hosting directory?

[CarolynParticipant]

I also install my WordPress sites in a subdirectory. Many of my clients have multiple sites and it’s just cleaner to have all of the WP installations (if I’m not using Multisite) in their own folder–including the main domain.

Perhaps we’ve found something in common? I haven’t had a chance to test this out as I just saw your post.

[MarkParticipant]

I have gone a bit further, but still inconclusive so far. Yes I am starting with a site based in the root folder. Copying it to another location in the same hosting in a subdirectory in another account. That much works. I edit the site without hacking it, so using the WP interface. Then move it back. So two observations from two different websites: One it was trying to restore something to a wordpress installation that did not exist. It was not trying to install it in the sub-directory. Then it failed. In the second case I have an error log which shows Updraftplus was trying to access PHP libraries in the hosting. However it was not using the correct path for them. So never found them. That might be an environment variable not being imported correctly. To confound these two cases, I have other sites that I have gone through exactly the same process and they all work ok. No errors, they just restore as one might expect. In the latter cases there is little to distinguish between those that work and the two that do not work.

I also have a working area where I have been doing these tests. I had around 8 databases in one account, only four were attached to real sites. While checking the databases of one of the problem sites, I found some key WordPress tables missing. However the site was functioning ok. (wp_options was one of them). I deleted the unused databases, and the missing tables appeared. If this is true, then this is something to do with my hosting causing this. I re-ran a backup and the database file grew by 40 lines and 120KB even though nothing had been changed in it. But restoring this database also failed. So it may be a red herring.

I have Updraftplus support looking into this now with access to the source and destination websites. I will wait to see what they come back with.

I am also not overwriting any live sites with updated WordPress sites. I am testing them independently in a third location first. It is too much hassle if you kill a live site with this problem. So being very cautious with this plugin until we get to the bottom of the problem.

[CarolynParticipant]

Wow – I’m in a similar boat. I use Updraft for all of my sites and I have over 50. I’m a bit terrified of having to migrate or restore at this point. Thank you so much for sharing all of your legwork. I’m going to try a couple of variables as well to see if I can narrow anything down.

[MarkParticipant]

If you can locate any conflicts in paths during the restore, either where it is trying to restore the website to (or looking for wordpress core files) especially if you are restoring it to a sub-directory, or where it is picking up PHP Libraries from that might be useful feedback to them. I checked the error logs in the accounts I have been using today and came across two sets of errors.

Here is the first:
http://www.wingrove-media.co.uk [Mon Aug 12 12:07:03 2019] [error] [client 146.198.120.150:0] File does not exist: /home/sites/2b/7/…./public_html/wp-login.php
http://www.wingrove-media.co.uk [Mon Aug 12 12:07:08 2019] [error] [client 146.198.120.150:0] File does not exist: /home/sites/2b/7/…./public_html/wp-login.php
http://www.wingrove-media.co.uk [Mon Aug 12 13:13:25 2019] [error] [client 146.200.45.84:0] PHP Fatal error (Error) has occurred. Error Message: Cannot access empty property (Code: 0, line 1647 in /home/sites/2b/7/…../public_html/test/wp-content/plugins/updraftplus/addons/migrator.php)

The last line I have seen more than once. It points to a particular function in the script. It fails in the same place. The script function is called _migrator_recursive_unserialize_replace. The three lines above that will have created an error because the website was not at that location, it was in a sub directory below the root for the hosting.

Secondly, and a different case: The error log looked like this:

[Mon Aug 12 20:40:10 2019] [error] [client 185.151.28.61:0] Failed loading /opt/php55/lib/php/extensions/no-debug-non-zts-20121212/ioncube_loader_lin_5.5.so: /opt/php55/lib/php/extensions/no-debug-non-zts-20121212/ioncube_loader_lin_5.5.so: cannot open shared object file: No such file or directory
wingrove-media.com [Mon Aug 12 20:42:51 2019] [error] [client 146.200.45.84:0] Failed loading /opt/php55/lib/php/extensions/no-debug-non-zts-20121212/ioncube_loader_lin_5.5.so: /opt/php55/lib/php/extensions/no-debug-non-zts-20121212/ioncube_loader_lin_5.5.so: cannot open shared object file: No such file or directory
wingrove-media.com [Mon Aug 12 20:50:09 2019] [error] [client 185.151.28.61:0] Failed loading /opt/php55/lib/php/extensions/no-debug-non-zts-20121212/ioncube_loader_lin_5.5.so: /opt/php55/lib/php/extensions/no-debug-non-zts-20121212/ioncube_loader_lin_5.5.so: cannot open shared object file: No such file or directory

Here I think there are two problems. The site was not located at Wingrove-Media.com it was located at Wingrove-Media.com/test2/ and secondly the path to PHP library is incorrect. There is no library at this location. I lost the rest of the log, but I have seen it terminate with the same critical error as the last one stopping on (Code: 0, line 1647 in /home/sites/…../public_html/test2/wp-content/plugins/updraftplus/addons/migrator.php) So the same point in the script as the earlier example but how we got there was different.

Interestingly looking at the debug history for the last two releases they have been working on paths, and environment variables. So there may be some connection.

In both of these cases I am taking a site in a subdirectory of the root of a hosting account and restoring to another sub-directory of the root in a different account in the same hosting. So none of these were restored to the root. That too may be a factor.

[Timothy FrankParticipant]

Wow – you all have a much greater level of patience than I do…

For me Mark, it looked as though the script was dying in the final stages. I was using clean sites and installs. My log files say the search and replace completes but when I open the MySQL databases – they are not updated. = They are the old databases

[MarkParticipant]

In the last one I did, it had partially populated the database and renamed the links. But the site was broken, it was not possible to sign in, or recover my password, the table for my email address was not in the database. So maybe we are seeing slightly different things. I will keep this space updated with whatever the support folks come back with.

[MarkParticipant]

Just a quick update here:

Updraftplus support have been working in my hosting. I asked them to move a site from location A to location B. I know that it fails, because I tried it on a problem site. They have come back to me this morning claiming success. However they did it using some other method. Just to check to see if the problem was resolved, I took another backup of the newly restored and fixed site (anticipating that the problem was something in the database and had been fixed). I moved it from location B to location C using Updraftplus to generate the backup set and restoring it. Same problem PHP fatal error.

So we are no further forward at this point. This is after another 2 days.

My problem, and I anticipate your problem, is if we are all relying on updraftplus to reliably be able to recreate a site from an updraftplus backup set, that is not the case. It has been 100% fine until a week or so ago when I first came across this problem. In my case it concerns me greatly because I am dependent on this plugin as a backup and restore solution for 130 sites. I think that from what I have found out so far, if a live site failed, or was substantially hacked, and I had to pick up one of my backups to get it back online, and found the backup did not work, I would have to rebuild the site from scratch. There seem to be some records missing from wp-options not being bought over, but cannot be absolutely sure.

Updraftplus Support did not state what they did to recover the site. Of course in their case, the source site was functioning and available. That would not be the case in the event of a major failure.

I have provided this feedback to Harshad (Updraftplus Support, and waiting for a response). I will update this thread if anything else happens.

Mark.

[MarkParticipant]

One further piece of information. The source (working site) has 105 tables in MySQL
The destination site after Updraftplus crashes has only restored 40 of them.
I have manually imported a good MySQL database into a broken site and managed to get it working. However using the tools in Updraftplus to rename the URL for the website generates the following error which I have seen before. The crash occurs in migrator.php one of the Updraftplus files. (I have hidden the full path replacing one of the directories with /…/)

Error Details
=============
An error of type E_ERROR was caused in line 1647 of the file /home/sites/1b/8/…/public_html/updraftplus/wp-content/plugins/updraftplus/addons/migrator.php. Error message: Uncaught Error: Cannot access empty property in /home/sites/1b/8/…/public_html/updraftplus/wp-content/plugins/updraftplus/addons/migrator.php:1647
Stack trace:
#0 /home/sites/1b/8/…/public_html/updraftplus/wp-content/plugins/updraftplus/addons/migrator.php(1647): UpdraftPlus_Addons_Migrator->_migrator_recursive_unserialize_replace(‘https://wingrove…’, ‘https://wingrove…’, Object(stdClass), false)
#1 /home/sites/1b/8/…/public_html/updraftplus/wp-content/plugins/updraftplus/addons/migrator.php(1631): UpdraftPlus_Addons_Migrator->_migrator_recursive_unserialize_replace(‘https://wingrove…’, ‘https://wingrove…’, Object(stdClass), false)
#2 /home/sites/1b/8/…/public_html/updraftplus/wp-content/plugins/updraftplus/addons/migrator.php(1618): UpdraftPlus_Addons_Migrator->_migrator_recursive_unserialize_replace(‘https://wingrove…’, ‘https://wingrove…’, Array, true)
#3 /home/sites/1b/8/…/public_html/updraftplus/wp-content/plugins/updraftplus/addons/migrator.php(1533): U

[MarkParticipant]

I noticed that there are a few more of these instances of migration failure, or failure to restore. My status right now is the support engineer has referred my case to the developers. It is a bug caused by something in the WP-Options table, there is an unexpected null value. It is acknowledged as a bug by Updraftplus, and should be fixed in the next release. I also found the previous release of Updraftplus on another website. That version works. So this is a bug introduced in the last release. I also established with support that the problem only occurs in a restore and the database backup is good. If you are absolutely stuck you can manually extract it and install it using myPHPadmin through the control panel of the hosting.

Mark

[MarkParticipant]

I am quite surprised that this bug has not been resolved. I am still hitting this problem, which makes my annual subscription to Updraftplus a waste of money. If I have to switch to a more reliable backup solution, I may not come back, and that is how you lose customers.

What is the status of your resolution to this problem. I thought we had established several things here:
1). It is not just me, while this critical problem is not affecting everyone, there are several reports on a similar theme
2). It was first reported nearly a month ago
3). It completely trashes the target site. (Several people had restored sites on top of live sites and killed the site completely, and could not go back. THat is a critical problem).
4). UpdraftSupport had also witnessed it and passed it to development and had some idea what the problem was.

Please advise when we can get a fix. Or even a work around. This is a major problem for me because I have 130 sites depending on Updraftplus as a backup programme, and right now I cannot be confident that in the event of a complete failure I will be able to quickly restore a site from a backup. I used to be 100% confident about that, but not anymore.

[CarolynParticipant]

I agree with Mark. I’m very concerned. I count on Updraft—particularly for migration. I have over 70 sites and I’m concerned a live site will go down if I have to restore.

Please tell us what is happening.

[Author]

Posts