Login

Backups & restore

Last updated: June 22, 2026

An untested backup is a guess. You only learn whether it works at the worst possible moment — the night you actually need it. The hard part of backups was never taking them; it's proving they restore, which means standing up a throwaway server, putting last night's data on it, and checking the result. That's enough work that most people skip it.

The American Cloud MCP server makes both halves cheap. Your assistant can snapshot your disks, set up off-site dumps, and — the part this page cares most about — run a full restore drill on a temporary VM and tear it down again, all from prompts you paste in. This recipe walks all three layers, then the drill.

Most steps here create or destroy infrastructure, which is a write operation. You'll need a read-write API key from console.americancloud.com/api-keys and the --allow-writes flag on the MCP server — see the overview for setup and safety. The "what should I be backing up?" inventory prompt near the end is read-only, so it's a good place to start before you enable writes.

Three layers of backup

These aren't alternatives — a real strategy uses all three:

  1. Snapshots — a point-in-time image of a whole disk, for fast rollback of an entire VM.
  2. Off-site dumps — application-level exports (a pg_dump, a tar of your uploads) pushed to object storage, so your data survives even if the VM and its disks are gone.
  3. The restore drill — periodically restoring a dump onto a fresh VM and verifying it, so you know the backups are good rather than hoping.

Layer 1: snapshots before a risky change

A snapshot captures the exact state of a volume at a moment in time. It's the right tool for whole-disk rollback: take one right before a deploy, an OS upgrade, or a schema migration, and if it goes wrong you can put the disk back the way it was. Snapshots are scoped to the volume — a VM's root disk and any attached data volumes are separate snapshots, so to capture an entire server you snapshot each of its volumes.

The natural moment is just before you change something. Paste this before tonight's deploy:

Snapshot every volume attached to my database VM, named with today's date and "pre-deploy", before tonight's deploy. Show me the cost estimate first.

What your assistant will do:

  1. Find the VM with list_vms, then list the volumes attached to it with list_block_storage_volumes (it can filter by the VM) so it knows the full set — root disk plus any data disks.
  2. Call get_cost_estimate_snapshot for each of those volumes and show you the price before taking anything. Snapshots are billed for the storage they occupy, so this matters when a VM has large disks. Nothing is billed until you confirm.
  3. On your go-ahead, call create_snapshot once per volume — RootDisk for the OS disk and DataDisk for attached volumes — naming each one like db-vm-root-2026-06-05-pre-deploy so you can tell them apart later.
  4. Report the snapshot IDs so you have them if you need to roll back.

To see what you've already got, ask any time — this is read-only:

List all my snapshots with their source volumes and dates, and flag any older than 30 days.

That runs list_snapshots (and get_snapshot for detail), so it works even before you enable writes. Old snapshots cost storage; once you're confident a change stuck, have the assistant clean them up with delete_snapshot (see rollback for the confirmation framing).

There's no recurring-snapshot scheduler — snapshots are something you take at a moment that matters (a deploy, a migration). For unattended, nightly protection, use off-site dumps (layer 2), which run on a cron on the VM. The two complement each other: snapshots for fast whole-disk rollback, dumps for durable off-server copies you can restore anywhere.

Layer 2: nightly off-site dumps to object storage

Snapshots live alongside your infrastructure. For data that has to survive the loss of the whole VM, you want an application-level export — a pg_dump or mysqldump for your database, a tar for your files — pushed off the server into a bucket.

The implementation lives in the object-storage recipe: see off-site backups from a VM for the full prompt and what the assistant sets up (a cron job, retention, the AWS CLI against your endpoint). Database dumps are the same shape — run the dump command, then upload the file:

On my database VM, set up a nightly cron job that runs pg_dump of my app's database, gzips it, and uploads it to my object storage bucket under db-backups/ named with the date. Keep the last 14 days and prune older ones.

In a coding agent that can reach the VM over SSH (like Claude Code), the assistant fetches the bucket's S3 keys, writes the dump-and-upload script, schedules it with cron, and confirms the schedule. Run it once by hand to make sure the first dump lands in the bucket.

Restoring one of these dumps costs nothing to download: American Cloud charges no egress fees, so pulling your backup back out is free, however large it is (why that matters). That's the property that makes the next section practical — you can drill restores as often as you like without paying to fetch the data each time.

Layer 3: the restore drill (the part everyone skips)

