Restoring backup getting stuck

  • Resolved beargreenholta

    (@beargreenholta)


    1 year, 10 months ago

    Hi, I backedup my webstie and trying to move restore it in another web hosting, it getting stuck on the database section

    The logs are here:


    Final checksLooking for db archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-db.gz
    Archive is expected to be size: 163053.7 KB: OK
    Looking for plugins archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-plugins.zip
    Archive is expected to be size: 39386.4 KB: OK
    Looking for themes archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-themes.zip
    Archive is expected to be size: 5985.5 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads4.zip
    Archive is expected to be size: 831344.1 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads5.zip
    Archive is expected to be size: 206381.4 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads6.zip
    Archive is expected to be size: 391738.2 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads7.zip
    Archive is expected to be size: 442182.6 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads8.zip
    Archive is expected to be size: 400237.9 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads9.zip
    Archive is expected to be size: 391079.6 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads10.zip
    Archive is expected to be size: 154849.7 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads.zip
    Archive is expected to be size: 409939.1 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads2.zip
    Archive is expected to be size: 403762.7 KB: OK
    Looking for uploads archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-uploads3.zip
    Archive is expected to be size: 458752.9 KB: OK
    Looking for others archive: file name: backup_2024-07-23-1454_Spotlight_580713f3bfd8-others.zip
    Archive is expected to be size: 1263.3 KB: OK
    Will not delete any archives after unpacking them, because there was no cloud storage for this backup
    DatabaseUnpacking backup... (backup_2024-07-23-1454_Spotlight_580713f3bfd8-db.gz, 159.2 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://spotlight-site.com
    Content URL: https://spotlight-site.com/wp-content
    Uploads URL: https://spotlight-site.com/wp-content/uploads
    Old table prefix: HTk3T3v_
    Old ABSPATH: /var/www/vhosts/spotlight-site.com/httpdocs/
    UpdraftPlus plugin slug: updraftplus/updraftplus.php
    Site information: multisite = 0
    Site information: sql_mode = NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Skipped tables: wp_smack_ecom_info, wp_smackformrelation, wp_smackleadbulider_field_manager, wp_smackleadbulider_form_field_manager, wp_smackleadbulider_shortcode_manager, wp_smackthirdpartyformfieldrelation
    New table prefix: 0i_
    Processing table (InnoDB): HTk3T3v_options - will restore as: 0i_options
    Atomic restore: dropping original table (wp_options)
    Atomic restore: renaming new table (0i_options) to final table name (wp_options)
    Table prefix has changed: changing option table field(s) accordingly: OK
    Search and replacing table: wp_options: rows: 625
    Processing table (InnoDB): HTk3T3v_users - will restore as: 0i_users
    Atomic restore: dropping original table (wp_users)
    Atomic restore: renaming new table (0i_users) to final table name (wp_users)
    Search and replacing table: wp_users: rows: 1
    Processing table (InnoDB): HTk3T3v_usermeta - will restore as: 0i_usermeta
    Atomic restore: dropping original table (wp_usermeta)
    Atomic restore: renaming new table (0i_usermeta) to final table name (wp_usermeta)
    Table prefix has changed: changing usermeta table field(s) accordingly: OK
    Search and replacing table: wp_usermeta: rows: 49
    Processing table (InnoDB): HTk3T3v_commentmeta - will restore as: 0i_commentmeta
    Atomic restore: dropping original table (wp_commentmeta)
    Atomic restore: renaming new table (0i_commentmeta) to final table name (wp_commentmeta)
    Search and replacing table: wp_commentmeta: rows: 0
    Processing table (InnoDB): HTk3T3v_comments - will restore as: 0i_comments
    Atomic restore: dropping original table (wp_comments)
    Atomic restore: renaming new table (0i_comments) to final table name (wp_comments)
    Search and replacing table: wp_comments: rows: 0
    Processing table (InnoDB): HTk3T3v_e_notes - will restore as: 0i_e_notes
    Atomic restore: dropping original table (wp_e_notes)
    Atomic restore: renaming new table (0i_e_notes) to final table name (wp_e_notes)
    Search and replacing table: wp_e_notes: rows: 0
    Processing table (InnoDB): HTk3T3v_e_notes_users_relations - will restore as: 0i_e_notes_users_relations
    Atomic restore: dropping original table (wp_e_notes_users_relations)
    Atomic restore: renaming new table (0i_e_notes_users_relations) to final table name (wp_e_notes_users_relations)
    Search and replacing table: wp_e_notes_users_relations: rows: 0
    Processing table (InnoDB): HTk3T3v_links - will restore as: 0i_links
    Atomic restore: dropping original table (wp_links)
    Atomic restore: renaming new table (0i_links) to final table name (wp_links)
    Search and replacing table: wp_links: rows: 0
    Processing table (InnoDB): HTk3T3v_postmeta - will restore as: 0i_postmeta
    Database queries processed: 50 in 1.34 seconds
    Database queries processed: 100 in 2.34 seconds
    Database queries processed: 150 in 3.77 seconds
    Database queries processed: 200 in 5.34 seconds
    Database queries processed: 250 in 6.29 seconds
    Database queries processed: 500 in 13.55 seconds
    Database queries processed: 750 in 21.01 seconds
    Database queries processed: 1000 in 28.36 seconds
    Database queries processed: 1250 in 35.46 seconds
    Database queries processed: 1500 in 43.08 seconds
    Database queries processed: 1750 in 50.59 seconds
    Atomic restore: dropping original table (wp_postmeta)
    Atomic restore: renaming new table (0i_postmeta) to final table name (wp_postmeta)
    Search and replacing table: wp_postmeta: rows: 8133
Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Support vupdraft

    (@vupdraft)

    1 year, 10 months ago

    Can you try optimizing your DB with the free plugin WordPress Optimize (getwpo.com)

    We often find this is enough to get a restoration through when it’s having issue with a bloated post meta table

    iamviveksri

    (@iamviveksri)

    1 year, 10 months ago

    @vupdraft Hi- i have been a user of updraftplus for many years now. i noticed one thing- maybe its true maybe not but need your expert advice please

    So what happens is that I lock some of the backups which i think were new additions/deletions in my website and let updraft take normal backups daily as well as delete all except the last 10 backups.

    So once i tried to restore using the last days backup which was NOT locked. and the restoration failed. then i used a locked backup which worked but because it was taken long back, i lost all my new blogs.

    So please advice on two things- 1. does locking effect the backup’s integrity… will the other unlocked backups also fail similarly in restoration. 2. if i want to attempt restoring is there some way i can save the blog posts somewhere first – so that even if the newest backup fails to restore i can go to an old (locked) backup and then get the blogs back from the other place i stored them?

    really grateful for your help

    regards

    vivek

    Plugin Support vupdraft

    (@vupdraft)

    1 year, 10 months ago

    Hi,

    Locking the backup will have no effect on restoring the backups (it just means that the backup will not be included in your retention deleted and thus not automatically pruned)

    The post meta table is famous for becoming bloated. The older backup likely had a smaller post meta table which was easier to restore.

    Your posts are in the wp_posts table (your prefix may be different. You could try restoring just the posts table to get your most recent posts back: https://snipboard.io/aA0SBc.jpg

    iamviveksri

    (@iamviveksri)

    1 year, 10 months ago

    @vupdraft thank you for your kind advice. regards

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Restoring backup getting stuck’ is closed to new replies.