Migrating A Linux Server from the Command Line - Scripted


Script-assisted syncing

If you’re looking for an easier approach to migrating your Linux server, we have a script that can be run from the command line that automates some of the work surrounding the syncing of your data to a new instance.

You’ll still want to run through the preparation steps in our article on getting ready for a migration before running the script. If you’re uncomfortable with the thought of leaving the sync to a script, you can use our article on a manual migration using rsync instead.

As mentioned in our preparatory article, you’ll want to make sure you have rsync installed on both your source and target servers and that you can run the migration script either as the root user or using sudo.

Before running the script

Before using the migration script you’ll want to set up the screen program, consider whether to create an extra excludes file for the script to use, and download the script itself.

Screen

We recommend that you install screen on the source server so that you can maintain a persistent session during this potentially long process.

If you don’t have screen installed, the package name should be “screen” in most distributions. Use your package manager to perform the installation.

Screen is a pretty versatile program, but we’ll just use a couple simple features for now.

Launch a screen session with the command:

screen -S OCSMigration

If you get disconnected you can run this command to resume the session after logging back in:

screen -r

Excludes

If you have extra files you want to exclude from the sync (the script’s exclude list already excludes most system files), you can create an addition exclude list in the file:

/tmp/excludeme.file

You can view the default excludes in the script itself toward the top, in the “EXCLUDELIST” variable.

Notes for RackConnect Users

If you are migrating a RackConnected instance to a new instance that will also be RackConnected, I would advise you exclude the "/etc/passwd" file, "/etc/group/" file as well as the "/etc/shadow" file. While this is not 100% necessary, some users have reported issues upon completion of the migration due to the system created users when the automation was originally done for the "source" instance. Including the files to be excluded is easy, the simplest method is to add the lines into "/tmp/excludeme.file". To accomplish this, you could edit the file manually with something like "vi" or "nano", or you could echo the lines into the file with a single command. Here is how I would do it.

echo -e '/etc/passwd\n/etc/shadow\n/etc/group' >> /tmp/excludeme.file

Another way you could accomplish the same thing would be to add the three files to the exclude line at the top of the script, in the general exclude area. If you will be running the script multiple times on multiple RackConnected instances adding the files into the general exclude line would simplify the process on subsequent uses.

Getting the script

Now you’ll need to download the script itself and run it from your source server (the server that contains the data you want to import to your Cloud Server). You can find it at this url:

https://github.com/cloudnull/InstanceSync/blob/master/rsrsyncLive.sh

To download the script you can use git, you can go to the github site and download the tar ball, or use any other method you choose. Here is how to get the script using git

In order to get this script using Git you will need to have Git installed.you can get Git from here. Once you have git installed, here is how you will get the repository.

git clone https://github.com/cloudnull/InstanceSync.git

This will create a new directory where the previous Git command was executed. From here you will need to enter the directory.

cd InstanceSync

Running the script

To run the script you will need to make it executable or call a bash shell before the script.

For simplicities sake we’ll just run the script using bash:

sudo bash ./rsrsyncLive.sh

Once the script starts please read the instructions it displays. Failure to do so could result in a migration failure.

What the script does

Once the script has been started it will prompt you for the IP address of the target server. The script will then ask you what directories you are wanting to migrate over.

If you are simply moving the entire server from one place to another you can press “Enter” and the script will make the assumption that the entire source server will be migrated; the script will use “/” as the directory to be migrated. If you would like to only move a certain source directory you can specify it at this time, but If you specify anything in this field you will also need to specify the target directory too.

Next the script will attempt a connection as the ROOT user to the target server. After you’ve authenticated the script will attempt to setup key-based authentication from the source server to the target server. This is all done on standard ports using the ROOT user, so if you’re running sshd on a non-standard port on the destination server you may need to either temporarily reset the config on the target server to use port 22 or adjust the scp lines in the script accordingly.

On the source server, by contrast, you don’t have to worry about the ssh server config. The script only makes outgoing connections from the source server to the target server, not the other way around.

The script will verify the rsync installation on both servers. Then it will run rsync twice - once for the main sync, then a second time to catch any files that may have changed during the first sync. When the sync is complete the target server will be rebooted.

Sync complete

Once the target server comes back online, log into it and check to make sure everything is running as expected. Remember that your accounts and passwords will have been synced by default, so log into the new server using your old password.

Note that you might need to delete any saved key for the new server from the “~/.ssh/known_hosts” file or equivalent on your desktop’s operating system. Otherwise you could get a warning about a changed server key or you might be prevented from connecting at all.

When you’re content that the new server is operating as it should, make sure you change any external settings accordingly. Remember to change any DNS information to point to the new server, and also don’t forget to make new backup arrangements for the new server. If you have other servers that made connections to the old server make sure they’re updated to point to the new server instead.



Was this content helpful?




© 2014 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License


See license specifics and DISCLAIMER