Snapshots vs Backups on Amóni Cloud

A cloud instance has two kinds of protection, and they aren't interchangeable. A snapshot freezes the instance exactly as it is now, so you can jump back to that moment. A backup is a full copy on separate storage, which means it's still there when the instance, or the machine it runs on, is gone. Take a snapshot before a risky change. Rely on backups for everything else.

Snapshots: an undo button

A snapshot records the instance's disk (and its memory, if you ask) in place, on the same storage. Taking one is close to instant, and a rollback puts the instance back in that state within seconds. So a snapshot is what you want right before anything you might need to undo: a kernel upgrade, a config change, a migration you're not sure about. Snapshot, make the change, and roll back if it goes wrong.

What a snapshot isn't is a safe copy. It sits on the same storage as the instance, so it's no help if that storage or the host fails. It also holds on to every disk block that's changed since you took it, which means an old snapshot quietly grows and ties up space. You get five per instance, so delete the ones you're finished with. Treat them 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 that doesn't depend on the instance or the host it runs on. That independence is what makes it disaster recovery. If the instance is destroyed, rebuilt or lost, a backup can bring it back. Backups run in snapshot mode, which means the instance keeps running while the copy is taken. No downtime.

Run a backup on demand, or set a schedule so one gets taken every night and the old ones are pruned to a retention you pick. A backup is slower than a snapshot and needs storage of its own. That's the trade you make for a copy that outlives the instance.

Which to use

Short version: snapshot before you touch something, and back up so you can sleep.

In the portal

Find your instance under Virtual Machines and go to its Snapshots and Backups tabs. On Snapshots, Take snapshot asks for a name and whether memory should be included, and every row gets Roll back and Delete. On Backups, Back up now starts one right away, Schedule switches on the nightly job and sets how many to keep, and every backup has its own Restore and Delete.

With the API

Both sit under the instance and need the VMs scope (vms.write), while listing only needs read. The path holds your cloud account id and the instance id, both of which you'll find in GET /v1/vms. Keys and scopes are explained in Getting started with the Amóni API.

Snapshots. Here's how to take one, list them, roll back and 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_..."

Names start with a letter and use only letters, digits, hyphens or underscores. Reuse a name and you get 409. A sixth snapshot gets 422 with code snapshot_limit, so delete one before you take another.

Backups. Start one on demand, or switch on the schedule and give it 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}'

Backups are asynchronous, so the call returns 202 with an operation_id. Track it on the Activity log or by polling GET /v1/operations/{id}, or subscribe a webhook and let the operation.succeeded event tell you when it's done. To list backups, use 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 won't survive the host. Treat it as an undo point, never as your only copy.
• Will a snapshot slow my instance down? An old snapshot ties up storage, and it can add write overhead as blocks diverge. Keep them short-lived, and delete each one when you're done.
• How many backups are kept? That's up to your schedule's retention. Backups you take on demand stay until you delete them.
• Is there downtime? No. Backups run in snapshot mode and the instance keeps running throughout. Rolling back or restoring is another matter: that does interrupt the instance while it happens.
• What about bare-metal servers? Both are cloud features. Bare metal gets protected differently; see reinstall and install profiles.

Still stuck?

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