Proxmox backup to S3-compatible storage

Your Proxmox VE cluster already makes backups with vzdump, and Proxmox Backup Server (PBS) deduplicates and verifies your VMs and containers. But if everything lives in the same rack, a fire, a theft or ransomware that reaches the hypervisor takes it all out. OtterStorage gives you the third link of the 3-2-1 rule: an offsite, S3-compatible destination where you can keep an immutable copy of your backups.

The problem

Local copies are fast to restore, but they don't protect against a site disaster. The most common Proxmox configurations leave a single point of failure:

• The vzdump dumps are written to local or NFS storage that is in the same building as the hypervisor.
• The PBS datastore, however good its deduplication and verification, is still a single physical copy.
• Ransomware with access to the host can encrypt or delete both the VMs and their backups if they are mounted or accessible from the same system.
• Replicating to a second PBS reduces the risk, but it's usually on the same network or the same provider.

The 3-2-1 rule sums it up well: 3 copies, on 2 different media, with 1 offsite. That "1 offsite" is exactly what's missing in most installations.

The OtterStorage solution

OtterStorage is S3-compatible object storage. You point your tools to the endpoint https://es-mad-1.s3.otterstorage.io, create a bucket with its credentials (per-bucket access key + secret key) and sync your Proxmox backups there as a third offsite copy. Key points:

• Truly offsite: your copies leave your datacenter with no need to set up a second site.
• Clear per-TB cost: you pay for what you store. We don't charge for requests or deletes, so frequent syncs and rotation of old copies don't penalize your bill.
• Immutability: with Object Lock (OtterVault) and bucket-level Legal Hold you can guarantee that a copy is not altered or deleted for a period, not even with compromised credentials.

There are several practical approaches depending on whether you use PBS or vzdump directly. We detail them below; if you want the general context of offsite backups, you also have our backups page.

How to set it up

Approach A — rclone: sync the PBS datastore or the vzdump dumps

The most direct approach is to copy to S3 what's already on disk. It works for both the PBS datastore directory and the vzdump dump folder (by default /var/lib/vz/dump).

1. Install rclone on the PBS host or on the Proxmox VE node:

apt update && apt install -y rclone

2. Create a generic S3 remote. You can use the wizard with rclone config or write directly to /root/.config/rclone/rclone.conf:

[otter]
type = s3
provider = Other
access_key_id = TU_ACCESS_KEY
secret_access_key = TU_SECRET_KEY
endpoint = https://es-mad-1.s3.otterstorage.io
region = eu-mad
acl = private

3. Check access by listing the bucket you created in the panel (for example proxmox-backups):

rclone lsd otter:proxmox-backups

4. Sync the backup directory to the bucket. sync makes the destination match the source (uploads what's new and removes from the destination what's no longer in the source):

# Volcados vzdump
rclone sync /var/lib/vz/dump otter:proxmox-backups/dump \
  --transfers 4 --checkers 8 --fast-list --stats 30s

# O el datastore de PBS (sustituye por la ruta real de tu datastore)
rclone sync /mnt/datastore/principal otter:proxmox-backups/pbs \
  --transfers 4 --checkers 8 --fast-list --stats 30s

5. Schedule the sync with cron. Edit the crontab with crontab -e and run it, for example, every night at 03:30:

30 3 * * * /usr/bin/rclone sync /var/lib/vz/dump otter:proxmox-backups/dump --transfers 4 --checkers 8 --fast-list --log-file /var/log/rclone-otter.log

A note on PBS: the datastore uses a structure of deduplicated "chunks". Copying those files with rclone gives you a faithful backup of the datastore that you can restore by mounting it again on a PBS; treat it as a coherent block and avoid syncing while garbage collection tasks are in progress.

Approach B — restic pointing directly to OtterStorage

If you prefer the backup tool itself to handle encryption, snapshots and retention against S3, restic is an excellent option for sending /var/lib/vz/dump (or the datastore) to OtterStorage. Restic encrypts client-side, deduplicates and applies retention policies.

1. Install restic and export the bucket credentials:

apt install -y restic

export AWS_ACCESS_KEY_ID=TU_ACCESS_KEY
export AWS_SECRET_ACCESS_KEY=TU_SECRET_KEY
export RESTIC_REPOSITORY="s3:https://es-mad-1.s3.otterstorage.io/proxmox-restic"
export RESTIC_PASSWORD="una-frase-larga-y-secreta"

2. Initialize the repository (first time only):

restic init

3. Back up the dump folder:

restic backup /var/lib/vz/dump --tag proxmox --tag offsite

4. Apply a retention policy and clean up the rest. Remember that we don't charge for requests or deletes, so running forget --prune frequently adds no cost:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

5. Verify the integrity of the repository periodically:

restic check

Keep the RESTIC_PASSWORD variable in a safe place: without it nothing can be restored. To automate, place the exports in a /root/.restic-env file with 600 permissions and load it from a cron task.

Approach C — native PBS sync jobs + S3 as a third copy

Proxmox Backup Server lets you define a remote (another PBS instance) and create sync jobs that replicate datastores between instances. It's a very solid PBS-to-PBS replication layer for the second copy. OtterStorage fits perfectly as a third copy: you sync with rclone (Approach A) the sync job's target datastore to S3, so the chain is complete:

• 1st copy: local PBS datastore, with verification and deduplication.
• 2nd copy: PBS sync job to a second PBS (another node or site).
• 3rd copy: rclone of the datastore to https://es-mad-1.s3.otterstorage.io, offsite and immutable.

Recommended immutability with Object Lock

So that a compromised copy on the host can't alter what's already in OtterStorage, enable Object Lock (OtterVault) when creating the bucket and, if you need it, bucket-level Legal Hold. With a retention period in compliance mode, not even stolen credentials can delete or overwrite the protected objects until the retention expires. It's the most effective defense against ransomware on your backups. Check the exact steps in the documentation.

Benefits

• Offsite without a second datacenter: you meet the "1 offsite" of the 3-2-1 rule by pointing to an S3 endpoint.
• Predictable per-TB cost: you're billed for what's stored, with no fine print.
• No charges for requests or deletes: sync often and rotate old copies without fear of inflating the bill with operations.
• Real immutability: Object Lock and Legal Hold protect your copies against malicious deletion or encryption.
• Compatible with what you already use: rclone and restic work with any vzdump or PBS workflow, without changing your operations.

Got questions about the endpoint, the eu-mad region or creating buckets with Object Lock? It's all in the documentation.