How to use Vultr Object Storage for server backups

Choose a tier

A subscription keeps its tier for good; to change it, Vultr says to create a new subscription and move the buckets. As of October 2026, Vultr's billing docs list:

Every tier includes 1,000 GB of storage and 1,000 GB of outbound transfer a month; inbound is free and extra outbound is $0.01 per GB. Faster tiers buy operations per second and throughput, mostly for Vultr servers in the same data center. A few large backup files a night need only Standard.

Archive is a fifth tier: $6 a month for 1,000 GB archived, 100 GB unarchived and 1 TB of transfer. Its lifecycle policy, which you can't change, moves objects to archive, where they show as 0 bytes and larger ones need a restore request before download. It suits archives kept for months, not tonight's restore.

Pick a location and its endpoint

A subscription lives in one location, and its hostname is the S3 endpoint for all its buckets. Vultr's FAQ lists:

Where a location has two hostnames, use the one your subscription shows. Keep backups in a different location from the servers they protect. The examples use a Standard subscription in New Jersey, ewr1.vultrobjects.com, and a bucket named acme-backups.

Create the subscription and a bucket

1. In the Vultr Console, go to Products, click Cloud Storage, select Object Storage and click Create Object Storage.
2. Select the tier, enter a name, select the location and click Create Object Storage.
3. Open the subscription, go to Buckets and click Create Bucket.
4. Enter a name of 3 to 63 characters, unique across all of Vultr Object Storage; 53 or fewer if you might enable Archival Storage on it.
5. Set Bucket Versioning and Object Lock, covered below, and click Create Bucket.

Uploads are private by default. Never add --acl public-read (AWS CLI) or -P (s3cmd) to a backup upload.

One key for the whole subscription

The subscription's Overview shows its S3 Credentials: hostname, access key and secret key. vultr-cli object-storage list and the API's s3_access_key and s3_secret_key fields return the same pair.

So isolate by subscription: servers that shouldn't reach each other's backups get separate ones, each $18.00 a month at Standard with its own 1,000 GB. If a key leaks, Vultr's advice is to regenerate it at once, with Regenerate Keys or vultr-cli object-storage regenerate-keys <id>, and every server using it then needs the new pair. Since the server's key can delete, keep a copy it can't reach; see protecting backups from ransomware.

Configure the AWS CLI

[profile vultr]
region = us-east-1
endpoint_url = https://ewr1.vultrobjects.com
retry_mode = standard
max_attempts = 5

[vultr]
aws_access_key_id = <access_key>
aws_secret_access_key = <secret_key>

• endpoint_url is the subscription's hostname with https://, which Vultr requires.
• Vultr ignores the region; its Terraform guide uses us-east-1.
• Vultr returns 429 when a subscription exceeds its tier's request rate and asks clients to back off. retry_mode = standard retries throttling error codes such as SlowDown, timeouts, and HTTP 500, 502, 503 and 504, with exponential backoff, and max_attempts = 5 allows five attempts instead of three. A bare HTTP 429 is on the AWS CLI's documented list for retry_mode = legacy, not standard: if the CLI gives up on Vultr's 429s, switch to legacy.

Run chmod 600 on both files, then list the bucket. No output means it's empty and the key works:

aws s3 ls s3://acme-backups/ --profile vultr

Or use s3cmd

Vultr's guides use s3cmd 2.0.0 or later, and so do its lifecycle examples. Keep Vultr's settings in their own file:

s3cmd --configure -c ~/.s3cfg-vultr

• Access Key and Secret Key: the subscription's pair. Default Region: keep US; Vultr ignores it.
• S3 Endpoint: ewr1.vultrobjects.com. DNS-style bucket+hostname:port template: %(bucket)s.ewr1.vultrobjects.com.
• Encryption password: optional; only uploads with -e use it, encrypting the file with GPG first. Use HTTPS protocol: Yes.

s3cmd -c ~/.s3cfg-vultr put /var/backups/web-01-2026-10-04.tar.gz s3://acme-backups/web-01/

-c picks the Vultr config file, and the trailing slash keeps the file's name. For many files at once, Vultr suggests s5cmd, which runs transfers in parallel.

Upload backups on a schedule

Name each backup by date, keep each server under its own prefix, and store a checksum beside it. This script archives two directories with tar and uploads both files:

#!/bin/sh
set -eu
NAME="web-01-$(date +%F).tar.gz"
cd /var/backups
tar -czf "$NAME" /etc /var/www
sha256sum "$NAME" > "$NAME.sha256"
for f in "$NAME" "$NAME.sha256"; do
  aws s3 cp "$f" "s3://acme-backups/web-01/$f" --profile vultr --only-show-errors
done
rm "$NAME" "$NAME.sha256"

set -eu stops at the first error, so a failed upload never reaches the rm. Make it executable with chmod 700 and schedule it:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
30 3 * * * root /usr/local/bin/vultr-backup.sh

The PATH line lets cron find aws in /usr/local/bin; see scheduling backups with cron. rclone works too, with provider = Other and the same endpoint, as in Vultr's migration guide.

Expire old backups with a lifecycle rule

