Failure to restore

[MarkParticipant]

I use Updraftplus on a daily basis for over 3 years and have no significant issues with it. Right now I have a site which was moved from A to B. In location B changes were made to the branding of the website through the application of colours and graphics. All of it handled conventionally through the normal WordPress editor interfaces. No manipulations of the database have been attempted. Unlike the 100’s of times I have done this before, when I try to move the site back to A from B (and noting location B seems to be working without any issues) an error occurs in the restoration of the database. I have a screen shot, and I have unzipped the database and located the line where the problem has occurred. When this happens the website simply crashes, so it is not possible to access the link for diagnosis. All I have is a screen shot. It says:
… Search and Replacing table: wp-options:rows 436
A PHP fatal error (Error) has occurred: Cannot access empty property.

When I examine line 436 in the database file it has the following data: (39502, ‘_transient_timeout_plugin_slugs’, ‘1564778001’, ‘no’),

I am running the latest version of Updraftplus and the latest versions of all plugins and wordpress. Is there any value in going back a version. This problem is only occurring in this website. I have similar sites that have gone through the same process that have no issues.

[MarkParticipant]

PHP version btw is 7.0.3

[CarolynParticipant]

I’ve been having the exact same issue all day. I was trying to launch a site by migrating from my development server to the client’s server–of course, now their site is down.

Search and replacing table: wp_options: rows: 485
A PHP fatal error (Error) has occurred: Cannot access empty property

On top of that, this server was running PHP 5.4. I managed to upgrade and try again and same problem happened.

The site has been down all day and I need to sort this out tonight. Hoping someone has a solution.

[MarkParticipant]

I have the hosting company assisting me right now. The solution has been to move all of the files over, which you can still do with Updraftplus, I found out that part worked. The bug or whatever is causing this problem is strictly limited to the database file. It is only when you try to recover that does everything break.
If you know how to do it, you can export your database from the source site, to the destination site using the tools available to you in the hosting. When you import it into the target site, you need to search and replace the database to amend the URL strings to the new location (domain name).

Other things I did (but did not help) was run a plugin to scrub the database before moving it, change PHP value, delete unused tables, none of it made any difference. If you are stuck as I was, then suggest you seek the help of the hosting companies concerned if Updraftplus cannot respond in time.

I have implicitly trusted this app, and used it probably a 1000 times or more over the past 3-4 yrs. The process of moving takes a few minutes and has always worked. I need to understand how to move a site manually so I do not waste hours if this happens again.

Would be nice to see a response from the Updraft Support team here.

[Bryle CroduaModerator]

Hi,

Please could you check for any further entries in the PHP error log from around the time of the restore?

Best Wishes,
Bryle

[MarkParticipant]

Once this error occurs WordPress crashes, wordpress is no longer responsive. So the link does not work. I think your link relies on the WordPress core functioning. I think what is happening is the database is being overwritten when it occurs. I have tried to recover a crashed site, however even my login has disappeared from the database. So perhaps you are deleting it before re-populating it. So the answer is no I am afraid. I now have a support raised on this btw.

I also moved another site yesterday using the same latest release of Updraftplus and did not see this issue. So it is not always a critical bug. But with this site, irrespective of what I do to it, the database file cannot be retrieved and the script crashes halfway through the restore, which then requires a new installation of WordPress, upload and installation of Updraftplus before you can try again. All very time consuming. I spent 5hrs doing this last night trying to identify the problem, rather than the usual 10 minutes.

I have had to use an independent method of getting this site back online. Once back online, I backed it up again using Updraftplus and tried to restore it somewhere else. That failed too, same error. Because I have seen this, I now have a huge question mark over my use of Updraftplus as a reliable backup program. I am using it on 130 sites. I cannot be sure now this has happened that it is not going to occur somewhere else.

[CarolynParticipant]

Same thing is happening for me. I did as Mark did with the files. I could restore the plugins, themes, uploads separately, but restoring the database breaks everything to the point that no users are found so you can’t even log back into WordPress and try again. I ended up reinstalling WordPress. I tried search and replace the database and had unrelated issues so I used the WordPress import to import the posts and then I still had to reset settings in the theme, plugins, etc.

This is all of the error log that was posted. After that, the whole thing crashes.

Unpacking backup… (backup_2019-08-01-1812_Tactical_Fire_Vehicles_30e68b4f817c-db.gz, 1.3 Mb)
Restoring the database (on a large site this can take a long time – if it times out (which can happen if your web hosting company has configured your hosting to limit resources) then you should use a different method, such as phpMyAdmin)…
Enabling Maintenance mode…
Backup of: https://*****
Content URL: https://*****/wp-content
Uploads URL: https://*****/wp-content/uploads
Old table prefix: wp_knjo_
Site information: multisite = 0
New table prefix: wp_
Processing table (MyISAM): wp_knjo_options – will restore as: wp_options
Table prefix has changed: changing option table field(s) accordingly: OK
Elegant themes theme builder plugin data detected: resetting temporary folder
Search and replacing table: wp_options: rows: 485
A PHP fatal error (Error) has occurred: Cannot access empty property

[MarkParticipant]

FYI Carolyn and Updraft Tech support staff. There is a common line in both of our error reports prior to the crash.
“Elegant themes theme builder plugin data detected: resetting temporary folder” so we are both using Elegant Themes templates.

Having said that, yesterday I did move another Elegant Themes site using the same release of Updraftplus and it all worked ok. So it may be a false indication.

[CarolynParticipant]

To Mark and Support — Please note that Timothy just posted what appears to be the same issue.

Migration Failure

[Timothy FrankParticipant]

Hi Carolyn – I am using the Brooklyn Theme.

[CarolynParticipant]

That’s actually good news for me since I’ve used Divi on quite a few of my sites, but – of course we’re no closer to finding the cause and haven’t heard back from support. I ended up having to migrate my site by hand–which is no fun at all. Hopefully support will chime in soon. I’m surprised they didn’t post anything since yesterday.

[MarkParticipant]

FYI: I have a support thread open on this case now. I have installed a clean version of WordPress, added and authorised Updraftplus and uploaded the set of files ready for a restore and given the support team access to it and the hosting control panel. So hopefully they may be able to identify what is going on here.

[MarkParticipant]

I have had to terminate the support case because I am going to be away for a few days. Tech Support have seen the problem now. Speculation: It looks like there may be some tables missing when the database file is created. That may be what is throwing the error. I would expect a database file to be fairly efficient. I exported the file from PHPMyAdmin and it was 8.5MB as an exported mySQL file. Updraftplus created a zipped up version 3.2MB. If the creation of the database file is dropping some tables, that is really bad news because you could never restore a site at all. If it was a problem in restoration and the database expansion was ok, just being interpreted incorrectly by the restoration script, that would mean you still have all of the data. Not sure if someone else can pick this up with the Updraft Team. There is a risk right now that under circumstances we do not understand that the database file is incomplete which would render any backup useless.

[Bryle CroduaModerator]

Hi Mark and Carolyn,

Apologies for the delay.

I will ask our developer to look into this. I’m afraid they might not be able to check on this today.
They will be back on Monday.

Also @Carolyn, please disregard the migration log request on the other forum post you opened.

Regards,
Bryle

[Timothy FrankParticipant]

Hi Mark – I noticed on my end, the zipped database that transferred to the receiving site had a different size than when I did just a backup from updraft of the database. Also, when I did a SQL dump and looked inside the tables, the search and replace did not function even though as I did the migration it said it was doing it.
Tim

[Author]

Posts