Does this mean while you are logged into your site you can restore database and everything will reflect the new update or does it mean something different. I never heard of being logged into a site and restoring database so, I'm not clear what you mean by restore.

Comments

ronan’s picture

Restore just means importing a database dump. If you do this while logged in you will not be logged out, but if the backup file contains a sessions table (they do by default) everybody else will be. This works because even though the sessions table will be overwritten, your session will be rewritten to the database once the request is completed.

Does this make sense?
R

darumaki’s picture

Yes, sort of, how does the update process work, in order to update successfully without accesing the database directly, I would think you'd have to have it set to replace ( not insert ) tables/data ? Is this what the module does ?

ronan’s picture

No, this module deletes tables, recreates them and then inserts the data. It is not something you would want to do on a live site unless you absolutely have to. If somebody tries to access your site while you are doing a restore, they could easily get an error. Backing up does not delete anything so it should not affect your users experience (though it may slow down the server).

The purpose of the migration is to copy an entire site from (for example) a live site to a staging site. Or to recover after disaster. It is not intended for incremental updates or to migrate partial data. If you have ever exported a db with phpMyAdmin or mysqldump and imported it on another server, this process is equivalent, but with the added ability to strip unnecessary cache data to save time and space.

darumaki’s picture

No, this module deletes tables, recreates them and then inserts the data. It is not something you would want to do on a live site unless you absolutely have to.

If that's the case how do you explain having to login to the site in order to restore database, or did you mean we would use that backup, take site offline and restore via phpmyadmin ?

That 's the part I didn't understand, you restore via site admin so I would imagine that we would need to take site offlilne then click restore.

ronan’s picture

Taking the site offline is definitely not a bad idea if you are restoring a live site, but it is not strictly necessary. If you do not take your site offline any logged in users (except you) may be logged out when you restore. Like I said, restoring the database should be a very last resort action on a production site. On a development or staging site, of course it is much more common.

If you are confused about how this works, try it out on a development site. Backup the site, make a change, restore from the backup.

ronan’s picture

Status: Active » Fixed

I'm going to mark this as fixed unless you have any more questions.

shanep’s picture

Hi, sorry to re-open this issue but I had a question about backing up specific data and you had mentioned above that the module is not designed for that. I have a sandbox site and a live site. I only want to migrate a few updates because there are things on the sandbox that I do not want to go live and there were minor updates made to the live site that aren't on the sandbox which I want to port over.

I have attempted to exclude all of the tables except for the ones that I thought were the necessary few but it did not update the data from the live to the sandbox site as hoped. It is a "content_type_xxx" table that I need to port over but it has a few other tables associated with it. I looked through PHPMyAdmin I found the exact tables that I needed to get the new data from the live site to the sandbox site. Once I backed them up the module declared "Restore complete. 1789 SQL commands executed." but nothing happened to the data that I backed up - the content was the same as before I did the backup/migrate. Is there a table that I am missing or a step that I may need to take that is not the normal format of backup/migrate?

Any assistance is appreciated, thanks for the great module - it has definitely saved the day a few times!!

~Shane

shanep’s picture

Version: 6.x-2.x-dev » 5.x-1.2

Sorry, I'm using Drupal 5.x and Backup and Migrate 1.2 - thanks!

shanep’s picture

Status: Fixed » Active

Forgot to re-open it.. I need more coffee...

ronan’s picture

Status: Active » Fixed

I only want to migrate a few updates because there are things on the sandbox that I do not want to go live and there were minor updates made to the live site that aren't on the sandbox which I want to port over.

No, I'm afraid that's not what this module does. If you know exactly which tables you need then you can certainly migrate them with backup and migrate, but Drupal's schema is so intertwined that you risk leaving some important data behind and having your db in a compromised state. Unless you know exactly what you're doing, this module should only be used to migrate whole databases.

That said, you're describing a very common problem, and many people have put forth solutions to solve it. I can't recommend any in particular since at my company we always hand migrate changes from stage to live (it's labour intensive but the safest way). But you may be able to get some help in the forums from somebody who has done what you're hoping to do.

I hope this helps
Ronan

shanep’s picture

Ronan,

Thanks for the info! I looked around for a solution to something similar to the one I am having but I have not found one. I definitely have learned a lot more about the SQL tables and Drupal but not enough to feel comfortable transferring it by hand just yet.

I know it's out of the scope of your module but maybe you could give me some advice on what tables I would to find/copy/transfer in order to get a CCK Content Type fully copied to a new Drupal site?

I definitely appreciate the module and the help thus far. Thanks again, cheers!

Shane

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

babbage’s picture

Just to note shanep that by "hand migrate" Ronan almost certainly doesn't mean modifying the SQL tables by hand, but rather by hand again going through the setup options for the new features being implemented through the usual Drupal/module interfaces, other than where direct manual modification of the SQL tables is specifically required for the change being made (e.g. adding an additional index to a particular table, say).