Moving servers

[Paul Ward]

Hi,

Not sure if this is the right place for this. I'm in the process of moving server at my current host and wondered what the best of going about moving my VBulletin forum is?

So far:

Uploaded all site files to new IP address
Downloaded current VBulletin files to desktop
Upload files from desktop to new IP address

Next step I guess is to set up my new MySQL database and then down/upload the existing database to it.

Does anyone know if this will work? Do I need to go through a new install on the new IP address? Is there anything I should do in advance?

I'm trying to pre-empt problems in advance rather than do it find it doesn't work and then have to get it working again.

[docvader]

I'm in the process of doing the same. According to vbulletin.com's instructions, your understanding is correct. You'll need to change the database/server settings in your config.php file once you've reuploaded your vbulletin files. You might also have to, after getting it all to work, alter some things in vbulletin admin area, such as the bb url setting. Uploading your vb files, making sure permissions are ok, and reconnecting to the newly uploaded and created database via includes/config.php, should do it.

The problem is, moving the databases. Especially if you have a large one. And, if you don't have ssh or telnet access on your new server.

PhpMyAdmin generally will not accept database transfers above 2mb. Which, doesn't do us any good. I've found that bigdump (http://www.ozerov.de/bigdump.php) is the way to do. Instructions are on that site. I've got some suggestions, however, if you go the bigdump route.

Run PhpMyAdmin and dump your database into a text sql file. You can either run the entire vb database at once, or, successively back up portions of the tables into different sql text files (and name them a.sql, b.sql, c.sql, putting all of the tables starting with "a" into the a.sql dump, etc).

Alter bigdump.php settings so that they match your msql user ID and password, table's settings.

Upload your text sql backups and bigdump.php into a "dump" directory on your new server.

Run http://yoursite/dump/bigdump.php

Now, the problem may arise, if you have a large database, whereby the new server will not allow more than 50000 "questions" per user. The install of your dump will fail. So, to bypass this problem, you need to create more users in mysql in your new server. How to do this depends upon the host that you have. Sometimes you can do it in your new host's control panel. Create ten or twenty more mysql users, that can access the new vbulletin database that you already created, and give them the same mysql access password. Then alter your bigdump.php file to include the new users. You get more "questions" as you reinstall the database, thus bypassing this error. I can tell you how to write this, if you go this route.

Alternatively, if you have ssh access, it's much easier.

To backup your mysql database (open a ssh window):
mysqldump --opt -Q -u dbusername -p databasename > /path/to/backupname.sql

New mysql don't require the opt command or q, you can sometimes do this:
mysqldump -u dbusername -p databasename > /path/to/backupname.sql

Upload "backupname.sql" to your new server, and restore:
mysql -u dbusername -p databasename < /path/to/backupname.sql

That's the easiest way, if you have ssh access.

Restoring via phpmyadmin, if it's a large file, will give you problems. phpmyadmin is not very good at working with large database restorations. Uploading table by table, especially if you have a heavily hacked board as I do, is a time consuming nigtmare, which is why I use my very unscientific a, b, c ... method.

Another option is to do a phymyadmin gzip or text dump of your entire database, upload it to your new server, and ask tech support to reimport it into the new database that you (or they) created.

Good luck. It's not an easy issue if you don't have ssh access, but bigdump works in most cases. And, as I've discovered, sometimes you have to "trick" the mysql server into using it successfully

rich
russbo.com

[baronvonwalz]

The best way to do it is to ask your current host for a database backup, which you then hand over to your new host for integration onto the new server.

[Paul Ward]

Thanks for the replies guys, especially docvaders impressively comprehensive one!

My database isn't that large, so hopefully it will go fairly smoothly, I'm going to leave it until tomorrow, so I have time to sort problems if necessary.

I'm moving servers with the same host - victim of my own success I'll come back and tell you how it went.

Thanks again.

[BoardTracker]

If you have ssh access an easy way to transfer a large mysql db is with scp. Just create the db on the new server then shutdown the db completely (on both servers) then scp the whole lot in one go to the new server and then make sure the tables on the new server are owned by mysql (chown mysql:mysql /path/to/yourdb/*) and restart mysql there. It should all be working fine as long as you created the appropriate db accounts (grant) etc. I've used this method often to copy db's with many gigs of data.

Something like this would do it..

scp /path/to/mysql/yourdb/* username@newserver.com:/path/to/mysql/yourdb/

if 'username' does not have access to /path/to/db/yourdb/ then just scp to whatever directory it does have access to (/home/username/tempdb/ for example) and then do a local copy/move to the appropriate mysql directory.

Check the man for scp options (man scp), test it with non-essential files/directories first and of course always make sure you have a backup before doing anything!

You could also use rsync over ssh (rsync -a -e ssh /full/path/* user@newserver:/full/path/) which is handy but seems a bit slower than scp alone.

Oh and make sure you have enough disk space on the new server before copying or you will end up with a broken db there.

You could also do a local copy first, zip/gzip the files then scp to the new server and unzip.. depending on your needs it may or may not be faster.