Preparing for a Cloud Server Migration

This guide covers some general tasks that can be performed to optimize a server prior to migration or image creation.

General preparation

Some tasks can help control the disk space on the server in general.

Establish a log rotation policy

Large log files can potentially increase the time for a migration or the size of a created image. Application and virtual host logs aren't generally rotated unless you specifically set up rotation for them.

You can use a utility like logrotate to make sure your logs stay at a reasonable size.

Prune and archive old data

Look for archived log files, application cache files, and old tables or entries in databases. The more you can remove the less there will be to copy to the new server.

Ruby on Rails applications in particular can create a large number of session files and never delete them. Before an operation make sure you look into where your apps might store those session and cache files.

For more advice on locating and pruning old session and cache files, see this article about optimizing rsync.

Check for large files

Removing other large files from the server can also cut down on the overall copy time or image size.

You can look for the largest files on your system using the find utility:

sudo find / -mount -type f -ls|sort -rnk7 |head -30|awk '{printf "%10d MB\t%s\n",($7/1024)/1024,$NF}' 

The output will show the largest files on your cloud server so you can determine if any can be deleted or archived elsewhere.

Right before the operation

You can reduce the time required for a migration and improve reliability of a resulting image by taking steps to reduce the number and size of files that might change during the operation.

Force log rotations

Applications that are still running may generate new log entries.

If you force a log rotation beforehand you can ensure that any changes to log files will be relatively small. Most log rotation utilities provide a means of forcing rotations manually.

For example, if you're using logrotate to manage your application logs you can force a rotation with the command:

sudo logrotate -f /etc/logrotate.conf 

Lock databases

Databases that change during the operation could result in lost data or a corrupted database in an image.

It's a lot safer to bring the database down entirely for the operation. If that isn't practical, however, the second-best approach is to make your tables read-only so they won't be written to during the operation.

To lock your tables in mysql run the command:

mysql -u root -p --execute="FLUSH TABLES WITH READ LOCK" 

Flush application caches

Clearing out old, unneeded session and cache files can prevent them from dragging the operation to a crawl. Copying a lot of very small cache or data files can take more time than copying one file of the same total size.

After a migration

When a migration completes and your new server boots you should test your web sites and applications. Make sure applications are responsive and that they can write information to their databases.

If you have any services that need to communicate to other servers, you should explicitly test their connectivity to make sure they still talk to each other.

Further reading

For migrations that use rsync to transfer files, the more detailed advice in this article about optimizing rsync can help.

Was this content helpful?

© 2015 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