🎉 Announcing new lower pricing — up to 40% lower costs for Cloud Servers and Cloud SQL! Read more →

Contents

Block Storage Volumes

Volumes are network-based block storage devices that provide high performance, high availability and flexible storage for Cloud Servers.

Volumes can be resized instantly at any time and additional volumes (up to 6 in total) can be attached to a cloud server at any time.

Volumes can be created in two ways:

  1. During cloud server creation when using a block storage server type – a single boot volume is created by default from the chosen OS image
  2. Individually, as required, using the volumes API

Volume size

An initial volume size can be specified during volume creation and defaults to the minimum volume size if not specified. Volumes must be a minimum of 40GB and maximum of 4TB.

Volume size can be increased at any time up to the maximum volume size, but cannot be decreased in size.

Automatic formatting

When creating a new volume an optional filesystem_type (either ext4 or xfs) can be specified which will automatically create a corresponding filesystem on the volume. When a filesystem type is specified, an optional 12 character filesystem_label can also be specified which can be used to reference the formatted filesystem within a cloud server (see Persistent block device naming).

The filesystem attributes on a Volume cannot be changed via the API after creation.

Persistent block device naming

When servers have more than one block device, the ordering of OS-assigned device names (e.g. /dev/vdb, /dev/vdc etc) should not be relied upon to be consistent and it is possible for device names to change order after a reboot.

To solve this, there are two attributes which can be used to provide persistent block device names and allow referencing a volume consistently inside a cloud server.

Volume serial

The serial is a string of up to 20 characters and defaults to the volume id (vol-xxxxx). The volume serial can be edited, but only when a volume is detached.

Volume serials can usually be referenced within a Linux-based cloud servers using the symbolic links present in /dev/disk/by-id/

Example:

$ ls -l /dev/disk/by-id/
total 0
lrwxrwxrwx 1 root root  9 Apr 26 15:51 virtio-my-vol-serial -> ../../vdc
lrwxrwxrwx 1 root root  9 Apr 26 15:24 virtio-vol-xi757 -> ../../vda
lrwxrwxrwx 1 root root 10 Apr 26 15:24 virtio-vol-xi757-part1 -> ../../vda1
lrwxrwxrwx 1 root root 11 Apr 26 15:24 virtio-vol-xi757-part14 -> ../../vda14
lrwxrwxrwx 1 root root 11 Apr 26 15:24 virtio-vol-xi757-part15 -> ../../vda15
lrwxrwxrwx 1 root root  9 Apr 26 15:26 virtio-vol-yf8iz -> ../../vdb

Filesystem label

The filesystem label, if provided (see Automatic formatting) can also be used to reference the formatted volume’s filesystem within a cloud server.

Labels can usually be referenced within Linux-based cloud servers using the symbolic links present in /dev/disk/by-label/

Example:

$ ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx 1 root root 11 Apr 26 15:24 UEFI -> ../../vda15
lrwxrwxrwx 1 root root 10 Apr 26 15:24 cloudimg-rootfs -> ../../vda1
lrwxrwxrwx 1 root root  9 Apr 26 15:26 my-vol-label -> ../../vdb

Boot volume

Cloud servers must have one attached volume designated as the boot volume, which must contain a bootable filesystem.

The boot volume can be changed when the cloud server is inactive (i.e shut down) by attaching a different volume and specifying it as the boot volume.

Image

A volume can be created from an image which will copy the contents of the image to the volume. This is the default method used when creating a new cloud server specifying an image and a block storage server type.

Volume persistence

The delete_with_server attribute is used to determine whether the volume should be deleted automatically when the cloud server it is currently attached to is deleted.

By default, volumes created automatically during server creation have delete_with_server set to true (which aligns with how standard SSD cloud servers work). Volumes created independently of a cloud server are set to false, unless specified otherwise.

Locking

As with other Brightbox cloud resources, Volumes support resource locking to prevent accidental deletion.

Attaching volumes

Volumes can be attached to a cloud server at any time (up to a maximum of 6 volumes).

Attaching a volume to a cloud server makes it available as a block device, but it will need to be mounted within the cloud server before use.

Detaching volumes

Volumes can be detached from a cloud server at any time but no checks are made as to whether it is in use within the cloud server. Ensure that the relevant filesystem is unmounted before detaching the volume or data loss can occur.

Copying volumes

Creating a copy of a Volume results in a new volume which is an exact copy of the original. The new volume can be attached to an existing server or used as the root volume for a new server.

Creating a copy volume happens almost instantaneously. The resulting copy volume will be exactly the same size as the source volume, regardless of how much actual data has been written to it.

Snapshotting Volumes

Snapshotting a Volume creates an Image resource which, like other Images, is stored in Orbit (our object store).

Since snapshots are compressed with lz4, the exact size of a volume snapshot image will depend on how much empty space exists on the source Volume.

Accordingly, creating a snapshot takes several minutes while data is copied to Orbit, depending on the size of the image.

Last updated: 10 Jan 2024 at 12:45 UTC

Try Brightbox risk-free with £50 free credit Sign up takes just two minutes...