This is the centerpiece. A backup you've never restored is a hypothesis. The drill turns it into a fact: provision a small temporary VM, restore last night's dump onto it, verify the data, then throw the VM away. Run it monthly. It costs about an hour of the smallest VM tier.

Paste this:

I want to run a restore drill to prove my database backups actually work.

  1. Show me a cost estimate for the smallest Ubuntu VM, then create a temporary one for the drill (call it restore-drill so it's easy to spot). Wait for it to be running.
  2. Over SSH, install PostgreSQL, pull the most recent dump from my object storage db-backups/ bucket, and restore it into a fresh local database.
  3. Verify the restore: list the tables, show row counts for the main ones, and spot-check a few recent records so I can confirm they look right. Then start my app against this restored database and confirm it boots.
  4. Give me a short report: which dump you used, its date, the row counts, and whether the app came up.
  5. When I confirm I've seen the report, delete the temporary VM so it stops costing anything.

What your assistant will do:

  1. Price and provision a throwaway VM. It calls get_cost_estimate_vm for the smallest Ubuntu tier and shows you the number, then create_vm for a small VM (an isolated network and port 22 open is enough — nothing public needs to reach a drill box). It polls get_vm until the status reaches STARTED.
  2. Restore the dump onto it. Over SSH it installs PostgreSQL, fetches the latest object from your db-backups/ prefix (free to download — no egress fees), and restores it into a clean local database. It's reading from the bucket, so your real backups are never touched.
  3. Verify, don't assume. It lists tables, reports row counts for your main tables, spot-checks a few of the newest records, and boots your app pointed at the restored database to confirm the application actually comes up against the data — not just that the file imported without error.
  4. Report. You get the dump's date, the counts, and a pass/fail on the app boot. This is the artifact that tells you the backup is real.
  5. Tear it down. delete_vm destroys the temporary VM and its disk so it stops billing. This is destructive — the assistant will describe that the drill VM and everything on it (just the throwaway restore) is permanently gone, and clients that support confirmations will prompt before it runs. That's expected here: the drill VM is disposable by design, and deleting it is how the drill stays cheap.

The whole thing is one prompt and roughly an hour of a tiny VM. Put it on the calendar monthly. The first time it surfaces a dump that doesn't restore — a missing extension, a truncated upload, a schema the app no longer matches — you'll be very glad you found out during a drill instead of during an outage.

Rolling back when something goes wrong

When you actually need a backup, you have two tools, and they're not interchangeable. Tell your assistant what broke and let it explain which fits before it acts:

  • revert_snapshot — whole disk, back to a point in time. This restores the entire volume to the snapshot's state. Everything written to that disk since the snapshot was taken is overwritten and lost — it's destructive and can't be undone. It's the right move when a change corrupted the system broadly (a bad OS upgrade, a botched migration) and you want the machine exactly as it was at the snapshot. Because it's irreversible, the assistant will spell out the snapshot's timestamp and what you'd lose, and confirmation-capable clients will prompt before reverting.
  • Restoring a dump — surgical. Pulling a pg_dump back into the database fixes just the data, without touching the rest of the disk or the OS. It's the right move when the problem is data-level (a bad delete, a corrupted table) and the server itself is fine.

A good prompt names the symptom and asks for the recommendation first:

A migration I ran an hour ago corrupted the orders table. I have a pre-deploy snapshot of the database VM from before the migration and a nightly dump in object storage. Walk me through the options — which one loses the least, and what exactly would I lose with each — then do the one I pick.

The assistant lays out the trade-off (revert loses the last hour of everything on the disk; restoring just the dump loses changes since the dump but keeps everything else), waits for your choice, and only then runs the destructive step — with a confirmation.

What should I be backing up?

If you're not sure where the gaps are, have the assistant take inventory. This is read-only, so it works with a read-only key — a good first prompt before you enable writes:

Inventory my VMs and their attached volumes. For each one, tell me when it was last snapshotted, and flag any VM that has no recent snapshot and no obvious off-site dump job. Where am I exposed if a disk failed tonight?

What your assistant will do: it calls list_vms, then list_block_storage_volumes and list_snapshots (or list_block_storage_snapshots per volume) to line up each volume against its most recent snapshot. It can't see inside a VM's crontab without SSH access, but it can flag every volume with no recent snapshot and ask you which ones have a dump job — turning "I think we have backups" into a concrete list of what's covered and what isn't. Close the gaps with the prompts above.

Next steps