Your host may provide database sql backups compressed with tar.gz for space reasons. That will vary with the host. You'll want to uncompress it before reading it into the new database.

Remember, there are TWO parts to transfer: The database (all SQL data) and the scripts (mostly PHP). The PHP code is just a copy and paste, then edit settings.php. The database you need to export from your old web host and then import into the new host's database.

If your web host lets you have shell access, then you can probably make a backup most easily like so:

mysqldump -u yourusername -p -h dbservername databasename > backup.sql

It will prompt you for your password first. All of that information is in your current settings.php file.

If not, then I'm sure your web host has some function on their web control panel to let you "make a backup" of the database (not the site, the database). If the file it gives you is compressed, you can uncompress it yourself with:

tar xvzf filename.tar.gz

on any *nix system. WinZip can handle tar.gz files, too, if you prefer that.

To import the data into the new host, follow the install directions for Drupal but instead of database.mysql, use the backup file you just made.

Does that make more sense? On Wednesday 21 December 2005 05:28 pm, Rob wrote:

Would a database dump be the same as saving a backup copy from the old hosting company in tar gz form and then reinstalling that?

Rob

On 12/21/05, Larry Garfield larry@garfieldtech.com wrote:

...

Hi, Rob. Here's what I do when moving a 4.6 instal from a devel server to live, so it should be the same process.

First, ensure your new host will work with Drupal in the first place. :-) Assuming it does, create a database and database user on the new host, but do NOT put anything in it yet.

Go to your current site and, in admin/settings, disable Clean URLs and the Page Cache.

Take a database dump of your current database. If you're on the command line, mysqldump will do this for you. If your host offers phpMyAdmin, that works, too, or they may have some other backup process. As long as you get a .sql file out of it at the end, either way will work.

Load the database dump into the new database you just created. Again, the exact process varies with the web host, but the command is the same as if you were following the install instructions, just with a different file. After it's loaded, clear the cache table. The SQL command would be "DELETE FROM cache;" (no quotes, of course).

Now, copy all of the files in your Drupal install from your old host to the new host, verbatim. Once that's done, check the permissions on the files/ directory (and its contents) to make sure they're set correctly.

Now edit your settings.php file on the new server. Again, it's just like it were a new install.

You should now be able to log into your new Drupal install and re-enable Clean URLs and the page cache. (Those can sometimes cause weirdness if the new server isn't configured correctly, so it's safer to disable them for the move.)

Bear in mind that if you're also mving the domain name to a new host, there will be a delay in getting the domain to point to the new server. The details there vary depending on your web hosts.

Hope that helps. Cheers.

--Larry Garfield

On Wed, December 21, 2005 5:13 pm, Rob said:

...

I am moving several sites to another hosting company. I wanted to ask if someone could explain how I should go about moving my existing Drupal

site

...

files so I will not lose archives etc.The simplest way possible is what

I

...

need to do since I only know how to use Drupal but am not familiar with some of the technical things about servers.

Rob

[ Drupal support list | http://lists.drupal.org/ ]

-- [ Drupal support list | http://lists.drupal.org/ ]

Bèr Kessels wrote:

Op donderdag 22 december 2005 00:26, schreef Larry Garfield:

...

Bear in mind that if you're also mving the domain name to a new host, there will be a delay in getting the domain to point to the new server. The details there vary depending on your web hosts.

to avoid the delay of other DNS servers picking up the change you can set the TTL value of the DNS entry to zero a day or so (depending on the entry's current value) before switching over to the new IP. That way, downstream DNS servers will not cache the entry during the phase of the switch and will always request the IP from the primary DNS server.

Don't forget to set the TTL to a sane value again after the move.

Here is a way to avoid downtime:

• set up the site (with the backups / sql files etc) on the new host
• add a example.com/settings.php to that new hosts intallation
• add a staging.example.com/settings.php to that new hosts intallation
• Lock down comments and submissions. For all content added, from now on, to

the ld site, will be lost.

• Get staging.example.com dns to pint to that new host [1]
• Test staging.example.com (to find out if everythnih on that new host runs as

wished.

• You might optionally do a new database copy here, and only then lock the

submission on the old site.

• Get the DNS for example.com to point to the new server
• Wait untill the world hasz the new detals and is working on the (unlocked,

you never locked that one down) new site/server

• Remove the old stuff from the old site. A good thing to do is to request a

DVD by mail from the data your account.

[1] Alternaatively, instead of staging.example.com you can use the IP of the new host just add a sites/123.451.234/settings.php (the ip)

-- mike