Vultr snapshots: create, restore and automate with vultr-cli

Snapshots vs automatic backups

To keep a backup past rotation, or restore it to a different instance, convert it to a snapshot: click the camera icon (Convert) next to it in the backup list.

Turn on automatic backups from the instance's Backups tab: click Enable Backups, confirm, then pick a schedule from Schedule Backups. To set the schedule from the CLI:

vultr-cli instance backup create <instance-id> --type daily --hour 3

• --type is daily, weekly, monthly, daily_alt_even or daily_alt_odd (the every-other-day options).
• --hour is the hour of day, 0 to 23. Vultr's docs give these hours in UTC.
• --dow (0 to 6) sets the weekday for weekly. --dom (1 to 28) sets the day of the month for monthly.

Take a snapshot in the customer portal

1. If the instance runs a database, stop it or dump it to a file first (see below).
2. Go to Products, then Compute.
3. Click the instance to open its management page.
4. Open the Snapshots tab.
5. Enter a label that says why you took it, then click Take Snapshot (labelled Create Snapshot in some views).

Vultr says creation can take up to 30 minutes, depending on the instance's size.

Take a snapshot with vultr-cli or the API

vultr-cli is Vultr's official CLI. It reads your API key from the VULTR_API_KEY environment variable.

export VULTR_API_KEY=your-api-key

vultr-cli instance list

vultr-cli snapshot create --id <instance-id> --description "before nginx upgrade"

• --id (-i) is the instance ID from vultr-cli instance list. It is required.
• --description (-d) is optional, but it is how you tell snapshots apart later.

With API v2 directly:

curl "https://api.vultr.com/v2/snapshots" \
  -X POST \
  -H "Authorization: Bearer $VULTR_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"instance_id": "<instance-id>", "description": "before nginx upgrade"}'

Both return the new snapshot's ID. Pass that ID to vultr-cli snapshot get to check on it.

Is a snapshot of a running instance consistent?

Vultr doesn't stop your server to take an automatic backup, and its docs say booting from one is like rebooting after a non-graceful restart. A snapshot of a running instance carries the same risk. Filesystems handle that well. A database in the middle of a write may not.

• Dump databases before the snapshot with pg_dump, mysqldump or mongodump, so a clean copy sits in a file inside the image.
• Or stop the database service until the snapshot finishes, then start it again.

List and delete snapshots

vultr-cli snapshot list

The columns are ID, DATE CREATED, SIZE, COMPRESSED SIZE, STATUS, OSID, APPID and DESCRIPTION. You pay for COMPRESSED SIZE. Add --output json when a script reads the list.

vultr-cli snapshot delete <snapshot-id>

Delete takes one snapshot ID per call. destroy is an alias.

Restore a snapshot

Same instance. Restoring overwrites everything on the instance's disk. In the portal, open the instance, go to Snapshots, choose the snapshot and click Restore Snapshot. From the CLI:

vultr-cli instance restore <instance-id> --snapshot <snapshot-id>

• --snapshot (-s) is the snapshot ID. Use --backup (-b) instead to restore an automatic backup. Pass one, not both.
• In API v2, the same restore is a POST to /v2/instances/{instance-id}/restore with a snapshot_id in the JSON body.

New instance. Deploy a new instance and choose Snapshot as its image, or from the CLI:

vultr-cli instance create --region ewr --plan vc2-2c-4gb --snapshot <snapshot-id> --label web-01-restore

• --region can be any region. Vultr snapshots span all regions.
• --plan must have storage equal to or greater than the source instance's. You can't downsize with a snapshot.
• --snapshot is the snapshot ID, and --label names the new instance.

Automate snapshots with a retention count

Automatic backups keep only two copies. For a longer history, take snapshots from cron and delete the oldest. This script needs jq.

#!/usr/bin/env bash
set -euo pipefail

INSTANCE_ID="your-instance-id"
PREFIX="web-01-auto"
KEEP=7

vultr-cli snapshot create --id "$INSTANCE_ID" \
  --description "$PREFIX $(date -u +%Y-%m-%dT%H:%MZ)"

vultr-cli snapshot list --output json \
  | jq -r --arg p "$PREFIX " --argjson keep "$KEEP" \
      '.snapshots
       | map(select(.description | startswith($p)))
       | sort_by(.date_created) | reverse
       | .[$keep:][] | .id' \
  | xargs -r -n1 vultr-cli snapshot delete

• The description prefix marks the snapshots this script owns, so manual snapshots are never touched.
• jq keeps the script's snapshots, sorts them by date_created, skips the newest seven and prints the IDs of the rest.
• xargs -n1 calls delete once per ID, because the command takes one ID at a time.

0 4 * * * root /usr/local/bin/vultr-snapshot.sh >> /var/log/vultr-snapshot.log 2>&1

Cron doesn't read your shell profile, so export VULTR_API_KEY inside the script, or source it from a file only root can read. Run the job from a machine other than the instance it snapshots.

What it costs

As of October 2026, Vultr's documentation lists:

• Snapshots: $0.05 per GB per month, charged on the compressed size.
• Automatic backups: an extra 20% of the instance's base hourly or monthly price, prorated for the time the instance runs.

Sum the COMPRESSED SIZE column of vultr-cli snapshot list to estimate the monthly snapshot bill.

Limits

• An instance deployed from a snapshot needs storage equal to or greater than the source's. You can't downsize this way.
• Snapshots aren't available for Bare Metal instances.
• Automatic backups keep only the two most recent copies and don't include attached Block Storage.
• After an instance is destroyed, its two most recent backups remain for up to 7 days.
• Snapshot creation can take up to 30 minutes, and restores take 10 to 15 minutes longer than a standard deploy.

What a snapshot does not protect against

Vultr's own support docs say that without a snapshot or backup, a deleted instance can't be recovered through Vultr, and you would need external backups. Snapshots narrow that gap but don't close it, because they sit in the same account.

• Account loss. A suspended or closed account takes its snapshots and backups with it.
• A leaked API key. A key with full access can delete the instance and its snapshots alike.
• Short backup history. Two automatic backups may both postdate a problem you notice late.
• Block Storage and bad data. Attached Block Storage needs its own backups, and a snapshot taken after data went bad keeps the bad data.

Keep at least one copy outside Vultr: database dumps and file archives in storage at another provider, or on a machine you control. That is the off-site leg of the 3-2-1 rule. Restore from it now and then to prove it works.

Frequently asked questions

Can I restore a Vultr snapshot to a smaller plan?

No. The new instance needs storage equal to or greater than the source instance's. To move to a smaller plan, restore to a same-size instance and copy the data across.

Can I use a Vultr snapshot in another region?

Yes. Snapshots span all regions, so a snapshot of a London instance can deploy a new instance in New York.

How many automatic backups does Vultr keep?

The two most recent. After an instance is destroyed they stay for up to 7 days, so convert any you need into snapshots.

How much do Vultr snapshots cost?

As of October 2026, $0.05 per GB per month of compressed size. Automatic backups add 20% to the instance price.