Duplicate a Drupal installation from one server to another_问答_开发者

I have been developing a Drupal 6 site on my PC using XAMPP. I'm done now, and everything looks peachy.

Problem is, I need to put all my content (including custom modules and themes) up onto a staging server which only has a fresh Drupal 6 install on it. I can't imagine having to set up all my custom content types and whatnot all over again on the staging server.

So I ask, how does one go about doing what I need to do? Which is essentially duplicating my Drupal install from my PC, to the sta开发者_如何学运维ging server.

The staging server is running Linux, and I develop on a Windows PC, if that helps.

Thanks in advance.

Copy up all the files from development to live, and mysqldump your database and run that on the live server. Then all you have to do is change the settings.php file to point at the right database, if for some reason 'localhost' is not also your mysql database.

The quickest solution is probably the backup_migrate module. It is only a tool to copy your database. You could also use phpmyadmin or similar instead if you wanted. The backup_migrate module do have some good defaults settings as to which tables to skip (like cache tables). All the settings etc. that is not defined in code is stored in your db. So you only need to copy the db to be set. You can choose to exclude some tables, like the node or user table if you don't want to bring over your test data.

If you don't use subversion, then you gotta manually copy the files (rsync, scp, whatever) and the db (mysqldump).

what we usually do is have a hierarchy of independent subversion repos as follows:

core
sites/all/modules/contributed
sites/all/modules/custom
sites/all/themes/ (we develop our own and don't use contributed themes)
sites/all/libraries

then we use the svn:externals properties so that if you check out "core" you get every associated repo.

we got about 2 main developers with 4 other guys that may also contribute code to the site. each have their own local dev environment and we all got a common sandbox - where we make sure the stuff we wrote doesn't break someone else's module (it has happened before!).

we use svn commit hooks to update the beta/staging/sandbox site upon commit.

with all that setup, [re]deploying a site is a simple matter of going to the proper folder and issuing a "svn co http://repolocation/reponame ." and then updating the DB.

two last things to consider:

we are moving from svn to git
the features module will allow you to save changes you make to your own modules (views, content types, etc) and package all that into a deployable module so you don't have to duplicate your efforts. we are also looking into using this for ourselves.

I hope this helps you.

I second using backup_migrate. It's great.

When I'm installing a fresh site from development to production, I:

backup the site using backup_migrate module
copy all the files up to the server
edit the sites/default/settings.php to have the right database path and account info
do an import of the last backup_migrate dump (usually using mysql < backupfilename.sql, unless I already have drupal setup and have backup_migrate installed, then I use the GUI

But take a look here for the official version:

http://drupal.org/node/776864

Now, you didn't ask, but when the site is live and users are contributing content, moving future development versions of your site from development/staging to production without blowing away live content is a whole different problem, and one that Drupal doesn't have a good answer for...

Andy-