Back up and restore

A snapshot is a copy of every persistent volume of the instance, taken while it runs. Only an instance with at least one persistent volume can have snapshots: its page then has a Snapshots tab, and the Backups card on the Overview shows the Last snapshot. For an instance without one, the card says No persistent volume and the platform refuses a snapshot.

Take a snapshot

1. On the Snapshots tab, choose Take snapshot.
2. Give it a Description, if you like, and choose how long to Keep for: 7, 30, 90 or 365 days. 30 days is the default.
3. Choose Take snapshot. The instance keeps running; the snapshot completes in the background and appears in the list, where it expires by itself when its time is up.

Besides the volumes, a snapshot copies the instance's Kubernetes secrets and configuration objects — the content of sensitive files among them — into the platform's backup store. A restore puts back only the volumes.

With the CLI (--ttl in days, 1 to 365):

stsh ci snapshot create web -g my-resource-group --description "before the upgrade" --ttl 30
stsh ci snapshot list web -g my-resource-group

Schedule snapshots

1. In the Scheduled snapshots card on the Snapshots tab, choose Schedule snapshots.
2. Under Runs, choose Daily or Weekly at a time in UTC, or a Custom cron expression with five fields, in UTC. Only the number of fields is checked when you save; an expression the scheduler cannot read puts the schedule in a failed state.
3. Choose Keep each snapshot for: 7 days, 30 days, 90 days or 12 months. A month counts as 30 days, so 12 months keeps a snapshot for 360 days.
4. Choose Save.

The card then shows whether the schedule is Active, when it runs, the Next run and the Last scheduled snapshot. Pause scheduled snapshots stops it without removing it, and Edit changes it. Remove — clicked twice — deletes the schedule and its hooks; snapshots already taken stay until they expire. A changed retention applies to snapshots taken from then on.

With the CLI:

stsh ci backup-policy set web -g my-resource-group --schedule "0 2 * * *" --retention 14d
stsh ci backup-policy set web -g my-resource-group --paused true
stsh ci backup-policy get web -g my-resource-group
stsh ci backup-policy remove web -g my-resource-group

--retention is a number followed by d, w or m, such as 30d, 4w or 6m. Without a schedule of its own a policy runs daily at 03:00 UTC and keeps each snapshot for 30 days.

Consistency hooks

A snapshot copies the disk as it is at that moment. For software that keeps data in memory or in files that must not be copied half-written — a database, a cache — a hook can make it write a consistent copy first:

• Before the snapshot — a command run inside a container right before every snapshot, the ones you take and the scheduled ones. Only one container takes part: the first container in the list that has a hook of either kind. Its command runs; the other containers' do not. When that first container has only an After a restore hook, no Before the snapshot command runs at all.
• After a restore — a command run inside a container after a restore, once the instance is back up. Every container's command runs, in every running pod that has that container.

A restore uses the hooks as the schedule has them at the time of the restore, not as they were when the snapshot was taken. Init containers are listed in the dialog but never run a hook.

In the portal the hooks are under Consistency hooks in the schedule dialog, one row per container; each command runs through /bin/sh. With the CLI they are <container>=<command> pairs:

stsh ci backup-policy set web -g my-resource-group \
  --hook-backup db='pg_dump -U postgres -Fc postgres > /var/lib/postgresql/data/backup.dump' \
  --hook-restore db='pg_restore -U postgres -d postgres --clean /var/lib/postgresql/data/backup.dump'

Write the copy to a persistent volume, so that it is part of the snapshot, and keep an After a restore hook for as long as you may restore snapshots taken with a Before the snapshot hook. Without one, a restore of such a snapshot is reported as failed — but only after the volumes have been replaced and the instance started again, so the restored volumes stay, with the copy not put back. When the instance was stopped before the restore, no hook runs and the restore is reported as completed.

Restore a snapshot

1. On the Snapshots tab, choose Restore on the snapshot.
2. Type the instance's name to confirm, and choose Restore.

The restore runs in place and keeps the instance's name, endpoints and settings:

• every component is stopped;
• each persistent volume is replaced by its copy from the snapshot;
• the components start again, and After a restore hooks run.

The previous volumes are kept for seven days and then deleted. Follow the restore on the instance's Operations tab; a restore that has not finished after 45 minutes fails. An instance that was stopped before the restore stays stopped.

If the restore fails, the platform starts the instance again and the operation says why. When the copy from the snapshot fails or does not arrive in time, the previous volumes are put back first.

Caution

A failure of any other kind while the volumes are being replaced — an error from the cluster, for example — starts the instance again without putting the previous volumes back, so it can come up on empty volumes. The previous volumes are still kept for seven days, but the platform offers no way to attach them again; ask your platform administrator straight away.

With the CLI, which asks before it starts:

stsh ci snapshot restore web -g my-resource-group <snapshot-id>

Delete a snapshot

Choose the bin icon on the snapshot and confirm with Delete, or:

stsh ci snapshot delete web -g my-resource-group <snapshot-id>