Snapshots & volumes

Which servers

Snapshots and volumes are made through Hetzner's API with your team's Hetzner token, so they are available on servers Provisore created on Hetzner Cloud. They live under Storage in the server's Settings. A server you connected yourself shows a single line there instead.

Every operation runs as a job in the console, step by step, with Hetzner's own answer when it refuses something. One job at a time holds a server: a snapshot, a restore, a volume change or a type change waits for the one already running.

Taking a snapshot

Take snapshot copies the server's disk into an image stored at Hetzner. Hetzner compresses it and bills per GB stored each month. Volumes are not part of a snapshot.

• Running. The default. Provisore flushes the server's writes to disk first, and the image is what a sudden power cut would leave behind. Databases recover from that the way they recover from a crash.
• Shut down. The server is shut down while Hetzner copies the disk and powered on after. Every write is in the image. If the copy fails, the server is powered back on.

A snapshot stays until you delete it, including after its server is deleted. Snapshots of deleted servers are listed under the Snapshots section of every server Provisore created on Hetzner, and in the new server form.

Provisore does not take snapshots on a schedule. For daily images, turn on Hetzner's backups for the server in the Hetzner console. They are Hetzner's own feature, and their price is included on the Costs page.

Restoring in place

Restore in place rebuilds a server from one of its own snapshots. Hetzner powers the server off and overwrites its disk with the image, so everything written since the snapshot is lost. You confirm by typing the server's name, and restoring needs the admin or owner role.

The job then powers the server on, waits for SSH to answer with the server's own host key, and mounts its volumes again, since the disk's fstab is the one from the snapshot. The server keeps its IP address. Provisore's records still describe the server as it was before the restore, so run a resync from the server's Drift settings to see what differs.

Creating a server from a snapshot

Choose Create a server from this snapshot in a snapshot's menu, or pick the snapshot under Start from when you create a Hetzner server. The new server gets the snapshot's Ubuntu release, role and database engine. Its server type needs a disk at least as large as the snapshot's and the same architecture, and the form offers only those.

Before the copy reports to Provisore on its first boot, it undoes the source's identity:

• New SSH host keys, so the two servers are never mistaken for each other.
• The source server's Provisore key is removed from root and provisore, and the new server's own key takes its place.
• SSH hardening is removed and applied again by provisioning.
• The source's metrics and log shipping credentials are removed. Install the collector and shipper again from the new server's Monitoring settings if you use them.
• Entries for the source's volumes are taken out of fstab.

Everything else on the disk comes up as it was on the source: sites, databases, cron jobs and daemons, which start running. Provisore's records for the new server do not list them; a resync shows them.

Volumes

Add volume creates a Hetzner volume in the server's location, attaches it, formats it with ext4 or xfs, and mounts it at the path you choose. The mount goes into fstab by the filesystem's UUID with nofail, so the volume is mounted again after every reboot and a missing volume never stops the server booting.

• Formatting. Only a blank volume is formatted. A volume that already holds the filesystem is mounted as it is, and anything else is refused.
• Mount path. Created if it does not exist. A directory that already holds files is refused, since mounting over them would hide them. If the mount fails, the volume is detached again and listed as detached.
• Owner. The account the volume’s top directory belongs to: root, the provisore deploy user, or one of the server’s sites. No other site can read a volume a site owns, and that site’s links into the volume pass symlink protection. The owner is set on every mount; files already on the volume keep theirs.
• Resize. Hetzner grows the volume and the filesystem is grown to fill it while it stays mounted. Volumes cannot shrink. If the filesystem step fails, resizing to the same size finishes it.
• Detach. Unmounts the volume, removes its fstab entry, and detaches it at Hetzner. If any process has a file open on it or works inside it, nothing changes and the job lists each process by PID, user and command. The data stays on the volume.
• Attach. A detached volume can be attached to any server in its location, with its data.
• Delete. Unmounts and detaches the volume first if it is attached, then deletes it and every file on it. You confirm by typing its name.

A server's volumes have to be detached or deleted before the server itself can be deleted, because Hetzner keeps billing for a volume after its server is gone. Detached volumes are listed under every server in the same location.

What they cost

Volumes and snapshots are lines on the Costs page, priced from Hetzner's API for your account: a volume on its size, a snapshot on the size Hetzner stores.