Migrating your data to a Performance Cloud Server from a standard Cloud Server can be a straightforward process with some planning and preparation.
For detailed advice on preparing a server for a smooth migration, please see the recommendations in this article on migration preparation. In particular, you can reduce the amount of data to be migrated by cleaning out old installers, rotating logs, and removing old cache and session files.
You can also find a good list of items to keep in mind before migrating in this Before You Move to Performance Cloud Servers checklist.
If you do plan to remove files from your server to help a migration go more quickly, we strongly recommend making a backup first to ensure that no essential data is inadvertently lost.
A server image can only be restored to the system disk of a Performance server (and similarly, images can only be taken of the system disk of a Performance server, not of any data disks attached).
Image-based migration to a Performance server will not be possible for standard servers with more than 1GB of memory due to the larger disk allotment on those servers. Some 1GB and smaller servers may also be ineligible for image migration (if a server has been resized in the past it can affect an image's minimum disk size requirement, for example). First-generation server images cannot be used to create a Performance server.
Images are restricted to the region in which they were created. Performance servers can only be created in the IAD, ORD, DFW, and LON regions at this time. Support for other regions will be added in the first half of 2014.
The simplest way to find out if you can migrate in this fashion is to try it out. Make an image of your server (you can use the steps in this article for guidance) then try restoring it to a new server. You won't have the option of creating a Performance server if the image size is too large for a Performance server system disk.
If an image-based migration will work, that's the easiest approach you can take. For a reliable migration we recommend stopping any running applications before creating the image you'll restore to the new server.
If you were able to use an image to migrate you're all set. If you're unable to use image-based migration, read on to prepare for a manual migration of your data.
To determine the minimum disk space you need on the new server, check how much disk space you're currently using.
To check disk space used on Linux, run:
To check disk space used on Windows, check the properties for the C: drive.
If you require more space than is provided by the system disk, you will need to use data disks or Cloud Block Storage volumes on the new server to accommodate all of your data.
When setting up data disks or Cloud Block Storage volumes, you should check the sizes of the directories on your origin server. This information can help you plan your data's organization on the new server - what will go on the system disk, and what will be stored on the additional volumes.
On Linux, you can determine the disk space used by files and directories in the current directory by running:
du -hs *
You can also specify a directory or file name, as in:
du -hs directoryname
On Windows, right-click the directory you wish to check and select Properties.
Once you know which data will be copied to your system disk and which will be copied to an attached disk, plan the size of the new server and its additional volumes (if any) accordingly.
When creating the destination server, keep your storage requirements in mind as well as memory, CPU, and network requirements.
If you have more data than will fit on the new server's system disk, you'll need to decide where you want to store the additional data. The flavor of server you've selected might include one or more data disks. You can also attach Cloud Block Storage volumes to the server.
When choosing the size of your server, consider your current needs and any scaling you might need to do in the future.
Performance servers can't be resized, so adding and removing storage space via Cloud Block Storage are the only changes you can make to their capabilities. For a single-server environment, you will need to migrate to a new server if your RAM or CPU requirements change.
Alternately, you might plan your environment to use horizontal scaling - where more than one server runs your application, with a load balancer in front managing traffic to the different servers. Horizontal scaling may not work with all applications, but once set up it makes it easy to add or remove servers to account for fluctuating load requirements.
Some example environments can be found in our article on open cloud reference architectures.
Note that you can't take a snapshot of a Performance server data disk, so to back up data disks you will need to rely on Rackspace Cloud Backup or a similar file-based backup approach. If you want your additional storage to be more portable or need to be able to take data snapshots, consider adding one or more Cloud Block Storage volumes to the new server.
With your server created, prepare any attached data disks or Cloud Block Storage volumes by formatting them and configuring the system to use them.
If you've attached Cloud Block Storage volumes, see this article for instructions on preparing those volumes.
For instructions on formatting and mounting data disks on Performance servers, see the appropriate article for your server's operating system:
If you are setting up attached volumes in a software RAID on Linux, see the Linux Software RAID HOWTO for instructions.
With your attached disks ready to go, it's time to migrate your data.
You have several options for a manual migration, including Rackspace Cloud Backup, Rackspace Cloud Block Storage, or rsync on Linux, and Web Deploy or the Web Farm Framework on Windows.
To use Cloud Backup to migrate particular directories, take a backup of your data from the origin server then restore it to the destination server.
To migrate specific data using Cloud Block Storage, attach the drive to your origin server first and copy your data to it. Next detach the server, attach it to the destination server, and copy your data from the drive.
On Linux you can use rsync to copy a directory over the network directly. For example, from the origin server you can run the following to copy /var/lib/mysql:
rsync -e 'ssh' -avl --stats --progress /var/lib/mysql firstname.lastname@example.org:/var/lib/mysql
For more details on rsync, see this article.
If you want to migrate the entirety of a Linux server to a new Performance server, you can follow the directions in this article series detailing a full rsync-based migration.
To migrate IIS and MSSQL data on Windows 2008, you can use Microsoft's Web Farm Framework per the instructions in this article.
To migrate IIS and MSSQL data on Windows 2012, you can use Microsoft's Web Deploy tool per the instructions in this Rackspace Community post.
Other applications may have their own means of facilitating data migration. For example, to migrate a database you could make the new server a slave of the original database to automatically replicate your data to the new server.
Once all your data is on the new server, make sure you test your application thoroughly to make sure it works as expected in the new environment.
If you haven't already, put a backup plan in place to prevent significant data loss in the event of a catastrophe.
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License