Vultr documents lifecycle rules in S3's XML format, applied with s3cmd. This one deletes backups under web-01/ 30 days after upload:

<LifecycleConfiguration>
  <Rule>
    <ID>expire-web-01</ID>
    <Filter><Prefix>web-01/</Prefix></Filter>
    <Status>Enabled</Status>
    <Expiration><Days>30</Days></Expiration>
  </Rule>
</LifecycleConfiguration>

s3cmd -c ~/.s3cfg-vultr setlifecycle lifecycle.xml s3://acme-backups

• Filter with Prefix limits the rule to one server's backups. Put a Rule per prefix in one file: as on S3, a new configuration replaces the old one.
• Expiration deletes each object 30 days after it was created. Vultr's limits page says lifecycle policies run daily at 00:00 UTC, so a backup can outlive that by up to a day.
• s3cmd -c ~/.s3cfg-vultr getlifecycle s3://acme-backups reads the rule back.

Versioning and Object Lock

The bucket form has Bucket Versioning and Object Lock switches, and the API's bucket call takes enable_bucket_versioning and enable_object_lock. As of October 2026 Vultr's docs stop there: they don't describe retention modes or default retention, Object Lock isn't on the S3 compatibility list, and a bucket that has ever had versioning can never use Archival Storage.

With one key doing everything, versioning guards against mistakes, not against whoever holds the key, who can delete old versions too. Object Lock in compliance mode is what could stop that key, so test it on a throwaway bucket created with the switch on before relying on it:

aws s3api get-object-lock-configuration --bucket acme-lock-test --profile vultr

If it reports "ObjectLockEnabled": "Enabled", set a 1-day default retention with aws s3api put-object-lock-configuration, upload a file, find its version ID with aws s3api list-object-versions, and run aws s3api delete-object with that --version-id. Only an AccessDenied shows the lock holds.

Verify a backup

aws s3 ls s3://acme-backups/web-01/ --recursive --human-readable --summarize --profile vultr

--summarize adds the object count and total size. To prove a backup restores, download it with its checksum file and check both:

mkdir -p /tmp/restore-test && cd /tmp/restore-test && aws s3 cp s3://acme-backups/web-01/ . --recursive --exclude "*" --include "web-01-2026-10-04.tar.gz*" --profile vultr

sha256sum -c web-01-2026-10-04.tar.gz.sha256 && tar -tzf web-01-2026-10-04.tar.gz > /dev/null && echo OK

Trust your own checksum over response headers: Vultr notes that a download's Content-Length can differ from the file's size because responses are gzip-compressed, and that a multipart upload's ETag isn't an MD5 of the file. Then extract the archive, as in testing a restore.

What it costs

From the October 2026 prices above, per subscription and month:

Isolation has a price: the last row costs three times one shared subscription holding the same 900 GB. Weigh that against one key that can delete every server's backups.

Limits and common errors

• 100 buckets per subscription by default; support can raise it. Each tier caps operations per second and throughput for the whole subscription.
• Not supported: bucket replication, access logging, inventory, notifications and website hosting.
• Deleting a subscription deletes everything in it, irreversibly, and blocks its bucket names for at least 48 hours.
• The console can't delete a bucket holding more than 50,000 objects; empty it with s3cmd del --recursive --force first.

• HTTP 429: over the tier's rate limit. Retries with backoff handle it; for rclone, Vultr suggests --retries-sleep.
• InvalidAccessKeyId or SignatureDoesNotMatch: the keys were regenerated, or the endpoint is for another location than the subscription's.
• Missing required header for this request: Content-MD5 or checksum errors: newer AWS CLI versions add checksums by default, which not every S3-compatible service accepts. Add request_checksum_calculation = when_required and response_checksum_validation = when_required to the profile.

A Vultr bucket for a Vultr server

For a Vultr server, a bucket in another location covers a destroyed instance, a broken upgrade or trouble in one location, and unlike Vultr's snapshots, its files restore anywhere. It doesn't cover the account: the server, the bucket and its one key share a login and a bill. Vultr's own guidance is to keep backups somewhere separate, such as another region or an independent subscription under a different account. Keep a further copy with another provider, per the 3-2-1 rule. Vultr encrypts data at rest on its side; encrypt backups before upload if only you should be able to read them.

Frequently asked questions

What is the S3 endpoint for Vultr Object Storage?

The subscription's hostname, such as https://ewr1.vultrobjects.com in New Jersey or https://ams1.vultrobjects.com in Amsterdam. Vultr ignores the region setting, so us-east-1 works.

Can I create a Vultr Object Storage key for one bucket?

Not as of October 2026. A subscription has one key pair with access to all its buckets, so use a separate subscription for each set of buckets that needs its own key.

How much does Vultr Object Storage cost?

As of October 2026, Standard is $18.00 a month with 1,000 GB of storage and 1,000 GB of outbound transfer, then $0.018 per GB stored and $0.01 per GB transferred.

Does Vultr Object Storage support Object Lock?

The bucket form has an Object Lock switch, but as of October 2026 Vultr doesn't document retention modes or defaults. Check that a locked version refuses deletion before relying on it.

Can I change a Vultr Object Storage tier?

No. Create a subscription with the new tier and move the buckets to it.