I created a database backup from a live site. I'm on a fresh install of a local site and trying to use this module to restore my live database onto the local site.
Here's what I did:
Download and install the Backup and Migrate module on your site (http://www.drupal.org/project/backup_migrate)
Navigate to administer -> Content management -> Backup and Migrate
Download a database backup on this page
Copy your entire site structure to your local server
Navigate to sites/default on the local installation
Delete the file settings.php
Copy default.settings.php and rename the copy to settings.php
Install Drupal, same as you did when you first created your site on the server. Don't worry too much about the site name or account info etc, as you will overwrite this all afterwards
After you have installed Drupal, enable the Backup and Migrate module
Navigate to Administer -> Content Management -> Backup and Migrate -> Restore
Upload (and restore) the database backup you took from the remote server
This last step is not working. I basically get a page refresh.
Comments
Comment #1
xl_cheese commentedI'm just wondering if someone can help me? I tried this again on a different computer at home and I still see the same problem.
When I click upload nothing happens.
Comment #2
keithm commentedYou should have some kind of status message posted on the page and in the log file whether the restore succeeded or failed. What does your log say? (/admin/reports/dblog)
Comment #3
keithm commented(duplicate apparently due to drupal.org crash)
Comment #4
barwonhack commentedI have this issue too. I suspect it is a PHP5.3 issue
Comment #5
barwonhack commentedScratch the above. It is something else - another module I guess.
Comment #6
Gridpike commentedI ran into the same problem, but was able to fix it after taking the following steps:
If that didn't fix it, then do the following:
For help on this, here are two links offering the same solution within a Linux server accessed through PLESK, but written for audiences of different skill levels:
Should you still be experiencing problems, browse to your Drupal reports page([domain]/admin/reports/dblog) to see if there are any specific errors.
I hope this helps.
Comment #7
chaosprinz commentedHello,
i have got almost the same problem. The difference is that i didnt use the fileupload, but the destinations and copied the mysql.gz from one server to the other with scp.
I checked my php.ini, where Safe_Mod is off and basedir-restriction is turned off.
When i look into reports/dblog it says:
"Default Database restored from Manual Backups Directory file schala_bkup_14_03_11.mysql in 4393.57 ms. 8236 SQL commands executed."
But it changed nothing.
It is my own server and i configure it how i want, so if anyone has an idea: Everything can be configured for my needs.
Comment #8
Andy Langton commentedThis problem can occur if you've specified a database prefix in settings.php or via the installer and then restore from a database that did not use the same prefix.
Backup Migrate executes the SQL commands successfully, but you won't see any change if the prefix is different unless you change the prefix in settings.php to reflect the database you restore from
Comment #9
Old Man commented@Andy Langton - THANKS!
I spent over an hour scratching my head, wondering why B&M didn't work. It was the table prefix in the settings.php file. Changed that to match and now good as gold!
Comment #10
zakir.gori commentedHi if not working
why you are not using phpmyadmin take backup from php myadmin open your backup file search
Database: `database name`
write your localhost drupal database name and import it
i used this before its work for me.
Comment #11
Old Man commented@zakir.gori
I made a new installation of Drupal 7 using a script at a new webhost using CPanel (ugh! I hate CPanel). The script assigned a table prefix and didn't notice that. I DID try importing the database from localhost, and it didn't work because of the prefix on tables at the new host.
Removing the prefix in settings.php resolved to problem.
Comment #12
zakir.gori commentedComment #13
Anonymous (not verified) commentedThanks Andy!
I never had this problem before.
Removed the 'dp__' from prefix in settings.php and suddenly it works perfect.
Thanks a lot!
Ben.
Comment #14
Anonymous (not verified) commentedComment #15
zakir.gori commentedi am marking as fixed.
Comment #17
jorisx commentedWould be nice if the migrate/restore option could fix the prefix.
Is there any work been done on this?
Comment #18
quantos commentedGuys. I have just run into the same issue - without knowing if it is the same cause, see https://www.drupal.org/node/2321021.
The consensus in this thread is that "removing 'dp__' from prefix in settings.php fixes the issue" for original 6.x-2.2 branch whereas my issue has suddenly sprung forth after the current D 7.3.1 update (and is present in both the Backup 7.2.8 and 7.3.0 branches) where the restore function no longer works, almost exactly as described by xl_cheese at #1. I was previously using Backup 7.2.8 perfectly happily backing up and restoring from/to local/remote servers and so can't yet tell if this is Backup, core, php or mysql (or anything else?) issue.
I.E. I'm still none the wiser what the issue is and can't see any 'dp__' prefix info in the current D 7.3.1 default.settings.php or in a clean installed settings.php file.
Any help/pointers with this would be highly appreciated.
Q.
Comment #19
ivnish