Skip to content
Coritan Docs

Back up and restore an instance

Back up an instance by hand or every week or day, restore a backup over its disk, and delete the backups you no longer need.

View as Markdown

A backup is a full copy of an instance's disk, saved as a compressed archive. Restore a backup to put the disk back the way it was when we made the copy. An instance can hold 16 backups. You can make them yourself, and we can also make them for you every week or every day (Automatic backups).

Each backup is an archive of its own, apart from the disk it copies. When you rebuild the instance, its backups stay, and you can restore one over the new disk. Cancelling the instance deletes its backups. We keep backups on the server the instance runs on, so keep your own copy of anything you cannot lose. For quick restore points on the same disk, take a snapshot.

The Backups card says the same in one line: backups are full copies that survive a rebuild and suit restores days or weeks later, and Snapshots is for a quick undo.

  • The instance is not suspended.
  • No other backup, restore or backup deletion is running on the instance. They run one at a time.
  • The instance has not used more than its monthly traffic allowance. We make no backups of an instance that is over it until the next month starts. How instance traffic is counted explains the allowance.
  1. In the dashboard, go to Cloud Compute, open the instance and select the Backups tab.

  2. Select Create backup…. A page opens with the heading Create a backup, the instance's name under it and a This backup card that counts the backups the instance holds out of 16.

  3. Under Note, optionally add up to 255 characters, such as Before the database migration. The table shows the note as the backup's name.

  4. Under Mode, choose how we copy a running instance:

    • Snapshot (no downtime) copies the disk while the instance keeps running. It is the default, and it suits most workloads.
    • Suspend pauses the instance while we start the copy, then resumes it.
    • Stop shuts the instance down, starts the copy and boots the instance again. It gives the most consistent copy, with the longest pause.

    When the instance is stopped, the three modes are off, because every mode gives the same consistent copy.

  5. Under Compression, keep zstd (fast, recommended) unless you have a reason to change it. lzo (fastest, larger) and gzip (smallest, slowest) trade speed against size, and None stores the copy uncompressed.

  6. Select Create backup.

If we refuse the request, a Could not start the backup message says why, and every field keeps what you entered. When the instance cannot take a backup at all, the page opens with You cannot take a backup now and the reason, and shows no form. The Back to Backups button takes you back to the tab. On the form, Cancel and the Backups link above the heading do the same without making a backup.

After Create backup, a message says the backup is queued and you return to the Backups tab.

The backup appears at the top of the table with the status Creating. You can leave the page while it runs. Reload the page to see its progress.

Restoring replaces the instance's disk with the backup and loses everything written to the disk since the backup was made.

  1. On the Backups tab, open the menu at the end of a Completed backup's row and select Restore backup….
  2. Type restore to confirm, then select Restore backup.

We stop the instance and write the backup over its disk. When the disk is ready, we start the instance, even if it was stopped before. The backup shows Restoring until then, and stays in the table afterwards.

A restore also brings back what the instance was like at the moment of the backup: its password, SSH keys, hostname, network settings and size. After the restore:

  • If you changed the password, SSH keys or hostname since the backup, set them again on the Access tab.
  • If the instance's address changed since the backup, or it got IPv6 after the backup, reapply the instance's settings and restart the instance from the header.
  • If you changed the plan since the backup, contact support so we can apply it to the instance again.
  • Take new snapshots. The restore deletes the instance's snapshots, because they belong to the disk it replaced.

Warning

Create a fresh backup first if you might need the disk's current state. A snapshot does not help here, because the restore deletes it.

  1. On the Backups tab, open the menu at the end of the backup's row and select Delete backup….
  2. Type delete to confirm, then select Delete backup.

We delete the archive, and the backup leaves the table once it is gone. You cannot undo this.

A backup that shows Failed stored nothing. Select Remove backup… on its row, then Remove backup, to take it off the list.

With automatic backups, we back up the instance every week or every day and keep the newest ones. Each is an ordinary backup named Automatic backup in the table, and you restore or delete it like one you made. They come as an add-on for the instance:

Add-on We back up We keep Price
Weekly Instance Backups Every week The newest 4 20% of the instance's price
Daily Instance Backups Every day The newest 7 30% of the instance's price

Once account plans open on your account, the Business plan pays for either add-on on up to three instances, and the Enterprise plan on every instance. On an instance your plan covers, the add-on shows Included in your plan and costs nothing.

An instance billed by use has no price of its own, so an add-on that costs a share of the instance's price takes that share of the monthly list price of the instance's size. An RX-2 instance lists at $4.99 a month, so Weekly Instance Backups cost $1.00 a month and Daily Instance Backups cost $1.50. The add-on renews every month on its own, and the instance keeps billing by use (Add-ons on a service billed by use, How Cloud Compute is billed). A size with no monthly list price cannot take the add-on, and the list says Weekly Instance Backups has no monthly price, so it cannot be bought for this instance.

Add automatic backups to an instance

