A snapshot preserves the state of a system at a specific point in time. The name “snapshot” is an analogy to photography, as it is a quick way to save a “picture” of your data. Snapshots are saved in memory and if required, a user can return the system to a previous snapshot. In CloudCIX, snapshots are taken of Virtual Machines (VMs). Taking a snapshot allows peace of mind when changing data on a virtual machine. If something goes wrong, the user can return to the VM image at the point the snapshot was taken.
Note that a snapshot is not the same as a backup. A backup is a full duplication of data if original files are lost or damaged. A snapshot does not duplicate any data, and instead saves a record of what has changed since the last snapshot. Snapshots are not intended to replace backups, but they are quick to create useful checkpoints when making changes on a VM.
VMs support multiple snapshots. Together they create a “timeline” for the state of a VM. Returning a VM to a previous snapshot is called “applying” a snapshot. Note that any changes since the last snapshot will be deleted when applying a previous snapshots.
As a user can apply old snapshots and then create new snapshots, tree structures occur naturally. Snapshots have parent and child relationships within the snapshot tree. The current VM state is a child of the most recently applied snapshot. When deleting a snapshot, the user can choose whether or not to delete the children and grand-children (called a “subtree”) of the snapshot.
Snapshots are part of CloudCIX Ifrastructure as as service (IAAS).
There are 5 possible actions that can be performed with snapshots.
Create a snapshot
Apply a snapshot
Revert to a snapshot
Delete a single snapshot
Delete a snapshot subtree
These actions can be performed either using the UI or via the CloudCIX API (https://docs.cloudcix.com/).
Performed using a put/patch request.
The pk (primary key) sent is the id for the snapshot
One piece of data needs to be sent:
state = RUNNING_UPDATE
Note that RUNNING_UPDATE is an integer defined by the CloudCIX state table.
Performed using a put/patch request.
The pk (primary key) sent is the id for the snapshot
One piece of data needs to be sent:
state = SCRUB
Note that SCRUB is an integer defined by the CloudCIX state table.
Performed using a put/patch request.
The pk (primary key) sent is the id for the snapshot
This snapshot and all of its children will be deleted
Two pieces of data needs to be sent:
state = SCRUB
remove_subtree = True
Note that SCRUB is an integer defined by the CloudCIX state table.
CloudCIX uses hypervisors to create virtual machines. The hypervisor is also used to create and manage snapshots.
CloudCIX uses two types of hypervisor:
HyperV (for windows host)
KVM (for ubuntu host)
From a CloudCIX user’s perspective, they work the same, but snapshots function differently behind the scenes on both hosts.
On hyperV, snapshots are sometimes called checkpoints.
The terms snapshot and checkpoints are used interchangeably.
There are two options for snapshots in HyperV.
These options are referred to as:
Standard Checkpoints
Production Checkpoints
CloudCIX uses standard checkpoints.
Standard checkpoints contain information about running applications. If you have a text editor open and create a snapshot - that same text editor will be open after you later apply the snapshot. When a standard checkpoint is applied, the VM shuts down and automatically restarts.
Production checkpoints do not contain information about about the running state. They use software on the virtual machine to avoid recording the running state.When a production checkpoint is applied the VM does not automatically restart.
Standard checkpoints were selected instead of production checkpoints because they autorestart the VM. They resemble KVM snapshots more than production checkpoints, so they are easier to incorporate into CloudCIX
KVM is the hypervisor for Ubuntu hosts.
KVM is able to make two types of snapshot:
Internal Snapshot
External Snapshot
CloudCIX uses internal snapshots
External snapshots create an extra file outside of the virtual hard drive for the VM. This external file is useful for later taking a backup (as it can be copied away). CloudCIX does use external snapshots when performing backups, however this functionality is separate to what is described here.
Internal snapshots do not create an external file. They are not useful for backups, but are easier to manage. Internal snapshots are easier for handling user requests to build snapshots via CloudCIX.
Robot runs commands on the host server to build, apply or delete snapshots
These are represented as 3 different categories of task.
Build = Create
Apply = Update
Delete = Scrub
Note that the update task is different from the update in an API put request.
A put request is used to apply a snapshot and delete a snapshot.
The robot update task is only used to apply a snapshot.
The put request changes the state of a snapshot in the API and this allows robot to perform actions accordingly.
Note: There is currenlty no limit in the snapshots API on the number of snapshots that can be created.
However, a limit does exist on the hypervisor.
The max snapshots on hyperV is 50.