1. Backup your current files, this is simple with the "tar" command in Linux/Unix/BSD as:


Additionally, if you're on a "windows" machine you can zip the directory or use any other archival tools available on the machine; if you don't have any you *could* download them file by file via FTP but it will take quite a while.

2. Now you'll want to backup your database, you can do this from free tools like PHPMyAdmin, however I recommend doing so through the command line (in Linux/Unix/BSD) as:


(Note that you can optionally use the -hhostname and -Pport trigger should you be communicating with a non-local SQL server; please note that most servers do not allow non-local access.)

You can also tar the output by:


Alternatively, if you're on another OS or cannot use Linux command line tools, you can use web utilities like PHPMyAdmin to download an archive of your sql data. Please note that on large forums this is not recommended, and it is always recommended to use the "compression" options within PHPMyAdmin itself (tar/globalzip are recommended).

The Linux/Command Line versions will take MUCH less time to import/export, as you're not going through a php script which uses the web server; you're accessing the SQL server directly.

3. Now you'll want to transfer your backups to your new server. You'd do this either by downloading the database and forum backups to your hard disk, and uploading them to the new server -OR- you can place them both in a web-accessible directory on your old server, and use the "wget" command in Linux/Unix/BSD to download them, ex:


From here you'll need to decide how you'll put the old files on the new server. If the new server is a Linux machine and you can access it via SSH and have access to "tar" and mysql command line this is a simple process. If your new server is windows based you'll want to be sure it has compression tools if you wish to place a compressed archive (that you likely created in steps 1 and 2) on it.

You'll want to decompress the files on the new server; in Linux/Unix/BSD with tar you'd do:


Once tar has extracted the files, you'll want to change to the appropriate directories within the extracted files, and use the "mv" command to move the forum files to their proper new location, EX:
cd the/directories/that/where/created/when/you/made/your/backup/ (by not using a starting slash you tell the command to go from where you are now vs the physical path ont he server)
mv forum /the/new/location/of/your/forum

4. Now that the old files are on the new server, you need to import your database; you can again use PHPMyAdmin or use the command line to import the database. The command line way of doing this (note, this is not the MySQL command line, simply the Linux command line) would be:


(Note that you can optionally use the -hhostname and -Pport trigger should you be communicating with a non-local SQL server; please note that most servers do not allow non-local access.)

The Linux/Command Line versions will take MUCH less time to import/export, as you're not going through a php script which uses the web server; you're accessing the SQL server directly.

Now that the database and files are now on the new server, you need to update your permissions of files and directories, they may or may not have been carried over via your backup (if you used tar), so you'll want to make sure that your files are chmodded 666 and your directories 777.

After checking your permissions, you'll want to update your includes/config.inc.php file, updating the paths (and urls if they're different) for the new server. At the time I'm writing this article, these lines are:


You'll also want to update the MySQL connect information in your includes/config.inc.php file:


5. From here, you should be completely moved over, it may sound quite difficult at first, but it's really not. Time can vary based on the size of your database, and some sites will be larger than others.

Additionally, if you don't feel comfortable about preforming the move yourself, you can always hire a developer *ahem*orme*ahem* to preform the migration for you.

Very handy Gizmo

If only for the comand lines at the very least.
I'm going to be doing a sort of transfer when we have 7.1 Final
so i can give it a blast.

hehe, i need to write an upgrade guide for within 7.x

Good work, Gizmo.

Regarding "tar" and file/directory permissions, does anyone know for sure whether they carry over or not?

they should with the -p flag

I can move a tar file manually to the new server by downloading it to my desktop first, right? And I take it that I would use binary for this, which seems to be the way to move zip files as well?

If I was to do it using the "wget" command then how do I then transfer & unpack it in the right directory, namely the "/public_html/" one?

And how would I be able to "wget" the database dump into a directory that is not the www one, say one level above the web root?

