Add an offsite PBS datastore to Proxmox VE in five minutes.

An offsite copy is what turns local Proxmox backups into real backups. This guide adds a remote Proxmox Backup Server datastore to Proxmox VE, turns on client-side encryption and proves the restore works. The steps work with any remote PBS; we use ours as the example.

Start the guide See datastore plans

About five minutes
Works with any remote PBS
Client-side encryption

Proxmox VE shell

# after setup: one run by hand

root@pve:~# vzdump 100 \

--storage offsite \

--mode snapshot

INFO: Finished Backup of VM 100

# then the step most people skip:

# restore it as VM 9100, boot it

Before you start

Four values from your provider.

Your ServerCrate portal shows them when you create the datastore. The token secret is shown once, so copy it somewhere safe.

Server

pbs.servercrate.net, port 8007, over TLS.

Datastore

The datastore name from your portal, for example sc-XXXX.

API token

A token user such as user@pbs!pve and its secret. Ours is backup-only: it cannot delete or prune.

Fingerprint

Leave it empty for ServerCrate: our certificate is publicly trusted. A remote PBS with a self-signed certificate needs it pinned.

Step by step

From an empty storage list to a tested restore.

Get your connection details. Create the datastore in your portal and copy the server, datastore name, token user and token secret.
Add the storage. In Proxmox VE open Datacenter, Storage, Add, Proxmox Backup Server. Fill in Server, Datastore, Username (the token) and Password (the token secret), or use the shell command below.
Leave retention to the server. On ServerCrate, tick Keep all backups: retention runs on our side and the token cannot prune. On another PBS, set the prune policy you want here.
Turn on client-side encryption. Under Encryption choose Auto-generate a client encryption key and save a copy somewhere that is not your cluster. The remote server only ever sees encrypted chunks.
Schedule the job. Datacenter, Backup, Add: pick the new storage, snapshot mode and a nightly time. Incremental backups and deduplication keep the nightly transfer small.
Test a restore. Restore one guest to a new VM ID and boot it. A backup you have never restored is a hope, not a backup.

step 2 from the shell

root@pve:~# pvesm add pbs offsite \

--server pbs.servercrate.net \

--port 8007 \

--datastore DATASTORE \

--username 'USER@pbs!TOKEN' \

--password 'TOKEN_SECRET' \

--content backup \

--prune-backups keep-all=1 \

--encryption-key autogen

/etc/pve/storage.cfg

# what step 2 writes

pbs: offsite

server pbs.servercrate.net

port 8007

datastore DATASTORE

username USER@pbs!TOKEN

content backup

prune-backups keep-all=1

encryption-key KEY_FINGERPRINT

Keep the single quotes around the token name: the ! is special to the shell. Lose the encryption key and the backups cannot be restored, by anyone, including us.

Need the offsite target?

Offsite datastores from ServerCrate.

A dedicated PBS datastore in Los Angeles with a hard quota, a backup-only token, retention and weekly verify run by our team, and no egress or restore fees.

Plan	Datastore	Price
PBS-100	100 GB	$3/mo or $30/yr
PBS-500	500 GB	$7/mo or $70/yr
PBS-1T	1 TB	$12/mo or $120/yr
PBS-2T	2 TB	$22/mo or $220/yr

See plan details, including retention per plan.

FAQ

Questions people ask at step two.

Not for ServerCrate. Our certificate on pbs.servercrate.net is publicly trusted, so the Fingerprint field stays empty. A remote PBS with a self-signed certificate needs its fingerprint pinned; that server's dashboard shows it.

The backups cannot be restored, by anyone, including us. Save the key, or its paper backup, somewhere that does not depend on the cluster it protects.

Token names contain an exclamation mark, which bash treats as history expansion. Single quotes pass it through unchanged.

No. Keep local backups for fast restores and add the offsite datastore as the copy that survives losing the site. That is the 3-2-1 rule.