10

I have been tasked with migrating one of our sites between servers (two different hosts). Both environments are linux.

The site streams video, so the server is currently filled with media files (images and video). My first thought was that we'd use rsycnc to transfer everything, but I want to be as efficient as possible and do everything as quickly as we can. I figured some of you may have advice on how to speed up the process, or if rsync is even the right choice here.

Thanks in advance. Apologies for my limited knowledge on sysadmin stuff...

EDIT: We're running on a basic LAMP stack (centos) and moving to red hat on rackspace).

user9517
  • 114,104
  • 20
  • 206
  • 289
Ghost Code
  • 103
  • 5
  • 1
    Define "efficient" in this context. Fast, reliable, robust, or what? And no, you can't have all those. – John Gardeniers Jan 06 '13 at 04:28
  • 1
    rsync is almost certainly the best choice for migrating the data; there is still the configuration and possible databases etc that others have mentioned that have other better options. – fukawi2 Jan 06 '13 at 04:30

2 Answers2

12

There is a lot involved in "migrating an application from one server to another" -- there's really no way we can answer this comprehensively for all use cases. YOU can answer it pretty comprehensively for your setup though, if you approach it systematically:

  1. Make a list of everything your application needs.
    • Web Server?
    • Database Server?
    • Mail Server?
    • Scripting language (PHP, Ruby/Rails, Perl, something else)?
    • Ancillary programs (ImageMagick, etc.)?
  2. Make a list of important configuration items.
    • IP Address, Netmask, Gateway, etc.
    • DNS Servers
    • Application-specific items (temp directories, etc.)
  3. Take the lists from (1) and (2) and write an outline of the migration.
    This should include things like installing and configuring any software/packages you need, dumping and loading the database, etc.
  4. TEST THE MIGRATION
    Copy everything over just like you would if the server was going to go live, but don't make it live. Stick it on an isolated network when you're done and test everything.
    If you have a standard test procedure for your application you should run it on the migrated server.
  5. If everything didn't go perfectly, goto (3), update (1) and (2) then revise your plan.
  6. When the test migrations go perfectly, do the actual migration.
    Depending on how complex the migration process is this might just mean dropping and reloading a database, or you may want to wipe the machine and do it all from scratch.

When you're done you'll have a checklist for your particular application, in your particular environment. That checklist will probably evolve as you develop the app, but it can serve as a starting point in 3-5 years when you have to migrate again.

Other things to consider include implementing configuration management ala Puppet or Chef.
(If you're going to be "the sysadmin" you should be considering them, otherwise pass them on to the responsible person/team.)

user9517
  • 114,104
  • 20
  • 206
  • 289
voretaq7
  • 79,345
  • 17
  • 128
  • 213
5

Well, you have server configuration and server content to deal with, and it's highly unlikely that the same technique will work for both.

Do you have a database? If so, that will need to be moved as well. Rsync works great for static content. Just run it once to get list of your data moved, and then say every few hours to keep things in sync until cutover. Make sure to disable the rsync cron before migration!

With regards to config, we have no idea what you're running, so can't really give recommendations.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • Thanks! We're currently running on CentOS with an Apache/PHP/MySQL stack (pretty standard) with WHM. We're moving everything over to redhat linux on Rackspace. – Ghost Code Jan 06 '13 at 04:15