Hi all,
I have to migrate a complete website made in drupal from one host (let's say www.address1.abc/drupal/) to another (let's say www.address2.abc/). Both of them have the same version of php, mysql, ...
I used backup_and_migrate module to backup the db, I installed the drupal on the new website and copied the sites folder from the old website, paying attention in keeping the settings.php of the new installation.
Then using backup _and_import I tried to recover the db, but nothing worked... I opened the .mysql file of the backup and I found that in that file it appears frequently the path of installation on the old website (both www.address1.abc/drupal or /drupal or the complete path on the server) and this prevents me to have a successful restore. I tried to edit the file to try to correct the errors but at the end it was even worst and now I broke the website.
Why is it so difficult to migrate a website? How can one test it in a sandbox on his computer and then make it public on a website if it is so difficult?
For sure I'm doing something wrong... can somebody of you help me?
thanks
Regards,
Mirko
Comments
Cache
Did you clear all the caches before exporting the database from the old address?
This signature is currently blank
Did it
Yes, I cleaned up the cache from
admin/config/development/performanceand I did the backup then, but still I can see the complete path of my website and also the path on the server.This make it impossible to migrate the website, but it is ok as backup if the path never changes...
Why does it happen?
Table names
What tables do those reference to the full-path occur in?
This signature is currently blank
Examples
I put here some examples:
Thanks,
OK cache_bootstap - if
OK
cache_bootstap - if clearing the caches from the performance screen isn't clearing that out, you can empty the table in phpMyAdmin before you migrate the site. That table should be empty when you migrate.
The I10n_update_file table relates to http://drupal.org/project/l10n_update - you'd be best off asking in the issue queue there as to what goes in that table and whether it matters if it's not empty.
The watchdog is the log - it contains a record of significant events that have occurred on the site, such as new nodes created, new user accounts, modules enabled, and so on. Some of those entries will contain mention of the domain / full file path, but none of that matters - it's just a historical log. You can delete the entries in that table if it bothers you, but there's no need and it's generally good to keep a log like that.
Any more?
This signature is currently blank
Contacts and others
Thank you,
I'll contact the locale package to ask for information. I'll deleted all the content of all the
cachetables and also the watchdog, but before trying to migrate it i checked again and I found:avdrupal_locales_source, subfolder of the website in which to find the website (i.e.www.example.com/subfolder)avdrupal_system, subfolder of the website in which to find the website (i.e.www.example.com/subfolder)avdrupal_variable, full path on server in 1 row about the garland theme (where to find images)these should be everything.
What should I do then?
Thank you!!
That should be fine - try it
You should now be able to import the database onto your target machine, and you're good to go. You should probably delete the cache on the new machine as the first thing you do, and that will sort out your last few entries.
This signature is currently blank
Worked
Yes, I was able to do that and it worked!
It is so strange that such an "hand-made" solution is needed with the backup&migrate package... and also it is strange that the clean cache function actually does not clean perfectly...
Thank you!!
For any future migrations,
For any future migrations, I'd definitely recommend to use 3-rd party tool xCloner, which is really great with site / DB archiving and moving.
Not relevant?
How, exactly, would that have helped with the precise problem this person was having?
This signature is currently blank
The problem has been fixed as
The problem has been fixed as we can see, this was just a suggestion for future if anyone would experience the problem regarding account move. Thanks for commenting.
Cheers.
But the cache
Agreed - but the person asking the question was having no trouble moving the database. The difficult step was making sure that all cached references to the original server's filesystem were removed from the database before migration. Unless I've missed something xCloner doesn't understand Drupal's table structure in such a way that it could help with sanitising the database.
This signature is currently blank
The xCloner actually is great
The xCloner actually is great with backing-up/moving entire site with its DB, so sure you'd prepare account first.
Thank you for the other
Thank you for the other proposal.
I'll keep it in mind and check for future migration eventually.
My problem anyway was that I was changing the complete path of the website and I needed a way to clean the DB, not only cloning it.
Thanks
Regards,
You're very welcome.
You're very welcome.