Snapshots vs Backups on Amóni Cloud

Two features protect a cloud instance, and they are not the same thing. A snapshot freezes the instance as it is right now so you can jump back to that exact moment. A backup is a full copy kept on separate storage, so it is still there if the instance, or the machine it runs on, is gone. Reach for a snapshot before a risky change; rely on backups for everything else.

Snapshots: an undo button

A snapshot records the instance's disk and, if you ask, its memory, in place on the same storage. Taking one is close to instant, and rolling back to one returns the instance to that state in seconds. That makes snapshots the right tool right before something you might want to undo: a kernel upgrade, a config change, a migration you are not sure about. Take the snapshot, make the change, and if it goes wrong, roll back.

What a snapshot is not is a safe copy. It lives on the same storage as the instance, so it does not help if that storage or the host fails. It also holds on to every disk block that has changed since you took it, so an old snapshot quietly grows and ties up space. You can keep five per instance; delete the ones you no longer need. Treat snapshots as short-lived: take one, use it, remove it.

Backups: a copy that survives

A backup is a complete copy of the instance written to a separate backup store, independent of the instance and the host it runs on. That is what makes it disaster recovery: if the instance is destroyed, rebuilt or lost, a backup can restore it. Backups run in snapshot mode, so the instance keeps running while the copy is taken, with no downtime.

You can run a backup on demand, or set a schedule so one is taken every night and old ones are pruned to a retention you choose. A backup takes longer than a snapshot and uses its own storage, which is exactly the trade for a copy that outlives the instance.

Which to use

A short version: snapshot before you touch something, back up so you can sleep.

In the portal

Open your instance from Cloud and use its Snapshots and Backups tabs. On Snapshots, Take snapshot asks for a name and whether to include memory; each row has Roll back and Delete. On Backups, Back up now starts one, Schedule turns on the nightly job and sets how many to keep, and each backup has Restore and Delete.

With the API

Both live under the instance and need the VMs scope (vms.write); listing needs read. The path carries your cloud account id and the instance id, which you can read from GET /v1/vms. See Getting started with the Amóni API for keys and scopes.

Snapshots. Take one, list them, roll back, delete:

curl -s -X POST https://api.amoni.app/v1/vms/990204/411/snapshots \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"name": "before-upgrade", "description": "kernel bump", "include_ram": false}'
# { "success": true, "data": { "message": "Snapshot created." } }

curl -s https://api.amoni.app/v1/vms/990204/411/snapshots \
  -H "Authorization: Bearer nr_live_..."
# { "success": true, "data": { "snapshots": [
#   { "name": "before-upgrade", "description": "kernel bump", "has_ram": false, "created_at": 1758... } ] } }

# roll the instance back to it (this reverts the instance):
curl -s -X POST https://api.amoni.app/v1/vms/990204/411/snapshots/before-upgrade/rollback \
  -H "Authorization: Bearer nr_live_..."

# remove it when you are done:
curl -s -X DELETE https://api.amoni.app/v1/vms/990204/411/snapshots/before-upgrade \
  -H "Authorization: Bearer nr_live_..."

A name must start with a letter and use letters, digits, hyphens or underscores. A duplicate name answers 409; a sixth snapshot answers 422 with code snapshot_limit, so delete one first.

Backups. Start one on demand, or turn on the schedule with a retention:

curl -s -X POST https://api.amoni.app/v1/vms/990204/411/backups \
  -H "Authorization: Bearer nr_live_..."
# { "success": true, "data": {
#   "operation_id": 88,
#   "message": "Backup started (snapshot mode — no downtime). Track it on the Activity page." } }

curl -s -X POST https://api.amoni.app/v1/vms/990204/411/backups/schedule \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"enabled": true, "retention": 5}'

A backup is asynchronous: the call returns 202 with an operation_id. Follow it on the Activity log or by polling GET /v1/operations/{id}, or subscribe a webhook and let the operation.succeeded event tell you it finished. List backups with GET /v1/vms/{account}/{id}/backups, restore one with POST …/backups/{id}/restore, and delete one with DELETE …/backups/{id}.

Questions we get

• Does a snapshot count as a backup? No. It lives on the same storage, so it does not survive the host. Use it as an undo point, not as your only copy.
• Will a snapshot slow my instance down? An old snapshot ties up storage and can add write overhead as blocks diverge. Keep them short-lived and delete when done.
• How many backups are kept? Your schedule's retention decides. On-demand backups you take yourself stay until you delete them.
• Is there downtime? No. Backups run in snapshot mode while the instance keeps running. A rollback or a restore does interrupt the instance while it happens.
• What about bare-metal servers? These are cloud features. Bare metal is protected differently; see reinstall and install profiles.

Still stuck?

Open a support ticket with the instance and, for a backup, the operation id. We can see the job and the backup store from our side.