Wed
Jan
14

2009

Moving large amounts of data between servers.

This is unashamedly another case of me documenting some rarely used server tricks so I can find it again next time I need it.
However, the last time I did this, it proved to be useful for others, so here we go:

Situation: You have a web server account somewhere with application(s) installed on it, and probably a MySQL database or two connected to those app(s). For whatever reason, you find yourself wanting or needing to move that app and it’s db to another server.
I had such a situation this week. I wanted to move a development installation of Magento – a very large open source ecommerce application. My install consisted of over 16,500 files in more than 5,400 directories totalling around 110Mb. Normally, you would move that by downloading all the files to your local system via FTP, then uploading the same files to the new server. While the total size isn’t too bad, the sheer number of files makes transfer via FTP just painful.
An example: deleting an earlier version of the app took over 4 hours via FTP!
In addition to the number of file and folders, the associated (nearly empty) MySQL db was about 2.9Mb with about 130 tables. Easy.

Solution: The very helpful resources at http://magentocommerce.com gave the answer, and this is merely a re-hash of that information, with a few changes for my situation.

Assumptions:

  • That you have SSH (Shell) access to both the old and the new servers.
  • That the existing app is installed in your public folder – public_html.
  • That the path to that folder is: /home/username/public_html and your SSH client will put you into the folder ‘username’ by default.
  • That you haven’t changed the domain DNS settings on the ‘old’ server – so it is still accessible by the domain name.

Old Server

  • Fire up an SSH session on the old server.
  • Move to your public_html directory using this command: cd public_html
  • Make a new folder for our backups: mkdir backup
  • If your app has a MySQL db, you need to make a backup of the db (a ‘dump’). This is the command: mysqldump -h DBHOST -u DBUSER -pDBPASS DBNAME > data.sql

You will need to replace the values with the correct information: DBHOST – Database host name, usually just localhost DBUSER – Database user with access rights to the database DBPASS – The password for the database user DBNAME – The name of the database that your web app is using

The backup will take anything from a few seconds to a couple of minutes, depending on it’s size. You will now have a file called ‘data.sql’ in the public_html folder.

  • Move the db backup tgo the backup directory using this command: mv data.sql backup/
  • Now we need to zip up the whole of the app – all it’s files and folders – into one compressed file. This is the command: tar -cvf backup.tar public_html/

New Server

  • SSH into your new server.
  • Go to the public_html directory:@cd public_html@
  • Make a place to put the backup files from the old server: mkdir backup
  • Go to that directory: cd backup
  • This is the fun bit: Grab the files from the old server using these commands:
    wget http://www.old_domain.com/backup/backup.tar
    wget http://www.old_domain.com/backup/data.sql
  • We need to extract the backup data: tar -xvf backup.tar
  • And move all the data to the public_html: mv public_html/* public_html/.htaccess .
  • You can remove the extracted public_html directory now. Do not confuse this with the public_html directory for your site, this is only the name of the directory that was in our backup file!
    rm -rf public_html/

Database restore

  • If you haven’t already, make a new, blank database on the new server (probably through your cPanel)
  • Restore the backup up data to the new db:
    mysql -h DBHOST -u DBUSER -pDBPASS DBNAME < backup/data.sql
    (replace the parametres as you did before)
  • Check the db parameteres of your app, to make sure it can find the db on the new server.

That’s it! It should all be good to go, once you’ve changed the DNS settings to point your old domain to the new server.
That should be it!

Comment

  1. Hi Neil,

    It’s always good to document a process so you can remember how to do it next time. A query/suggestion though – is there any reason you didn’t compress the archive you made?

    tar cvf means create/verbose/file.
    tar cvzf would use gzip compression to reduce the size of the archive – good for storage and transfer. tar cvjf uses bzip2 compression, even smaller files.

    Similarly with the database – gzip data.sql would squish it down a fair bit – especially if mostly text.

    Just a thought. It would add some cpu cycles to the creation of the file, but often that is outweighed by the benefit of the smaller file.

    Daniel.

    Daniel · Jan 19, 02:35 PM · #

  2. Hey Daniel,
    No special reason – other than ignorance!
    Most of that process was copied from a wiki post on the Magento site, adapted for my particular situation.
    But all the command line stuff is pretty much copy n paste. ;-)

    I was just pleased it actually worked and did the job, but thanks for the added syntax – that’s now documented here with the rest!

    Cheers

    Neil · Jan 19, 07:00 PM · #

Commenting is closed for this article.