Volumes and snapshots

This content is not available in your language yet.

A volume is a virtual disk, stored replicated on TebibHost’s Ceph cluster. Every VM has a boot volume made from its image; you can attach more data volumes for databases, uploads or anything you want to keep separate from the system disk.

Volumes


Size	1 to 2,048 GiB, in whole GiB
Data volumes per VM	up to 16
Boot volume	20 GiB by default, or the image’s minimum if larger; set it at VM creation
Billing	per GB, by the hour, for as long as the volume exists (attached or not)

Open Volumes, create one, and attach it to a VM. A running VM gets it hot-plugged: no restart.

VOL=$(tebib -o json volume create data-1 --size 10 --vm "$VM" --wait | jq -r .id)
tebib volume show "$VOL"

In the VM it appears as a new, empty SCSI disk whose serial number is the volume ID, so you can find it by ID under /dev/disk/by-id/. Format and mount it once:

ls -l /dev/disk/by-id/ | grep vol-       # the volume's ID, e.g. ...vol-0123456789ab -> ../../sdb
DISK=$(ls /dev/disk/by-id/*vol-0123456789ab | head -n1)
sudo mkfs.ext4 -L data "$DISK"
sudo mkdir -p /data
echo 'LABEL=data /data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a

Mount by label or UUID, not by /dev/sdX: device names can change between boots. The boot disk is the virtio disk /dev/vda.

Grow a volume

Volumes can grow, never shrink. Grow it, then grow the filesystem inside the VM:

tebib volume resize "$VOL" --size 20 --wait

sudo resize2fs "$DISK"                   # ext4; for XFS: sudo xfs_growfs /data

Detach and delete

Unmount the filesystem in the VM first, then detach. A detached volume keeps its data and keeps billing until you delete it. The boot volume can’t be detached: it goes with the VM.

tebib volume detach "$VOL" --wait
tebib volume delete "$VOL" --yes --wait

Delete on termination: a data volume with this flag is deleted together with the VM it’s attached to. Without it (the default), deleting a VM leaves its data volumes in the project.

Snapshots

A snapshot captures all of a VM’s volumes at one moment. Use one before an upgrade or a risky change, and restore the VM to it if things go wrong.

Consistency: when the guest agent runs in the VM (TebibHost’s images install it), the VM’s filesystems are frozen for a few seconds while the snapshot is taken: the snapshot is application-consistent. Without the agent it is crash-consistent, like pulling the plug. The snapshot shows which one you got.
Billing: per GB of the snapshot’s size, by the hour, while it exists.
A snapshot is not a backup in another place: it lives on the same storage cluster as the VM. Copy anything you can’t lose somewhere else as well.

Console
CLI

On the VM’s page, Snapshots → Take snapshot, or Storage → Snapshots → Take snapshot and pick the VM. The form shows what the snapshot costs.

SNAP=$(tebib -o json snapshot create before-upgrade --vm "$VM" --wait | jq -r .id)
tebib snapshot show "$SNAP"

Restore a VM

Restoring rolls the VM’s disks back to the snapshot; anything written since is lost. The VM must be stopped, and every volume in the snapshot must still be attached to it.

In the console, open the snapshot and use Restore VM to this snapshot. It offers to stop the VM first, lists the disks that go back, and asks you to type the VM’s name.

tebib vm stop "$VM" --wait
tebib vm restore "$VM" "$SNAP" --wait
tebib vm start "$VM" --wait

Snapshots belong to their VM: you can restore only the VM they were taken of. New VMs from a snapshot are not available yet; see Custom images.

Scheduled backups

A snapshot schedule snapshots one VM on a schedule and deletes its old snapshots for you.

When: every hour (at a minute you pick), every day or every week (at a time you pick), or a custom cron expression (minute hour day-of-month month day-of-week, such as 30 2 * * 1-5 for 02:30 on weekdays). At most once an hour. Times are in the schedule’s time zone (an IANA name such as Africa/Nairobi; the API’s default is UTC, the console suggests yours).
What it keeps: the newest N snapshots, none older than N days, or both. Only snapshots the schedule took are deleted, never the newest ready one, and never one you are restoring from. Snapshots you take by hand are never touched.
The snapshots are ordinary snapshots named <schedule>-<YYYYMMDD-HHMM>, labelled with the schedule. You restore, bill and delete them like any other.
Billing: the schedule itself is free; its snapshots bill per GB while they exist.
Quota: each snapshot counts against the snapshots quota (one per disk). A new snapshot is taken before the oldest is deleted, so leave room for one more than the schedule keeps.

Console
CLI

Storage → Snapshot schedules → New schedule, or on the VM’s page Snapshots → Schedule snapshots. The form shows what the kept snapshots cost at most.

SCHED=$(tebib -o json snapshot schedule create nightly --vm "$VM" \
  --every daily --at 02:30 --timezone Africa/Nairobi --keep 7 | jq -r .id)
tebib snapshot schedule show "$SCHED"
tebib snapshot schedule update "$SCHED" --every weekly --on sun --keep-days 30
tebib snapshot schedule update "$SCHED" --disable
tebib snapshot list

When a run doesn’t happen

The schedule shows its last run and why it didn’t succeed. The first such run sends a notification, and an alert stays in the console until a run succeeds again.

Reason	What to do
The snapshots quota is full	Delete snapshots, keep fewer, or ask for a higher quota
The balance is too low	Top up
The VM was busy	The VM was being created, changed or restored for 15 minutes after the run; nothing to do
The snapshot failed or took too long	TebibHost is alerted and looks into it; the next run is taken as usual

If TebibHost’s scheduler was down when runs were due, it takes one snapshot when it is back, not one per missed run, and the schedule shows how many were missed.

Turning a schedule off stops new snapshots and retention. Turned on again, or changed, it starts with the next run from now. Deleting a schedule keeps its snapshots: delete them when you no longer need them. Deleting a VM deletes its schedules, not its snapshots.

tebib snapshot schedule delete "$SCHED" --yes

Who may: compute:CreateSnapshotSchedule (plus compute:CreateSnapshot on the VM), compute:DescribeSnapshotSchedule, compute:UpdateSnapshotSchedule, compute:DeleteSnapshotSchedule. Once made, the schedule’s snapshots are taken by TebibHost, whoever made it.

A schedule takes snapshots of a whole VM. To back up a data volume, schedule the VM it is attached to.

Limits

	Default per project
Volumes, including boot volumes	20
Total volume size	100 GiB
Snapshots (one per disk in each VM snapshot)	20
Snapshot schedules	10 (5 per VM)