Best Practices when Migrating to Linode
Traducciones al EspañolEstamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
This guide describes the recommended strategy for migrating your services from another host to Linode. The specific steps you need to carry out vary depending on the software you use. However, the high-level outline is generally the same regardless of the nature of your service. The Migrate to Linode section offers other guides which describe migrating particular services in more detail.
Deciding on a Migration Strategy
There are two general strategies for migrating from another hosting provider:
Install Each Service Individually - Recommended Method
Create a Linode, deploy a Linode-provided Linux image to it, and copy over only the configuration and data relevant to your services. This results in a Linux environment that is guaranteed to boot normally on the Linode platform.
Re-installing your services can take time. However, any issues that come up when setting up your applications are usually easier to troubleshoot than low-level configuration problems. This is the recommended strategy when migrating.
Full Clone - Not Recommended
Create a Linode and perform a full clone of your existing disks from your current host to the Linode. This creates an exact copy of your disks on the Linode platform. This strategy is not recommended because low-level system configuration files can be different on different hosting providers.
These differences can prevent your Linode from booting normally. It is possible to adjust these settings sufficiently to allow your Linode to run normally. However, getting the right values for these settings can be difficult, and it can be difficult to troubleshoot when they are incorrect.
Migration Strategy Outline
Deploy a New Linode
There are two considerations when creating a new Linode: which data center the Linode should reside in, and which hardware resource plan the Linode should run under.
Data Center Location
To choose a data center location, run speed tests to the different regions that Linode offers from the speedtest page. This page allows you to download a 100MB file from each location. Compare the speed of each download to determine the bandwidth between your location and the data center.
You can also run MTR tests to the speed test servers at each location (e.g.
speedtest.dallas.linode.com). These tests report latency between your location and the data center–a lower latency is more desirable.
To determine which plan to choose, review the Linode Pricing page. At a minimum, choose a plan which offers enough storage capacity for the data you store on your current hosting provider.
CPU and RAM allocations are also important since a service with a higher workload/higher traffic requires more of each. If you’re not sure what your workload requires, start with a smaller Linode and then resize your plan up or down as needed.
If you know which Linux distribution your current host uses, deploy that to the new Linode. If your current deployment uses an older version of a Linux distribution, deploy the newest version available for your new Linode. This ensures the latest security enhancements and software availability.
If your host offers a shared environment and you are not sure which Linux distribution is being used, then you can select any new Linux image. The most commonly used distributions on Linode are Ubuntu, Debian, and CentOS. Most Linux distributions should support the software your service uses, but a few software packages are better-suited to specific distributions. Review Linode’s Guides & Tutorials to see which guides have been written for the software and distributions you’re interested in.
For further details on deploying your new Linux image, follow the Getting Started with Linode guide. It is also recommended that you follow the Setting Up and Securing a Compute Instance guide once you have deployed your new image.
Install the same software stack that is present on your current host on your new Linode. For guidance on how to set up different kinds of software, review Linode’s Guides & Tutorials.
If your host provides a shared environment and you’re not sure which software is needed, ask your host if they can provide more information about the software they run. For example, WordPress sites are powered by PHP, a web server, and a database, so installing a LAMP stack would be sufficient.
Back up Your Data
Locate and backup the data on your current host. Identify:
Which software configuration settings should be preserved (e.g. web server, virtual host information, database connection settings, and which files contain these settings, etc.).
Where your data is stored on disk (e.g. as files in a directory, in a database process, etc.).
If your data is stored in a database, you likely need to perform a database dump. This results in a file on disk that encapsulates your database data and can be copied over the network as a normal file:
- Use mysqldump to Back Up MySQL or MariaDB
- Create Physical Backups of your MariaDB or MySQL Databases
- Use postgres dump database
If your current host is a shared environment and you do not have full administrative/command-line access to it, then your host may offer an alternative method for exporting your data. If this is the case, then you should use those tools to download the data to your local computer or some other accessible location.
Use rsync to Transfer Your Data to Your Linode
Transfer your data to your Linode using a network transfer tool like
rsync. The Introduction to rsync guide is a good place to become more familiar with this tool.
For example, the following command uploads files from
/path/to/source_folderon the current host to
/path/to/destination_folderon the new Linode. Run this command from your current host. Replace
example_userwith the Linux user on your Linode, and
linode_ip_addresswith your Linode’s IP address:
rsync -avzh /path/to/source_folder example_user@linode_ip_address:/path/to/destination_folder
If your current host is a shared environment and you previously downloaded your data to your computer, then you should upload the data from your computer to your Linode. You can use an SFTP tool like FileZilla, which has clients available for Windows, Mac, and Linux.
If you have uploaded a database dump file to your new Linode, you also need to restore the dump file so that your database software can use the data normally. The database guides linked to in the Back up Your Data section include instructions for restoring those files.
Test the New Environment
When you have finished setting up your software and restoring your data, test the installation to make sure it works normally. At this point, you have not yet updated DNS records to point to your Linode deployment, but there are still methods for previewing your services without DNS.
Take this time to perform load testing on your new service. ApacheBench is a popular benchmarking tool for web services. If you discover that the hardware resource plan you chose originally is not enough when completing these load tests, then resize your plan and continue testing.
When you have finished testing, move on to the last step in migrating: updating your DNS records.
Migrating DNS Records
To direct your visitors to your Linode, associate your domain with your new Linode’s IP. There are two options for moving your DNS records:
Use Linode’s fast, stable DNS hosting which is free as long as you have one active Linode on your account.
Continue to use your current nameserver authority and update your DNS records with your new Linode’s IP address. You should check with your current provider to see if there are any costs for their DNS services. If you are using your domain name registrar’s nameservers, then they are generally free.
(Optional) Prepare Your Domain Name to Move
A recommended first step is to lower the Time to Live (TTL) setting for your domain so that the migration won’t have a negative impact on your site’s visitors. TTL tells DNS caching servers how long to save information about your domain. Because DNS addresses don’t often change server IP addresses, default TTL is typically about 24 hours.
When changing servers, however, make the TTL shorter to make sure that when you update your domain information, it takes effect quickly. Otherwise, your domain could resolve to your old server’s IP address for up to 24 hours.
Locate your current nameservers. If you’re not sure what your nameservers are, use a Whois Search tool. You will see several nameservers listed, probably all at the same company.
You can usually derive the website of your nameserver authority (the organization that manages your DNS) from the nameservers you find in the Whois report (e.g.
linode.com). Sometimes the labeling for the nameservers is not directly related to the organization’s website, and in those cases you can often find the website by plugging the nameserver into a Google search.
Contact your nameserver authority for details on how to shorten the TTL for your domain. Every provider is a little different, so you may have to ask for instructions.
Most nameserver authorities will allow you to set the TTL on your domain or on individual records, but some do not allow this setting to be edited. Here are support documents from some common authorities that mention how they manage TTL:
Make a note of your current TTL. It will be listed in seconds, so you need to divide by 3600 to get the number of hours (e.g. 86,400 seconds = 24 hours). This is the amount of time that you need to wait between now and when you actually move your domain.
Adjust your TTL to its shortest setting. For example, 300 seconds is equal to 5 minutes, so that’s a good choice if it’s available.
Wait out the original TTL from Step 3 before actually moving your domain–otherwise, DNS caching servers will not know of the new, lower TTL yet.
Use Linode’s Nameservers
Follow Linode’s instructions on adding a domain zone to create DNS records at Linode for your domain. Recreate the DNS records listed in your current nameserver authority’s website, but change the IP addresses to reflect your Linode IPs where appropriate.
Locate your domain’s registrar, which is the company you purchased your domain from. If you’re not sure who your registrar is, you can find out with a Whois Search tool.
Your registrar may not be the same organization as your current nameserver authority, though they often are, as registrars generally offer free DNS services.
Log in to your domain registrar’s control panel and update the authoritative nameservers to be Linode’s nameservers:
Wait the amount of time you set for your TTL for the domain to propagate. If you did not shorten your TTL, this may take up to 48 hours.
Navigate to your domain in a web browser. It should now show the website from Linode, rather than your old host. If you can’t tell the difference, use the DIG utility. It should show the IP address for your Linode.
Set reverse DNS for your domain. This is especially important if you are running a mail server.
NoteIf you’re having trouble seeing your site at the new IP address, try visiting it in a different browser or in a private browsing session. Sometimes your browser will cache old DNS data, even if it has updated everywhere else.
Alternative: Use Your Current Nameservers
If you’d like to continue with your current nameservers, update all of the DNS records that are assigned to your old host’s IP address to use your new Linode’s IP. Contact your nameserver authority for instructions on how to update your DNS records.
The following support documents describe how to update DNS records at common nameserver authorities:
After DNS propagation has finished, set reverse DNS for your domain. This is especially important if you are running a mail server.
After completing the steps above, your service should be fully migrated to Linode. It is a good idea to wait a few days before cancelling your shared hosting service to make sure that everything is running smoothly. Also, be sure to confirm that you don’t need to obtain more files from your shared host.
This page was originally published on