Manual DB restore failing – Migrator is the only way?

[MelindaParticipant]

Hi there,

In your instructions I saw that there was meant to be the option to do a manual restore of the DB – meaning that I should be able to grab the sql file from the .gz backup and simply use your host’s usual DB interface (like PHPmyAdmin) to do restores of the DB.

What I have run into while attempting to verify that Updraft does work for my particular sites is that I cannot actually use that file unless I use it with Migrator / the WordPress Admin interface – which works just fine.

So for example:
– I can dump the DB manually and restore it to a new DB manually just fine.
– when I take the backup of the db made by updraft and attempt to restore it to a new DB it fails out (with a variety of errors depending on which site’s DB I’m attempting to restore, I should add).

In running it for an example error right now I get failure logs that start with:

[Err] 1366 – Incorrect string value: ‘\xF0\x9F\x98\x9B” …’ for column ‘option_value’ at row 212
[Err] # Data contents of table wp_options
INSERT INTO wp_options VALUES (1, ‘siteurl’, ……….

Basically it can never get beyond the wp_options table.

Any thoughts? It’s probably something very simple that I’m failing to do to prep your product’s DB dump for manual re-import.

Thanks!

[udadminKeymaster]

Hi,

That indicates that your phpMyAdmin install isn’t set up to deal with some characters in the database. The UD backup is just a standard SQL file – it can be processed by any SQL-compatible tool; and all that UD is doing when it restores is sending the SQL commands in it one-by-one to the SQL server. But, the error above indicates that phpMyAdmin is falling over some non-ASCII characters. I can’t hazard a guess at what in its setup isn’t right, unfortunately – but, if UD on the same server is working, then presumably MySQL and Apache are both OK, so the problem must be in phpMyAdmin somewhere. (Perhaps check if it’s a recent version?)

David

[Author]

Posts