Volumes and snapshots

This document provides basic information about how volumes and snapshots work:

• Volumes are the basic service of the StorPool storage system. They appear to storage clients as block devices under the /dev/storpool/ directory and behave as normal disk devices.

• Snapshots in StorPool are read-only point-in-time images of volumes.

Volumes and snapshots can be managed in the following ways:

• Using the command line interface; for details, see Volumes and Snapshots.

• Using the REST API.

• You can generate a visual representation of the volumes and snapshots; for details, see StorPool tree.

Volumes

Volumes are the basic service of the StorPool storage system. A volume always has a name, a global ID and a certain size. It can be read from and written to. It could be attached to hosts as read-only or read-write block device under the /dev/storpool directory (available as well at /dev/storpool-byid).

A single volume

The volume name is a string consisting of one or more of the allowed characters - upper and lower Latin letters (a-z,A-Z), numbers (0-9) and the delimiters dot (.), colon (:), dash (-) and underscore (_).

Creating a volume

Creating a volume

All volumes are thin provisioned. Creating a volume is not limited to physical disk or disk pool size. Creating a volume doesn’t pre-allocate physical space in the storage cluster.

Here is an example how you can create a volume using the CLI (see Creating a volume):

# storpool volume testvolume create size 100G template ssd

Deleting a volume

Deleting a volume

Here is an example how you can delete a volume using the CLI (see Deleting volumes):

# storpool volume vol1 delete vol1

Renaming a volume

Renaming a volume

Here is an example how you can rename a volume using the CLI (see Renaming volumes):

# storpool volume testvolume update rename newvolume

Resizing a volume

Resizing a volume

Here is an example how you can resize a volume using the CLI (see Resizing volumes):

# storpool volume testvolume update size +1G

Cloning a volume

You have a volume:

When you clone it the system performs two steps. First, it creates a new transient snapshot of the volume. Then it creates a second volume, which is based on the same snapshot.

Cloned volumes with transient snapshot

Here is an example how you can clone a volume using the CLI (see Volume operations):

# storpool volume vol2 create size 2G template ssd baseOn vol1

Snapshots

Snapshots are read-only point-in-time images of volumes. They are created once and their data cannot be modified. They can be attached to hosts as read-only block devices under /dev/storpool.

A single snapshot

All volumes and snapshots share the same name-space. Names of volumes and snapshots are unique within a StorPool cluster. This means you can’t have a volume and a snapshot with the same name. Here is a simple example with unique names:

• Volume names: vol1, vol2, vol3

• Snapshot names: snap1, snap2, snap3

This diagram illustrates the relationship between a snapshot and a volume:

Volume-snapshot relation

• When you create a snapshot snap1 of volume vol1, this volume becomes based on the snapshot.

• vol1 contains only the changes since snap1 was taken. In the common case this is a small amount of data.

• Arrows indicate a child-parent relationship. Each volume or snapshot may have exactly one parent which it is based upon.

• Writes to vol1 are recorded within the volume.

• When there is a request for reading from vol1 the system reads data from the volume or from the parent snapshot snap1, depending on whether the data has been changed since the snapshot was created.

Snapshots and volumes are completely independent. Each snapshot may have many children (volumes and snapshots). Volumes cannot have children. This is illustrated in the diagram below:

Volume-snapshot chain

• snap1 contains a full image.

• snap2 contains only the changes since snap1 was taken.

• vol1 and vol2 contain only the changes since snap2 was taken.

Creating a snapshot of a volume

Assume there is a volume named vol1.

A single volume

After the first snapshot the state of vol1 is recorded in a new snapshot named snap1. vol1 does not occupy any space now, but will record any new writes which come in after the creation of the snapshot. Reads from vol1 may fall through to snap1.

After the first snapshot

Then the state of vol1 is recorded in a new snapshot named snap2. snap2 contains the changes between the moment snap1 was taken and the moment snap2 was taken. snap2’s parent is the original parent of vol1.

After the second snapshot

Here is an example how you can create a snapshot using the CLI (see Creating snapshots):

# storpool volume vol1 snapshot snap1

Creating a volume based on an existing snapshot (cloning)

Before the creation of volume there is a snapshot named snap1.

A single snapshot

A new vol1 volume is created, which is based on the snap1 snapshot. The newly created volume does not occupy any space initially. Reads from the vol1 may fall through to snap1 or to snap1’s parents (if any).

Volume created from a snapshot

Here is an example how you can create a volume based on an existing snapshot using the CLI (see Volume operations):

# storpool volume vol1 parent snap1

Deleting a snapshot

The vol1 and vol2 volumes are based on the snap1 snapshot. snap1 is based on snap0. snap1 contains the changes between the moment snap0 was taken and when snap1 was taken. vol1 and vol2 contain the changes since the moment snap1 was taken.

Before deletion

After the deletion of the snap1 snapshot, vol1 and vol2 are based on snap1’s original parent (if any). In the example here they are now based on snap0. When deleting a snapshot, the changes contained therein will not be propagated to its children and StorPool will keep the snap1 in deleting state to prevent from an explosion of disk space usage.

After deletion

Here is an example how you can delete a snapshot using the CLI (see Deleting snapshots):

# storpool snapshot snap1 delete snap1

Rebase to null (promotion)

The vol1 volume is based on the snap1 snapshot. snap1 is in turn based on snap0. snap1 contains the changes between the moment snap0 was taken and when snap1 was taken. vol1 contains the changes since the moment snap1 was taken.

Before rebase to null

After promotion the vol1 volume is not based on a snapshot. It now contains all data, not just the changes since snap1 was taken. Any relation between snap1 and snap0 is unaffected.

After rebase to null

Here is an example how you can promote a snapshot using the CLI (see Promoting snapshots):

# storpool snapshot testsnap rebase # [parent-snapshot-name]

Rebase

The vol1 volume is based on the snap1 snapshot. snap1 is in turn based on snap0. snap1 contains the changes between the moment snap0 was taken and when snap1 was taken. vol1 contains the changes since the moment snap1 was taken.

Before rebase

After the rebase operation vol1 is based on snap0. vol1 now contains all changes since snap0 was taken, not just since snap1. snap1 is unchanged.

After rebase

For details on how you can do this on the command line, see Promoting snapshots.

Example use of snapshots

This is a semi-realistic example of how volumes and snapshots may be used:

Using snapshots: example 1

• There is a snapshot called base.debian13. This snapshot contains a base VM image (in this example, Debian 13), which was prepared carefully by the service provider.

• There are 3 customers with 4 virtual machines each.

• All virtual machine images are based on the same ‘master’ image, but may contain custom data, which is unique to each VM. Changes in one volume don’t affect the parent snapshots or the other volumes that are created from it.

This example shows another typical use of snapshots - for restore points back in time for a volume.

Using snapshots: example 2

There is one base image for Debian 13, three snapshot restore points, and one live volume custA.v.1