Backup and recovery | DC VM Documentation

Create a backup

The request takes no body: the VM is identified by the route parameters. Create a backup before a change or maintenance window so you have a point to return to.

curl --request POST \
  --url 'https://api.zennohosting.com/v1/projects/{projectId}/vms/{vmId}/backups' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json'

The oldest backup is dropped automatically

Each VM keeps at most a fixed number of backups — currently seven. When a new backup would exceed that cap, the oldest one is deleted automatically, and the request does not fail because of it: it simply takes slightly longer. If you need a longer history, export backups yourself — the API does not keep them past the cap.

Wait for the backup to appear

A 202 only means the request was accepted. A list entry appears after the backup completes successfully: if creation fails, no entry is ever created. That makes the backup showing up in the list the most reliable success signal.

While a backup is in progress the VM is locked: starting or stopping it, creating another backup, or other operations on the same VM answer 409 Conflict until the current operation completes.

1
Create the backup
Keep projectId and vmId: everything that follows stays scoped to this VM.
2
Poll the backups list
Wait for the new entry to appear. Alternatively watch the VM: while the backup runs, its status is updating.
3
Check which OS the backup will restore
A backup entry carries sourceImageId — the image the VM was running when the backup was taken, so you can tell which OS a restore brings back. For backups created before this field existed it is null.
4
Restore the chosen backup
A restore is a change to the VM. An accepted request does not mean the VM is usable again yet.
5
Delete backups you no longer need
When a recovery point is obsolete, delete it explicitly rather than waiting for automatic rotation.

Restoring

A restore targets one specific backup. Pass the backupId you got from the list or from a read request. Afterwards read the VM and confirm its status is back to active and bootStatus is what you expect before sending traffic again.

curl --request POST \
  --url 'https://api.zennohosting.com/v1/projects/{projectId}/vms/{vmId}/backups/{backupId}/restore' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json'

Backups when a VM is rebuilt

Rebuild accepts a deleteBackups flag. It defaults to false, which keeps the backups. Pass true when the rebuild should also delete every backup of that VM.

The point of the flag shows up when switching operating systems: a backup taken under the previous OS cannot be meaningfully restored onto the new one. Keeping it after an image change is not just useless but risky — someone will eventually try to restore it.

curl --request POST \
  --url 'https://api.zennohosting.com/v1/projects/{projectId}/vms/{vmId}/rebuild' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{
"imageId": "00000000-0000-0000-0000-000000000000",
"deleteBackups": true
}'

Verify through the VM's state

Do not treat a restore as instant. Read the VM and check status and bootStatus; if something went wrong, the operation record and its failureCode carry the reason.

POST/projects/{projectId}/vms/{vmId}/backups

Create a backup of the VM.

GET/projects/{projectId}/vms/{vmId}/backups

List the VM's backups.

GET/projects/{projectId}/vms/{vmId}/backups/{backupId}

Read one backup and its sourceImageId.

POST/projects/{projectId}/vms/{vmId}/backups/{backupId}/restore

Restore the VM from the chosen backup.

POST/projects/{projectId}/vms/{vmId}/rebuild

Rebuild the VM, optionally deleting its backups.

DELETE/projects/{projectId}/vms/{vmId}/backups/{backupId}

Delete a backup that is no longer needed.