Section titled Add automatic backups to an instance

Once account plans open on your account:

  1. In the dashboard, go to Cloud Compute, open the instance and stay on the Console tab.
  2. On the Plan and add-ons card, under Available, select Add… beside Weekly Instance Backups or Daily Instance Backups.
  3. A page opens with the add-on's name in its heading. Read the price in Your order, choose how to pay under Pay with, and select the button that names the charge, such as Pay $5.00 and add. If the page asks you to pay an invoice, pay it (Pay an invoice). The backups start once the invoice is paid. Add an add-on describes the page.

Before account plans open on your account, add them with the API (Automatic backups with the API).

The add-on renews with the instance, on the same date and billing cycle, and the first invoice charges the rest of the current billing period. An instance takes one of the two add-ons. To switch between weekly and daily, remove the one it has from the Plan and add-ons card, and add the other once the first ends, when the instance renews.

We check every instance once an hour. An instance gets its next automatic backup a week or a day after its last one, so it lands at about the same hour each time. The first one comes within an hour of the add-on starting.

  • We copy the disk while the instance keeps running, compressed with zstd, as Snapshot (no downtime) does.
  • Automatic backups count toward the 16 backups an instance can hold. Once there are more than the add-on keeps, we delete the oldest automatic backup. We never delete a backup you made.
  • When the instance already holds 16 backups, we delete the oldest automatic backup first and take the new one an hour later. When all 16 are backups you made, we take none until you delete one.
  • We skip an instance while another backup, restore or deletion runs on it, while we move it to another host, and while it is suspended. We also skip it while it is over its monthly traffic allowance, and look again six hours later.
  • After a failure, we try again six hours later.

When the add-on ends, we stop making automatic backups. The ones already made stay in the table and count toward the 16 until you delete them.

The table lists each backup with its Status, its Size and when it was Created, with how long it took under the date. A backup is named by its note, with Manual and the date and time it was taken under the name. A backup without a note is named Manual backup or Automatic backup, with the date and time under it. Creating, Completed and Restoring backups count toward the 16 an instance can hold. Failed backups do not.

Once account plans open on your account, the foot of the table says when automatic backups are on for the instance. When the instance can take them, it links to the Plan and add-ons card, where you add them.

Create backup… is greyed out
The foot of the table says why, and a page you open by its address, /dashboard/compute/<uuid>/backups/new, says the same under You cannot take a backup now. A backup, a restore or a deletion is running, the instance is suspended, we are moving it to other hardware, it has used its traffic allowance for the month, or it holds 16 backups. Wait for the running one to finish, then reload the page. If the instance is suspended, the alert at the top of the page says why, and you can create backups again once the suspension ends. At 16 backups, delete one you no longer need.
A backup or restore is already in progress on this instance
A backup, a restore or a deletion is running on the instance. Wait for it to finish, reload the page and try again.
Backup limit of 16 reached
The instance holds 16 backups. Delete one you no longer need, then create the new one.
Monthly traffic quota exceeded; backups are blocked until the next period
The instance has used more than its traffic allowance this month. You can create backups again when the next month starts. The Bandwidth card on the Console tab shows the date it resets.
Too many requests for this action. Try again later.
You started more than 8 backups, or more than 8 restores, of the instance within five minutes. Wait a few minutes and try again.
Cannot delete a backup while it is still running
The backup is still being created or restored. Wait until it shows Completed, then delete it.
The backup shows Failed
We could not finish the copy. Remove the failed backup and create a new one. If backups keep failing, contact support with the instance's hostname.
The instance does not come back after a restore
Open the Console tab to see what the instance is doing. If it is stopped, start it from the header.
A second floating IP does not answer after a restore
The restore brings back the network settings from the moment of the backup. For each other floating IP on the instance, detach it and attach it again, then restart the instance from the header.
No new automatic backup shows up
The instance holds 16 backups that you made, and we never delete those. Delete one you no longer need, and the next automatic backup comes within the hour. We also make none while the instance is over its monthly traffic allowance.
This instance has weekly automatic backups. Remove them first to switch to daily.
An instance takes one of the two backup add-ons. Remove the weekly add-on, and add the daily one once the weekly one ends.

GET /api/v1/client/vps/{uuid}/backups lists the instance's backups, newest first. Each has an id, a note, a status, an origin, size_bytes, created_at and completed_at, and proxmox_volid, the archive's name in backup storage. status is creating, completed, failed, restoring or deleting. origin is auto for an automatic backup, and manual for one you made.

POST /api/v1/client/vps/{uuid}/backups starts a backup. Every field is optional:

  • note: up to 255 characters.
  • mode: snapshot (the default), suspend or stop.
  • compress: zstd (the default), lzo, gzip, or 0 for none.
Shell
curl -X POST https://api.coritan.com/api/v1/client/vps/$INSTANCE_UUID/backups \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"note": "Before the database migration", "mode": "snapshot", "compress": "zstd"}'
JSON
{"backup_id": 12, "status": "creating", "mode": "snapshot"}

