restoration of database post migration fails — appears to time out

UpdraftPlus Home Forums Paid support forum – UpdraftPlus backup plugin restoration of database post migration fails — appears to time out

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
  • #404921

    the database search-and-replace after restore takes quite some time and seems to fall down around the part when it’s working on wp-posts

    right around there I get the ‘your session has expired, please log in again” popup. (also after logging back in, the page no longer appears to receive updates after a few moments)

    I have tried logging back in right away; I have tried letting that sit and just refreshing the homepage; I have tried setting up crontab to poke wp-cron.php every 10 minutes; I have watched the log files with ~/www/wp-content/updraft {86}>$ ls -t log* -1 |head -n 2 |xargs tail -f; I have tried bumping php’s max_execution_time from 30 to 900;

    Having used wp-migrate-db plugin in the past to do search-and-replace, I am somewhat surprised at how long yours takes — perhaps they are doing things a little differently?

    my latest logfile seems to crap out around here:

    ==> log.e89375c40ec5.txt <==
    0655.236 () Search and replacing table: wp_posts: rows: 20819
    0978.786 () Searching and replacing reached row: 5000 <– this line never appears in the browser window after the session-timeout and log-back-in (which I did immediately as the dialog popup appeared this time)

    I’ve seen it get as high as 15000 but no further, in my attempts to make this migrate work. All other aspects of the migration have functioned fine: I restored theme/plugin/other, and then separately restored uploads (234 zip files, there)

    the gzipped database for this site is 27MB according to the shell
    -rw-r–r– 1 hidden hidden 27M Jun 27 03:30 backup_2019-06-26-1136_Hidden_ed497321a353-db.gz

    what other information can I provide to help debug this or what options do I have to work around this

    Bryle Crodua


    To help us work out the cause of your problem, can you please send us a copy of the migration log?
    You can find this log in the ‘wp-content/updraft’ directory of your new site location.
    You can send the log file as an attachment or copy the contents into an online tool (such as )

    Best Wishes,


    Could really use some assistance with this before the weekend arrives. there’s still work to be done on this site once we’ve put it up at the staging location for testing new features.


    here’s the logfile’s contents as requested

    0000.560 (R) [notice] Looking for db archive: file name: backup_2019-06-26-1136_Town_Square_Delaware_ed497321a353-db.gz
    0000.560 (R) [notice] Archive is expected to be size: 27104.6 KB: OK
    0001.219 (R) [notice] Unpacking backup… (backup_2019-06-26-1136_Town_Square_Delaware_ed497321a353-db.gz, 26.5 Mb)
    0001.269 (R) [notice] 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)…
    0002.049 (R) [notice] Enabling Maintenance mode…
    0002.050 (R) [notice] Backup created by:
    0002.050 (R) [notice] Backup of:
    0002.051 (R) [notice] Content URL:
    0002.051 (R) [notice] Uploads URL:
    0002.051 (R) [notice] Old table prefix: wp_
    0002.051 (R) [notice] Site information: multisite = 0
    0002.052 (R) [notice] New table prefix: wp_
    0003.068 (R) [notice] Processing table (InnoDB): wp_options
    0065.376 (R) [notice] Database queries processed: 50 in 64.11 seconds
    0142.835 (R) [notice] Search and replacing table: wp_options: rows: 1586
    0150.260 (R) [notice] Processing table (InnoDB): wp_users
    0158.606 (R) [notice] Search and replacing table: wp_users: rows: 224
    0158.894 (R) [notice] Processing table (InnoDB): wp_usermeta
    0219.488 (R) [notice] Search and replacing table: wp_usermeta: rows: 6593
    0219.608 (R) [notice] Searching and replacing reached row: 5000
    0219.645 (R) [notice] Processing table (InnoDB): wp_commentmeta
    0236.893 (R) [notice] Database queries processed: 100 in 235.62 seconds
    0251.316 (R) [notice] Search and replacing table: wp_commentmeta: rows: 4980
    0257.977 (R) [notice] Processing table (InnoDB): wp_comments
    0284.164 (R) [notice] Search and replacing table: wp_comments: rows: 2300
    0287.775 (R) [notice] Processing table (InnoDB): wp_links
    0292.141 (R) [notice] Search and replacing table: wp_links: rows: 0
    0292.142 (R) [notice] Processing table (InnoDB): wp_postmeta
    0369.780 (R) [notice] Database queries processed: 150 in 368.51 seconds
    0410.953 (R) [notice] Search and replacing table: wp_postmeta: rows: 310
    0549.739 (R) [notice] Processing table (InnoDB): wp_posts
    0588.048 (R) [notice] Database queries processed: 200 in 586.78 seconds
    0654.427 (R) [notice] Database queries processed: 250 in 653.16 seconds
    0655.236 (R) [notice] Search and replacing table: wp_posts: rows: 20819
    0978.786 (R) [notice] Searching and replacing reached row: 5000


    Well, too late to hope for a response before the weekend; is there any way we could arrange for some more timely back-and-forth where even more days don’t pass in between responses? Our end is a bit time sensitive, and already delayed. It would be greatly appreciated.

    Bryle Crodua


    Apologies for the late reply.

    It appears that the migration process is timed out or killed off. This is usually due to server resources reaching its limits.

    Please ask your hosts/server admin to investigate their PHP error logs. These logs should contain more information on the exact issue that is causing the backup process to halt.

    If you want us to restore/migrate the site for you, you can purchase one of our hands-on support package here –



    There’s nothing in the error logs for php to suggest that. particularly after I upped the max execution time to 900 from 30, but not before either. Nothing in the MySQL logs either.

    What other methods of workaround do I have for this? it’s 10:59am here in the states, so there’s plenty of daylight left for us to work on this : I notice that your timezone is significantly different from ours, inasmuch as the forum timestamps would indicate.


    this one-reply-per-day thing is getting wearisome. is there any way we could arrange to go back-and-forth via email rather than by forum? OR does anyone have alternative suggestions as to how we can get the DB restored so we can move forward with testing on the staging server so the client can show things to THEIR clients ?

    For a paid support forum the turnaround time on replies is shocking.

    posted at 3:43pm EST

    Bryle Crodua


    You can manually restore the database via phpMyAdmin. Then to change the old url with the new url, just follow this guide

    You can also open a ticket using this form –



    Sure I could use PHPmyAdmin — I could also manually restore it with commandline mysql even more easily.

    but this /faqs/migrated-site-searchreplace-database-can-now/ well. now this is some great advice..

    (presuming one had successfully restored the DB without the search-and-replace bit):
    1. change WP_SITEURL in wp-config.php to the old site’s address
    2. log in (you forgot to mention the part where you go to your hosts file and temporarily add the new server’s IP address so it points at the old url)

    (and I love this part):
    3. *perform the database migration again*

    ___You mean the part that’s been failing on us?___ So you’re basically saying, “Use the plugin harder”?

    *deep calming breath*

    We had already gotten this to the point of ‘restore the plugins/themes’, ‘restore the other and uploads’ and LASTLY JUST restore the db, each separately in their own pass run, before we contacted you. The logfail above is from the part where we were JUST restoring the DB with the search-and-replace. That was the _complete_ logfile.

    Why are we paying for the fancy schmancy version of the plugin again, remind us? I’m _certain_ the client is wondering at this point, given how long it’s taking us to get a workable support response.

    How about this: do you have a “sql patch” file or script that we can use to manually apply the search-and-replace to the DB with after manually importing it to the DB via the commandline? Other suggestions? Today?

    posted: 11:24 am EST


    support ticket submitted @ approximately 1:27pm EST


    SO yeah, we got a response from the support ticket, wherein I referenced this forum post to detail what we had tried so far.

    Their response? (which came in at 1:34am our time, and was read and responded to by us 7 hours later at 8:43am our time)

    >> “Restoration process can stall/halt depending upon the total backup size and available server configuration, PHP timeouts can stall/halt the restoration process.

    >> If you are trying to restore all backup sets at once, instead I’ll suggest you to restore each backup set one by one i.e. First restore Plugins > Themes > Uploads > Others and at the end restore the database.

    >> Let us know if above method helps to fix the issue.”

    So, try the thing we described having already tried (right there in our previous response), and for which the attached log was attached, and for which we had already increased the PHP max execution time 3000%.

    great. supremely unhelpful. So now we wait yet another full working day, sitting around twiddling our thumbs waiting for yet another probably-useless response that comes during anything other than normal working hours east coast time, and by which time we are able to respond, everyone over there’s already gone to bed. Fantastic.

    posted 9:39am EST

    Bryle Crodua
    This reply has been marked as moderator-only.
Viewing 13 posts - 1 through 13 (of 13 total)
  • The topic ‘restoration of database post migration fails — appears to time out’ is closed to new replies.