Bobcares

Clone your Vultr server – Here’s the safest method you should follow

by | Feb 1, 2019

At times, you should come across the need to clone your Vultr server.

It can be to create a pre-release environment, perform stress tests, scaling purpose, change server location, and more.

Unfortunately, there is no one click option to clone your Vultr server. It takes a series of steps to clone your Vultr server without data loss.

At Bobcares we help server owners to safely clone their Vultr Cloud Compute as part of our Managed Cloud Services.

Today, we’ll discuss the steps to clone Vultr server and the important points to be kept in mind during this process.

How do we clone a Vultr server?

Cloning is actually the process of creating an exact replica of your live server. And, a wrong step during this process can break the cloned Vultr Cloud Compute. So, the sequence of cloning is really important here.

Now, let’s see how our Support Engineers create a clone of the Vultr Cloud Compute without any data loss.

 

1) Take a snapshot of the original Vultr instance

The first and most important step is to take a snapshot of the Vultr Cloud Compute. Snapshot is actually the complete image of your server. We take the snapshot from Snapshots > Take Snapshot in the Vultr account control panel. The snapshot creation time depends on the size of the instance.

 

vultr clone server

How to take a snapshot of Vultr instance?

 

Data is continuously written to databases and files on a live server. Therefore, taking a snapshot of the live server can cause file system and database inconsistency. So before taking the snapshot, Vultr moves the server to a locked state so that no changes can be made on the server during this process.

But as a precaution, our Support Experts always power off the Vultr Cloud Compute instance before taking the snapshot. This guarantees that there are no data modifications happen at that time.

 

2) Create a new instance

The next step is to create a new Vultr instance that will act as the clone of the original Vultr server. We create a new instance from Servers > Deploy new server(+ symbol) in Vultr account control panel.

 

vultr clone server

How to create a new Vultr server?

 

Most importantly, we ensure that the disk space and the other resources of the new instance should be same or larger than the original Vultr instance.

 

3) Restore the snapshot

Once the new instance is created, we restore the snapshot of the original server to this new instance. This can be done from Servers > Click on the new instance > Snapshots > Restore Snapshot as shown in the below image.

 

vultr clone server

How to restore a Vultr Snapshot?

 

Most important point to keep in mind is that entire data on the server will be overwritten during the restoration of snapshot. So if you’ve multiple Vultr instances, make sure that you’re on the correct instance before restoring the snapshot.

 

4) Update Network configuration

Now, we have an exact replica of the original Vultr instance. But, if we need to use it as a live server, then the network configuration of the cloned server must be modified to reflect the new IP address. In other words, we need to replace the IP address of the old server with the new IP address. Additionally, we need to update the Netmask and Gateway IP addresses in the network configuration file.

For example in CentOS or Fedora servers, we change these parameters in the file /etc/sysconfig/network-scripts/ifcfg-eth0. Similarly in Windows servers, we update the new IP address from Control Panel > Network and Sharing center > Change Adapter Settings > Properties.

 

Vultr clone server – Common problems noticed

The cloning process looks simple. However, based on our experience managing Vultr Cloud Compute instances we’ve seen customers reporting problems during the cloning process.

1) Resource shortage issues

Resource shortage issues on the destination instance can affect the cloning process. In other words, if the target instance doesn’t have enough disk space to hold the snapshot, the cloning process will fail. That’s why our Support Engineers always compare the resources allocated on the origin and destination instances before cloning.

Most importantly, we always recommend the disk space of the destination instance should be same or higher than the size of the original instance.

 

2) Network configuration issues

Similarly, another common problem that can occur is the network adapter configuration issues after a snapshot is restored.

Usually when the network adapter changes, the operating system will create a new network adapter for it. So, the changing MAC address of network adapter can create problems.

In such cases, our Support Engineers login to the cloned instance via console and remove the contents from the file /etc/udev/rules.d/70-persistent-net.rules. After that, we review the network configuration file contents and update the IP addresses to match the new server and finally reboot the server.

 

3) Wrong destination instance

During the cloning process, the entire data on the destination instance will be overwritten with the snapshot contents. We’ve seen instances where users mistakenly select the wrong destination instance to restore the snapshot. As a result, the entire data on this instance become irrecoverable. In such cases, the only option is to restore the overwritten instance from the snapshot.

That’s why, we always double check the destination instance before the cloning process.

 

4) Forgot to update DNS

We see that the cloned Vultr instance has a new IP address. Therefore, for the websites to work from this new instance, we need to update the DNS of the domain to point to the new Vultr instance. However, we’ve seen instances where users missed to point the domain to the new instance. As a result, website throws DNS errors.

In such cases, our Support Experts update the DNS records of the domain to the new Vultr server. In addition to that, we correct the reference of the IP address in the website configuration files as well.

Conclusion

In short, cloning Vultr server is a pretty straightforward process. However, there are some additional factors that need to be checked during this process. Today, we’ve seen how our Support Engineers effectively clone a Vultr server and fix the common problems faced during this process.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

SEE SERVER ADMIN PLANS

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Never again lose customers to poor
server speed! Let us help you.

Privacy Preference Center

Necessary

Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

PHPSESSID - Preserves user session state across page requests.

gdpr[consent_types] - Used to store user consents.

gdpr[allowed_cookies] - Used to store user allowed cookies.

PHPSESSID, gdpr[consent_types], gdpr[allowed_cookies]
PHPSESSID
WHMCSpKDlPzh2chML

Statistics

Statistic cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.

_ga - Preserves user session state across page requests.

_gat - Used by Google Analytics to throttle request rate

_gid - Registers a unique ID that is used to generate statistical data on how you use the website.

smartlookCookie - Used to collect user device and location information of the site visitors to improve the websites User Experience.

_ga, _gat, _gid
_ga, _gat, _gid
smartlookCookie
_clck, _clsk, CLID, ANONCHK, MR, MUID, SM

Marketing

Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.

IDE - Used by Google DoubleClick to register and report the website user's actions after viewing or clicking one of the advertiser's ads with the purpose of measuring the efficacy of an ad and to present targeted ads to the user.

test_cookie - Used to check if the user's browser supports cookies.

1P_JAR - Google cookie. These cookies are used to collect website statistics and track conversion rates.

NID - Registers a unique ID that identifies a returning user's device. The ID is used for serving ads that are most relevant to the user.

DV - Google ad personalisation

_reb2bgeo - The visitor's geographical location

_reb2bloaded - Whether or not the script loaded for the visitor

_reb2bref - The referring URL for the visit

_reb2bsessionID - The visitor's RB2B session ID

_reb2buid - The visitor's RB2B user ID

IDE, test_cookie, 1P_JAR, NID, DV, NID
IDE, test_cookie
1P_JAR, NID, DV
NID
hblid
_reb2bgeo, _reb2bloaded, _reb2bref, _reb2bsessionID, _reb2buid

Security

These are essential site cookies, used by the google reCAPTCHA. These cookies use an unique identifier to verify if a visitor is human or a bot.

SID, APISID, HSID, NID, PREF
SID, APISID, HSID, NID, PREF