Editor’s Note: As of January 2022, iland is now 11:11 Systems, a managed infrastructure solutions provider at the forefront of cloud, connectivity, and security. As a legacy iland.com blog post, this article likely contains information that is no longer relevant. For the most up-to-date product information and resources, or if you have further questions, please refer to the 11:11 Systems Success Center or contact us directly.
This is the second blog in our series on continuity terminology. The 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:
What are backups?
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 an 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 see there are just the image files.
Within the 11:11 Cloud, we include seven-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.
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 11:11 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 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.
11:11 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 11:11 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.
No, what aren’t backups?
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 you will 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 eliminate certain 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 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 is, conveniently, the topic of next week’s installment.
