Rackspace Cloud to Rackspace OpenStack Flex Migration

This guide focuses specifically on the migration of Rackspace Public Cloud to Rackspace OpenStack Flex. If you are migrating to Rackspace OpenStack Flex from another platform please refer to our more holistic migration related document on Planning a Migration to Rackspace OpenStack Flex

Prerequesites

• A User, Credentials, and Access to a Rackspace Cloud Account
• A Rackspace OpenStack Flex Account

Understanding the Differences Between the Platforms

Despite both platforms being Rackspace managed and developed, based on OpenStack, and multi-tenant public clouds there are some major differences. To get an understanding of the differences between these two platforms, the parity in products and services, and more - check our article here that gives an in-depth comparison: Rackspace OpenStack Flex vs Rackspace Cloud

Migration Options Currently Available

Currently there is no seamless and automated way to turn a Rackspace Cloud server into a Rackspace OpenStack Flex server. The only paths currently available rely on data based migrations from one VM to another VM.

Data Migration Approaches

Because you'll be migrating into the Rackspace OpenStack Flex ecosystem you may need to rely on file-based migration methods. Below is a list of a few common data migration options:

• rsync over SSH: Good for structured, incremental transfers.
• SCP/SFTP: Simple, but not ideal for very large data sets.
• Compressed Archives (tar, zip): Good for packaging and reducing transfer size.
• Database dumps: Use tools like mysqldump, pg_dump, then transfer and restore.

NOTE: If source and destination VMs are not routable to each other, consider transferring data through your local workstation or using a cloud storage service (if allowed by your organization).

Cloud Backup Migration Method

The Cloud Backup tool was designed for use in Rackspace OpenStack Public Cloud - but it can also be installed on another server like a Rackspace OpenStack Flex server. You simply need to perform the following steps:

Step 1 - Install and Configuring the Backup Agent on a Rackspace OpenStack Flex server with your Rackspace Cloud username/API key. The below steps should be valid for Debian and Ubuntu servers. Be sure to replace $USERNAME, $APIKEY, and $REGION with your own values.

sudo apt-get update

sudo apt-get install bzip2 nscd

sudo wget https://agentrepo.drivesrvr.com/updater/cloudbackup-updater-latest.tar.bz2

cd cloudbackup-updater-2.9.010598/

sudo ./cloudbackup-updater --configure --user $USERNAME --apikey $APIKEY --flavor dedicated --datacenter $REGION

sudo systemctl enable driveclient

NOTE: The version for the cloudbackup-updater may change, so your folder may have a different name.

Step 2 - After running through the above steps on your server, you'll see a new Cloud Backup System listed in the Rackspace Portal that displays your Rackspace OpenStack Flex server.

Step 3 - You can now restore backups taken of your Rackspace Cloud server to your Rackspace OpenStack Flex server. This guide will walk you through the restore process for Cloud Backup

IMPORTANT! Be aware that restoring all of your servers files and overwriting everything on your destination server will result in a broken server. This is because you are overwriting many important networking and system files which are specific to the server. Best practice is to only move the critical application or other files that are unrelated to the underlying server's operating system and configuration.

NOTE: You can also configure backups for your OpenStack Flex server using the Cloud Backup agent. The data will be stored in Rackspace Cloud Files just as it would be for an OSPC server and can even be used to restore data back to a Rackspace Cloud VM or to another OpenStack Flex server.

Closing Tips

• Test the process with a non-critical servers or smaller workloads first. Once you understand the process and have determined a workflow that is comfortable and repeatable - attempt on more important servers.
• Try building out and migrating to a development environment first.
• Do NOT delete resources on your source platform until you've successfully moved and tested on the destination.
• Additional migration options may be made available in the future.