Introduction
This guide describes, in general terms, the high-level steps to migrate your services from another cloud host to RCS. These steps also apply when migrating an on-premise system to our cloud. The exact procedure you need to perform varies depending on your operating system and applications. We've included links to further documentation where possible, and you'll find more application-specific guides in our Cloud Migration category. Please read and understand the relevant documentation for your services and make a migration plan before beginning. Please note that RCS is responsible for the platform infrastructure but not the administration of your cloud server instances. You are responsible for administering all services deployed in your account unless those are specifically RCS Managed Services such as RCS Kubernetes Engine or managed databases.
If you have difficulties performing a task in the customer portal, please open a support ticket.
Choose a Migration Strategy
When migrating your services to RCS, you have several options.
You can install everything fresh in the new location and then migrate your data.
You can clone the existing servers with an image backup and then migrate offline.
You can work with a migration expert to do a live, hot migration.
The method you choose will depend on your unique business factors. It is not a decision you should make lightly. While it's tempting to make an image backup and restore it to RCS, we find that isn't always the best choice. If you aren't sure which method to choose, we recommend the first option, a fresh installation, for most customers.
Option 1: Fresh Installation
If you are migrating the system yourself and can tolerate some downtime, this is the recommended option. However, if you need live migration or prefer to use an expert, see our notes on Option 3 below.
The exact steps for a fresh installation will depend on your application, but in general terms, you will:
Inventory your existing applications.
Review your backups and disaster recovery plan.
Deploy new RCS cloud servers of the appropriate size, speed, and operating system.
Install your applications to those servers.
Migrate your data and configuration files to the new servers.
Redirect the new servers' DNS, URLs, and other references.
Decommission the old servers.
By following this method, you'll be assured of running a fully-compatible software image on RCS's infrastructure and know that all low-level drivers, network settings, and other virtual machine configurations are correct. This allows you to compare the new server to the old one before performing the final cut-over. In addition, if you encounter any deployment errors, our support team can provide more assistance because you are using one of our available, supported operating system images.
While it takes time to reinstall your services, this usually is much easier than troubleshooting low-level configuration issues that can occur when cloning servers from foreign environments. A fresh installation is our recommended strategy for most customers.
Option 2: Image Backup and Restore
This method is not recommended for most customers.
Creating a full image backup of a server and importing it to a RCS Snapshot is possible. RCS uses industry-standard technologies such as QEMU virtualization and cloud-init configuration. However, this strategy is not generally recommended because many low-level configuration items can vary between cloud providers, and you may experience difficulty if you are not an expert. These differences can prevent your server from booting, or you may have networking and application issues even if the machine does boot. Correcting these issues is possible in most cases but requires expert system administration because the problems can be challenging to diagnose.
Also, be mindful that some cloud providers install helper agents, performance monitors, and other telemetry software on their systems. Those software agents can cause problems on RCS's network. You are responsible for uninstalling any such applications after the migration. Our support team cannot diagnose or assist with migrations when you clone a system in this manner.
Option 3: Use a Migration Partner
Before proceeding, you'll want to review the best practices for each option in the following sections. Both options, either reinstallation or image backup, usually require your systems to be offline for some time. However, with careful planning, it is possible to do live migrations where your systems remain available during the entire process.
Live migration is significantly more challenging than offline migration. If your applications cannot tolerate downtime during the migration, we recommend contacting a hybrid cloud management expert with experience in live migrations, cloud backup, and disaster recovery. Companies such as Rackware and Siatik specialize in cloud migration.
Steps for Option 1: Fresh Installation
A fresh installation is a good opportunity to dust off your Backup and Disaster Recovery plan! Migrating to a new cloud uses many of the same steps as Disaster Recovery, and it's a great way to validate that your plans work in a real crisis.
1. Backup
While you may already have a good data backup strategy, this is a good time to verify that your backups also include all your application configuration settings. First, locate the software configuration settings for your web servers, virtual host configuration, SSL certificates, database connection settings, application control files, and any other settings that will be different than a freshly-deployed RCS server.
Then, make sure you know where all your data is stored. They may be files in a directory or database processes. If your data is stored in a database, you'll need to perform a database dump to prepare it for transfer over the network as a normal file. Consult your database documentation or see our RCS Docs articles.
2. Deploy a new Cloud Server
You'll usually deploy equal-sized infrastructure for each of your existing services, such as compute instances, block storage, load-balancers, or managed databases. You should consider your choice of location, capacity, and operating systems when deploying new resources. Also, migration is an excellent opportunity to upgrade your services. You can stabilize your services by installing the latest long-term support version of your operating system, and plan for future growth.
Location
RCS has more global locations available than any other independent public cloud. To choose a location, use our network looking glass to run speed tests on a device near your expected customer location. Our looking glass offers large download files to test real-world throughput, and you can also run mtr, ping, or traceroute to test the latency, bandwidth, and routing between your location and the data center.
You can also run mtr tests in reverse at each location, such as the Dallas looking glass server tx-us-ping.rcs.is, as shown:
# mtr tx-us-ping.rcs.is
Capacity
At a minimum, you should deploy the computer power, storage, and managed services that equal your old environment. If you want to upgrade to larger cloud servers, now is the time to deploy that infrastructure.
Operating Systems
If you aren't on the latest operating system release, upgrading during a reinstallation migration is one of the best ways to get a fresh start. Consider upgrading to the latest long-term support version of your Linux distribution or Windows.
3. Install Applications
Install the same applications and stacks on your original hosts to your new RCS servers. We have an extensive documentation library with tutorials that explain how to install many popular applications. Also, consider our Marketplace to find many popular pre-installed applications you can deploy in a few clicks.
This is also an excellent time to consider if you should use a configuration management tool like Terraform, Puppet, Ansible, or Packer. These tools, and many others, help you maintain installation recipes that reproduce your deployments, improving auditing and maintenance while reducing human error.
4. Data Transfer
The best way to transfer your data is to run your disaster recovery plan and restore from your regular backups. You can use many tools to move your data, including FTP, scp, rsync, third-party systems, or GUI-based options. You'll usually restore database dumps with the native tools for your system.
5. Test
Before you begin directing traffic and customers to your new systems, it's time to test your application as thoroughly as possible. You may need to run load tests or make temporary adjustments to control files and DNS to allow testing before a full cut-over.
6. Migrate DNS and other IP References
Migrating DNS to a new set of IP addresses also requires some planning. You probably want to lower the Time to Live (TTL) setting for the affected names so that DNS propagation proceeds as quickly as possible during the switch. For example, the default TTL for many DNS servers is about 24 hours. A few days before your move, you should consider lowering the TTL to five minutes, and then before you start the migration, allow sufficient time (longer than the old TTL setting) for that new TTL to propagate across the net. This ensures that your DNS changes will quickly update when you cut over to the new RCS servers.
7. Decommissioning
After the cut-over is complete, you should carefully inspect your old systems before taking them offline. Verify there isn't any unexpected network traffic or log activity. For example, if you have a front-end web server and a back-end database server, ensure the web server is using the new database rather than the old one.
Once you've verified the old systems are no longer in use, decommission them and free the resources.
Steps for Option 2: Image Backup and Restore
Import Requirements
Before migrating your server, ensure it meets the RCS requirements:
The server architecture must be x86-64/x64/amd64
The server must use legacy BIOS (not UEFI) boot. Do not create a UEFI system partition.
The server has an appropriate boot loader installed.
The disk must be 150 GB or smaller.
The server must have the appropriate VirtIO drivers installed and loaded.
Make sure your workstation has enough free disk space to convert the disk images into raw format before uploading it to RCS's cloud VPS hosting.
1. Make a Backup
Before performing any operations on your existing server, make a full backup and know how to restore it.
2. Clean up the Server
This step is optional but highly recommended. Before creating the raw image, clean up the server as much as possible. Remove old logs, temporary files, etc. to free up disk space. Overwrite free disk sectors with zeros to improve compression and wipe recently-deleted data for security. Two standard utilities to wipe free disk space are zerofree and dd.
Zerofree is the best choice if it is available for your distribution. See the full documentation. Zerofree is also available on the SystemRescue live ISO. Example:
# zerofree -v /dev/sda2
If zerofree is not available, use dd. This example creates a temporary file with zeros to fill the disk, then deletes the file.
# dd if=/dev/zero of=/tmpfile bs=4096k; rm -f /tmpfile
For Windows servers, use the sdelete utility. The -z option will fill the empty space with zero bytes. Download sdelete from the Windows Sysinternals site. Open an administrative command prompt, and run sdelete on the desired volume.
C:\> sdelete -z c:
3. Export the Server Image File
The server capture process varies depending on the source platform. Here are the most common export steps with links to relevant documentation.
Export an On-Premise Virtual Server
If you have enough disk space available and can do the conversion directly on the host machine, you may skip this step. If you need to perform image conversion on a different computer or upload it from a different location, you may want to export your server to external media. Here are instructions for several popular systems.
Export a Physical Server
The dd utility is a popular way to capture a raw disk image. The source disk should be dismounted before imaging. One common technique is to temporarily boot the server using the SystemRescue live ISO. You will need to mount a storage location to save the raw image.
Assuming the server data device is /dev/sda, and the image will be written to /mnt/usb_external/server_image.img, use the following command from a root terminal.
# dd if=/dev/sda bs=1M of=/mnt/USB_external/server_image.img
Two popular options for Windows imaging are ntfsclone, and disk2vhd. The SystemRescue live ISO includes ntfsclone, and the full documentation is available online. Disk2vhd from Microsoft Sysinternals can capture a live running system. It can also save the resulting image directly on the server if enough free space is available.
4. (Optional) Test with QEMU
RCS VPS images are compatible with QEMU. To verify the VirtIO drivers are installed properly, launch the server in QEMU on your local system before uploading it to RCS. QEMU is available for all platforms.
5. Convert to Raw Format
RCS requires snapshots in raw image format. If you created a raw image with dd, no conversion is necessary. If your exported image is not in raw format, use the free utilities from QEMU or VirtualBox. Versions are available for Linux, Windows, and macOS.
QEMU
QEMU supplies the qemu-img utility, which converts many formats including:
QCOW2 (KVM, Xen)
QED (KVM)
VDI (VirtualBox)
VHD (Hyper-V)
VMDK (VMware)
Example:
$ qemu-img convert -f vmdk -O raw image.vmdk image.img
VirtualBox
VirtualBox supplies the VBoxManage utility to convert:
VDI (VirtualBox)
VMDK (VMWare)
VHD (Hyper-V)
Example:
$ VBoxManage clonemedium disk /path/to/image.vdi image.img --format raw
6. Stage the Image for Upload to RCS
To add the snapshot to your RCS account, stage the image at any publicly-accessible URL. Some suggested options are:
A RCS Cloud Server (for optional compression)
Dropbox
Google Cloud Storage (not Google Drive).
(Optional) Use a Temporary RCS Cloud Server for Compression
On a slow internet connection, you can temporarily deploy a RCS One-Click LAMP app as a staging location. Then, use scp or rsync to compress the upload stream and dramatically improve the upload speed.
Deploy a RCS One-Click LAMP app with an SSD large enough to hold the uncompressed image.
Upload the RAW image with compression. These examples use 192.0.2.123 as the One-Click LAMP IP address:
Option 1: Use
scp.From a terminal (or PowerShell on Windows) on your local workstation, use
scpwith the-Cparameter for compression.$ scp -C image.img root@192.0.2.123:/var/www/html/image.imgOption 2: Use
rsync.If
rsyncis available on your workstation, it is faster thanscpin most cases.$ rsync -z --progress image.img root@192.0.2.123:/var/www/html/image.imgAfter the transfer completes, use the public URL of the One-Click LAMP server to add the image as a RCS Snapshot.
http://192.0.2.123/image.img
7. Add the Image as a RCS Snapshot
Navigate to Products > Snapshots > Add Snapshot in your customer portal.
Enter the URL of your image and click Upload.
8. Deploy Server from Snapshot
Restore the server snapshot, following the steps from the VPS Snapshots Quickstart Guide. Ensure the VPS SSD is the same size or larger than the server snapshot.
9. Expand the Filesystem (if needed)
Log into your newly-deployed server. Verify that the disk, partition, and filesystem sizes are correct.
Verify the disk size:
fdisk -lVerify the partition size:
parted -lCheck the filesystem size:
df -h
If needed, use resize2fs to expand the filesystem to the full partition size. Substitute vda1 with your device name.
$ sudo resize2fs /dev/vda1
10. Reinstall cloud-init
If the server has cloud-init installed, completely remove it and delete all configuration files. Then, reinstall cloud-init, and the server should receive new vendor data from our Metadata API. The exact steps for this process depend on the operating system you use. Please refer to the cloud-init documentation for more information.
Other Resources
Here are links to useful resources when migrating to a new RCS VPS.