The request returns as soon as we queue the backup. List the backups again until its status is completed or failed.

POST /api/v1/client/vps/{uuid}/backups/{backup_id}/restore takes no body and restores a completed backup. It answers {"status": "restore_queued"}. The backup's status is restoring until the instance runs again, then returns to completed. GET /api/v1/client/vps/{uuid}/tasks shows the host's qmrestore task and then its qmstart task.

DELETE /api/v1/client/vps/{uuid}/backups/{backup_id} deletes a backup and answers {"status": "delete_queued"}. The backup shows deleting until we remove it from the list.

These requests can answer:

  • 400 with mode must be snapshot, suspend, or stop for another mode.
  • 403 with Monthly traffic quota exceeded; backups are blocked until the next period when you start a backup of an instance that is over its allowance.
  • 404 with Backup not found when the instance has no backup with that id, or Backup not found or not completed when you restore a backup that is not completed.
  • 409 with A backup or restore is already in progress on this instance, Backup limit of 16 reached or Cannot delete a backup while it is still running.
  • 409 while we move the instance to another host: Instance is migrating for a new backup, and a message that starts Cannot restore or Cannot delete a backup for the others.
  • 429 for more than 8 new backups, or more than 8 restores, of one instance in five minutes, as Rate limits describes.

The Cloud Compute API reference lists every field.

Automatic backups with the API

Section titled Automatic backups with the API

GET /api/v1/services/{service_ref}/addons lists what the instance can take. service_ref is the instance's service ID. In available, the two backup add-ons have kind set to vps_auto_backups, and each shows what it costs on this instance:

JSON
{
  "product": {"id": 91, "slug": "addon-instance-backups-daily", "name": "Daily Instance Backups"},
  "kind": "vps_auto_backups",
  "adds": "daily automatic backups",
  "price": {"mode": "percent_of_parent", "percent": "30", "amount": "3.60", "cycle": "monthly", "text": "30% of the instance price"},
  "addable": true,
  "included_by_plan": false,
  "reason_unavailable": null
}

Add one with its product's id:

Shell
curl -X POST https://api.coritan.com/api/v1/services/$SERVICE_ID/addons \
  -H "Authorization: Bearer $CORITAN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 91}'

When the answer has requires_payment set to true, pay invoice_id as Pay an invoice shows. Add-ons describes the answer, and how to remove the add-on.

In the backup list, an automatic backup has origin set to auto and note set to Automatic backup.

GET /api/v1/client/vps/{uuid}/backups/automatic shows how the instance's automatic backups stand:

Shell
curl https://api.coritan.com/api/v1/client/vps/$INSTANCE_UUID/backups/automatic \
  -H "Authorization: Bearer $CORITAN_TOKEN"
JSON
{
  "available": true,
  "frequency": "daily",
  "keep": 7,
  "latest_backup_at": "2026-09-26T03:00:04",
  "next_run_at": "2026-09-27T03:00:04",
  "last_run_at": "2026-09-26T03:00:02",
  "last_error": null,
  "automatic_backup_ids": [118, 116],
  "backups": [
    {"id": 118, "origin": "auto"},
    {"id": 117, "origin": "manual"},
    {"id": 116, "origin": "auto"}
  ],
  "service_id": 1042
}
available, frequency and keep
Whether the instance has one of the backup add-ons, which one (weekly or daily), and how many automatic backups we keep: 4 or 7. Without an add-on, available is false and the other two are null.
latest_backup_at and next_run_at
When the newest automatic backup started, and when the next one is due: a week or a day later, or now when there is none yet or that time has passed. Our hourly check takes it at about that hour, unless How automatic backups run gives a reason to wait. Without an add-on, next_run_at is null.
last_run_at and last_error
When we last tried, and why that try failed, such as This instance has used more than its monthly traffic allowance, so we take no backups of it until the next month starts. last_error is null after a try that worked.
backups and automatic_backup_ids
Every backup being taken or kept, newest first, with its id and origin, and the id of each automatic one. A backup that failed, or is being restored or deleted, is left out.
service_id
The instance's service ID, for the add-on requests above.

While the instance's service is not active, available is false, the lists are empty and every other field is null.

API operations on this page

MethodPathWhat it does
GET/api/v1/client/vps/{uuid}/backupsList backups for this instance
POST/api/v1/client/vps/{uuid}/backupsCreate a new backup of this instance
GET/api/v1/client/vps/{uuid}/backups/automaticThe instance's automatic backups, for its Backups tab
DELETE/api/v1/client/vps/{uuid}/backups/{backup_id}Delete a backup
POST/api/v1/client/vps/{uuid}/backups/{backup_id}/restoreRestore from a backup
GET/api/v1/services/{service_ref}/addonsThe add-ons on one of your services, and the ones you can add
POST/api/v1/services/{service_ref}/addonsAdd a capacity add-on to one of your active services