Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a dedicated server running ubuntu server 9.04 for web, database and mail. There's about 5 GB of data on the entire hard drive.

I want to migrate the server to a more affordable dedicated server provider but I am unsure how to do this.

  • Can I clone an entire hard drive? What about hardware specific files/dirs?
  • Or maybe there is a saner approach?
  • The future hosting will probably have another version of ubuntu, so should I upgrade our current server before migrating? How about migrating apache, mysql and postfix?
share|improve this question

4 Answers 4

up vote 7 down vote accepted

My suggestion is to take backups of everything and restore it on the new server. Ie:

  1. Dump databases and restore them on the new server
  2. Copy webserver, database, email configs on the new one

Of course it requires a little downtime. There are some things you can do to make the downtime smaller:

  1. Do a previous rsync for all email data, then after everything configured and tested stop the service on the old server, rsync only the new data and start the new server.
  2. Use mysql replication to keep data on both servers until the time to 'switch'
  3. The rsync approach can be used with all other data (even db, but I suggest you to use a dump or replication to minimize the choice of error).

Also remember that this is a procedure that needs to be carefully planned and executed or data loss may happen.

share|improve this answer
1  
This was my initial idea but the problem is that the "settings" are scattered all over the OS. Since it is so easy to forget one data migration step, I'm afraid that the migration will be very cumbersome. –  molidoli Feb 23 '11 at 13:36
1  
GTD :) Create a list of tasks and go one by one. A little brainstorm is really needed. Also, all configurations should be on /etc (it's the FHS and Debian/Ubuntu way) unless you installed things without using packages or proprietary stuff on /opt. –  coredump Feb 23 '11 at 13:51
1  
You just made an argument for my most prized practice. Next time, consider documenting every change you make to a production server on a private wiki. That way you know exactly where and what settings exist and how the server was setup. It may seem like a cumbersome task but its saved me several times. Also great for the company if you leave or get sick. –  iainlbc Feb 23 '11 at 14:11
1  
+1, although #2 is not something to take lightly. And once the new server is up-and-running on the latest LTS release (you may/likely will run into some PHP 5.3 "deprecated" errors that you'll want to clean up if you're hosting a PHP app), just schedule/notify your users of some downtime to do the final rsync and mysqldump. –  gravyface Feb 23 '11 at 14:16
    
@ianlbc It's one of the first practices I implement when I get to a new place. I use dokuwiki for it's simplicity and text based backend. –  coredump Feb 23 '11 at 14:17

If you have found your new provider, have you asked them how they like to do this? You may want to know the details of the from/to environments, including hardware, to pick the best approach.

Also, inquiring about ease of migration and available support may help you choose your new provider!

share|improve this answer
    
The new provider basically told be I have to do this myself and get started with getting services up and running and then migrate the data. Not terribly useful but I understand that the process is pretty complex. –  molidoli Feb 23 '11 at 13:37

You may be interested in exploring the possibility to use FSArchiver, http://www.fsarchiver.org/Main_Page

share|improve this answer

A few relevant things I've learned by trial and error (mostly error):

  • Document the steps as you go so you have a record the next time you do it (there will always be a next time). That way you won't forget any steps and it permits someone else to do it as well.
  • If you can switch components piece by piece it will be easier to diagnose issues. For example, keep the mail/database on the original server and just move the web server to the new server. Skip this if your application cannot easily handle inter-server but it is something to consider if you need to scale your system to multiple servers. This method is particularly useful if you need to minimize downtime.
  • I wouldn't try just copying the raw database files from one server to another unless you are sure the database supports it. If you just have a few 100MB of databases I would just create a dump on the old server and restore on the new one. For larger databases it will be significantly quicker to setup replication.
  • If using rsync or scp to copy files from one server to another make sure the user you use has read permissions for all the files. For example, I once used rsync to copy over some files from /etc but didn't have read permissions for some files. By the time I found out some files were missing it was too late (the old server was wiped). Since then I have always used tar as root on the old server to backup directories and then rsync/scp the tar archive over.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.