This is the second blog in the our brief series on continuity terminology. My first covered Snapshots – and the third will cover Replication. As noted, this guide is a simple introduction to each of these concepts, and helps to explain the differences in clear, simple terms. We will discuss what each one is, isn’t, and how you might want to use them in your environment.

Without further ado, onto Backups:

Backups – What they are:

A backup refers to a full copy of a VM that is made at a regular interval (say, every 24 hours). These backups work in the same manner that any other file level backup would, by making an independent copy of the files being backed up. Essentially, this is the equivalent of backing up and entire hard drive into an image file and storing it on a remote server. All the files and documents on that drive are copied as well, but if you log on to the backup server, what you will actually see there are just the image files.

Within the iland cloud,  we include 7-day backups for every customer. So, in our environment, the files being backed up are the files that make up your VM. The machine configuration and disk files are copied and stored in a separate place within our infrastructure. Since we are making direct copies of those files, the backup process is agnostic of what is actually contained within the VM or what is on its disks.

Typically, when it comes time to restore from a backup, you need to move them from “cold storage” to a live cloud environment. In the case of the backups done in the iland cloud, however, it all happens behind the scenes. Multiple Restore Points are kept for each machine being backed up. Each of these Restore Points represents a time that the backup completed successfully, and backups can typically be configured to save Restore Points going back as far as you need.

All you need to do is open the cloud console, choose the Restore Point you prefer, and the restoration process will begin.The configuration and disk files are imported into on the back end, and you will see a new VM, identical to the original (at the time of backup) in every way, appended with “_restored” and a UUID. This new VM will be restored in place, alongside the already existing VM – effectively giving you two versions of the same machine from different points in time. Once the restore is complete, you may then make whatever changes are needed and power on the restored VM.

These backups can be a lifesaver, but they only work on machines that live in your environment permanently, and have been there for at least long enough to have a backup made (about 24 hrs). So, a brand new machine will not necessarily be backed up until it’s been live for 24 hours.

iland also offers longer term backups for those who need 30 or 90 day options. And, we offer offsite backup options for those who want those copies saved at a secondary iland location. These backups do not take up space in your ECS environment, and they do not use your resources at all until they are restored.

Backups – What they aren’t:

• Backups should not be used to “roll back” a machine to a specific point in time, like before an upgrade. For that, you will want to use snapshots, since they allow you to specify a time to which to revert. Backups are taken once a day, and you are not able to control when that process starts. While you can restore from a backup to revert those changes, you will also lose any other changes you may have wanted to keep that occurred after the time of the backup.
• Backups are not the best way to handle file-level restores. If you need to restore specific files or documents on a VM to an earlier time, you should use another method of file backup for efficiency’s sake. Every time you restore a backup, you will have to wait for the entire machine to be copied back into the environment, and you will have to have the resources available for that backup to be restored and powered on. This is especially problematic with file servers, because of the sheer size of the drives being restored.
• Backups are not a true Disaster Recovery solution. Because each VM would need to be restored in-place, one by one, you could not restore an environment nearly fast enough to recover from a disaster. Since these are simply file-level copies of the VMs on our infrastructure, there is no way to “Failover” to the backups. They must be restored before they can be used.

If you are looking for a true Disaster Recovery solution, see the section on Replication- which conveniently, is the topic of next week’s installment.