1. You CAN.
2. You'd untar it, then cd to the directory of files you wish to move, then:
mv old_public_html/* /path/to/new_public_html

And WGet is a linux command, you can run it from any directory that you have permissions to run it from; but on the site you're grabbing it from, it has to be in the webroot to use wget to grab it.

The directory I'm currently in when I type in "tar -cvpzf my_ubb_backup.tgz /path/to/threads" is where the zipped file will be placed?

OR is there a command that I can add to that line that will point to the directory where I want the zipped file to be saved?

just put the full path to the chosen directory before the my_ubb_backup.tgz - so /full/path/to/my_ubb_backup.tgz

If you do ian's route you can specify the directory, if no directory is defined the file will be created wherever you execute the command (assuming you have write access to that directory)

Guys, can I make the tar files and do the wget thing when logged in as root?

Because in SFTP for instance you are logged in as root and if you upload a file then disconnect and FTP in normally you will not be able to delete that file as it is owned by root and not the user.

Will something like this be the case with making the tar file or doing the wget if I am logged in as root via ssh?

You CAN do that just fine as root; in fact, I did it when I was writing it up lol...



If you planned to SCP the file to your local computer you'd have to chown the file to a username you can access the machine with though.

Just a purely hypothetical question about moving the db dum...

Is it going to be quicker to tar the dump, then wget it on the new server, and then (un)tar the dump... or would it be quicker to just wget the dump without doing the tar and untar?

What kind of compression ratio are we looking at when doing a tar of a dump file?

If you're going to be transferring it from one machine to another with WGet and they're both on professionally hosted lines (IE a non DSL/Cable line) then it should be fine to just forget tarring it, as it's text it'll transfer pretty fast on it's own and would take about the same time, but it may affect yoru bandwith quota on either host; so tarring would be best if possible.

And we're looking at a 200mb dump being 20mb.

Righto, I just tried moving my forum to a new server and failed miserably.

I was able to do the following:
-dump the db
-tar both the dump as well as the forum folder titled "ubb"
-wget both to the new server

What I couldn't do: tar (unpack) any of the files on the new server

1. This is what I got when I typed "tar -xzvf forumdump.tgz" into the command prompt:

...a pause that lasted a few seconds, and then this...


gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

2. I was also unable to tar (unpack) the forum files. I did the wget while being in the web root of the new server account, so the tgz file was naturally saved in "public_html" which was what I wanted. But when I tried to unpack it (tar -xzvf ubb.tgz) it simply listed all the compressed files like this... but no new files appeared anywhere so nothing got unpacked:

home/forum/public_html/ubb/file1.whatever
home/forum/public_html/ubb/file2.whatever
home/forum/public_html/ubb/file3.whatever
home/forum/public_html/ubb/file4.whatever
and so on...

What's interesting is that it was listing the path that was used on the old server: home/forum/... (which surprised me because why should a compressed file list the previous absolute path of all its elements), whereas on the new one the correct path is home/ubb/... Still, nothing was unpacked anywhere.

============

Any thoughts on how I can move my forum files across successfully? Is there a way to move over the ubb folder using wget but without a) having to compress anything -and- b) keep the original file permissions? The compression thing is messing me up and I can afford to go without it. But how can I keep all forum file permissions intact?

Very odd, generally that means that the tar archive wasnt' fully created on the source...

And yes, it iwll list what is listed, the -v flag is verbose, which means it'll list all files as they're extracted. It should have extracted all the files to home/forum/public_html/ubb (from the directory you're in; so if you're in /home/gizmo they'd be in /home/gizmo/home/forum/public_html/ubb).

the reason it's listing the path is that when you tarred them you specified a full path to the files, so it was backed up as paths; you can use mv to move the files to where you want them once they're on the server.

Had a few questions earlier but it's all cleared up now.

I had a problem removing files via ftp later after moving and untarring them while logged in as root (funnily enough I could erase the tgz file but not the files that came out of it), but this is not a problem as I can ssh my way in under the account shell login instead.

I'll give the entire move operations another shot in the evening.

ahh, that'd be due to the -p flag (the deletion issue) as it preserves user permissions; so if you run it as root on one machine and don't have root access on the other, you could run into a pickle...

Actually it doesn't seem like the -p tag is the reason as that is used to compress the files/folders. It actually seems to depend on what I'm logged in as (root or user) when I unpack the tgz file on the new server.

So if I use the -p tag to compress the file when logged in as root, I can then uncompress the file on the new server while logged in as the account user and everything will be fine.

Just a quick last-minute question: how would you compare the time it takes to make a mysql dump to the time that it takes to restore the dump on the new server? What kind of ratio are we looking at? Similar... twice as long... more?

-z is the compress (globalzip), -p is preserve permissions.

and I'd say they should take similar times, at max a large db should only be a couple of minutes.

What is the parameter to preserve the document permissions if -p does not work?

Thanks for the review, I just moved a 700mb tar of someone's html/php files (yes, it's a huge site, the db tar is about the same size ). It only took me about 8 hours as opposed to 3 days my old way

Totally overlooked this post...



I believe -p is the only way to preserve permissions while utilizing Tar to create an archive...

Yeh, theres often faster ways to do things hehe...

My favorite is to create the archive, move it to a web directory, then use wget on the destination machine to snag the file... No downloading on your part required, and can usually do a 700mb file in seconds...

There wasn't ssh on the old server. :smash:

Yikes, that's one heck of a drawback... SSH just makes things fun ;)...

If it's a linux maxhine, you could use system() or exec() to issue shell commands (if the machine allows it); I have a site on a server I don't have SSH access to and that's how I roll out my maintenance (backups)

hmm... I do have this shell script I probably could have used...

There are a lot of "PHP Virtual Shell" scripts out there that I've been guilty of using; when you get backed into a wall... lol

Is this still a fairly accurate guide? This is exactly why I logged in this morning. Thanks, Gizmo! Problem is ... I don't have command line access on the old server and I want to move to a new server at some point. Any recommendations on hosting providers?

Thanks,
Bill

Ok, it still appears to be fairly accurate. I'm getting the following error when trying to backup the forums:

write failed, user disk limit reached mysqldump: Got errno 69 on write

Does anyone know if there are any options to store the backup elsewhere during the backup? I'll also post on the hosting support forums. Thanks!

This is the guide that i use (hence why I threw it on the forum ;)). I would totally recommend only using hosts with CLI access as it makes certain tasks much easier (backing up with tar, utilizing the mysqldump command, etc).

That error occours becasue you're reaching your space limit (see Disk limit reached), you can't write after you reach your limit.

Most hosts "secure" the mysql server by not allowing external (off site) connections, otherwise i'd tell you to use sqlyog (as i believe it will allow you to dump all data to your local machine). The backup utility in the forum will also reach this space limit, so no use recommending that... You may contact your host, and ask if they could dump the sql database for you as you reach this limit, a lot of them will actually be helpful for "backups".

As for recommending a host, I only really recommend VPS for larger sites, and in that I recommend http://www.webintellects.com

Not easy to debug, but wonder if you could run that stuff from CRON job on hosts that don't allow SSH.

If they allow you access to cron, i don't see why it wouldn't work... most webhosts that don't give you cli access though likely don't give you access to cron either

Well not sure - I've been on a few Linux hosts that did not have or charged extra for SSH but they do have CRON (via Web interface)

FTP up what you want to do then let CRON do it

Yeh, cron can be a really useful tool; in fact I use it to run backups on the 1 site I don't host myself that I own...

Thanks Gizmo, for the GREAT guide to get me started with the transfer! One note for you to possibly include in future editions of your guide: When the SQL and Web servers are different, the --host= command can be added to the mysqldump command (e.g. mysqldump --host=mysql.serverhost.tld -uusername -ppassword my_database_name > my_database_name.sql).

It worked! Yay! Thanks again, Gizmo!!!

I just updated both SQL sections with:
(Note that you can optionally use the -hhostname and -Pport trigger should you be communicating with a non-local SQL server; please note that most servers do not allow non-local access.)

I just followed the instructions to move a copy of my site to a testing site, and all I get is a blank page when I try to bring up the site. No errors or anything, just a blank page. I did the sql dump, and imported it into a new database. Any suggestions?

Thanks,
Ian

Did you set the information in your includes/config.inc.php?

Yep, Sirdude helped me out yesterday, it looked like the ubbthreads.php file might have gotten messed up somehow. I am going to upgrade the test site to 7.3 today.

Ian

Top top post Gizmo

I was struggling on how to create a parallel install so i could trial 7.4 before commiting fully to upgrading the live site. Found this post and now have a wonderful test instance to play with +++

Chuffed

Gizmo,

I followed your instructions and have successfully transferred a modererate sized forum from one ISP account to another (same ISP). I have checked permissions, and modified all code in the custom islands to reflect the appropriate data paths as well as modifying the config file.

However, I have a problem. I have three custom islands that are not working. When I try to "modify" the code within the island, I get the SQL ServerError message:

Script: - Line:
SELECT
COUNT(*) as total, p.USER_ID, u.USER_DISPLAY_NAME,
u.USER_MEMBERSHIP_LEVEL, up.USER_NAME_COLOR
FROM ubbt_POSTS as p,
ubbt_USERS as u,
ubbt_USER_PROFILE as up

WHERE u.USER_ID = up.USER_ID
AND p.POST_POSTED_TIME > 1212842253
AND p.USER_ID NOT IN (1,2)
AND p.USER_ID = u.USER_ID
GROUP BY p.USER_ID ORDER BY total DESC
limit 5
- Server shutdown in progress

Of course the Posted Time changes...

Any advice?

Thanks

seems that it is related to "pathing" of some of my custom islands. When I corrected the appropriate paths to the new server, it seems to have stopped the error messages. 2 out of 3 custom islands are working fine.

I will continue to monitor the situation and let you know what I discover.

Turns out that it is a pathing issue...

Any coding that uses absolutes paths within a custom island that is no longer accurate will "break" the portals ability to modify settings within the control panel. Of course the content will also not display correctly.

The solution is simple, modify the absolute paths according to the new server information, and save the changes. Even though you will get an SQL Error message, if there are other broken paths, the changes are saved.

Once you have finished modifying all of the custom island paths, clear the cache from the Control Panel menu and presto, no more server errors.

Hope this helps.

Lol, glad you figured it out ... Was working on a new server rollout for a client (:glares at glider:) so have been busy most of the morning hehe

Hmm old posts but useful, hopefully I am asking in the right place, I plan on moving my 7.2 ubb board to a new hosting setup soon, (still shopping) one problem the mysql version on the old host is 4.1.22 the newer hosting firms are at 5.x (that I have looked at so far) can this older version database be migrated or am I sol???? or in for a big hassle?

Shouldn't be any different really, if you have command line access it'd be exactly the same on my recommendations.

Thanks Gizmo, it worked out ok even without shell access, after I worked out a couple "fatfingered" settings it's all good so far as I can tell. (now off to muck around with dns for a while)

just readed this thread now.. Its all good for me.