When running tests or pushing updates or patches to your virtual machine, it’s good to have reassurance that any changes you make aren’t going to leave with you a broken project. Maybe some of your code doesn’t work with the new version of the operating system, or maybe your data is broken by a test. A good way to help prevent this happening is to create a copy of your virtual machine. CloudNX Root Servers offer three different methods of creating copies of your virtual machines: images, clones and snapshots. But what exactly is the difference between the three?
A snapshot is a ‘picture’ of a server taken at a moment in time. On CloudNX, these snapshots are retained for 48 hours, and users can revert their servers back to the snapshot at any time. A snapshot allows a user to quickly take a copy of their machine, change the settings or run the updates that they want to run safely in the knowledge that they can roll their server back to its snapshot state if anything goes wrong. Snapshots are read-only, so it just gives you a picture to revert back to, rather than a writable copy of the VM.
Like a snapshot, a server image can be used to rollback/restore a server to a time before it broke. Taking an image of a server copies all of the SSD data the server is storing. This backup copy can be used to recover the original server if anything goes wrong. The difference between images and snapshots is that images can be stored indefinitely, whereas snapshots only remain for 48 hours. As well, a server can only have one snapshot at a time, whereas a server can have many images from different times.
Images can be set up to run automatically, in intervals of either every day or every week, up to a total of 50 images. A common schedule is to configure an image to be taken every day of the week, with each new image overwriting the oldest image from seven days ago. This way you’re not using more storage than you need to, but can be sure that you can revert to an image from any day in the last week if necessary.
A server image can also be used to build a clone of a server.
Cloning a VM creates a duplicate copy of it. Unlike an image, a clone copies the CPU and RAM as well as the SSD storage, and creates a writeable copy of the original VM. These clones can be edited, modified and updated in complete isolation to the original VM, without affecting it. This is useful when creating staging environments or test copies of the data.
As well as this, cloning saves time when setting up server farms or large numbers of similar-spec servers. Instead of having to create each server individually, you can spin up one VM and then clone it repeatedly to create VMs of the same spec. This is a significant timesaver when starting a project that requires multiple VMs.
Which one to use?
If the goal is to build a QA platform or a test environment, a clone is the suggested method to use. As a quick failsafe, just in case an OS update or patch ends up breaking something in your project, having a recent snapshot to revert to is a good solution. And having images taken every day, replacing the last week’s image is a better ongoing solution.
Visit the Fasthosts website for more information on cloud servers.