Every time Versus backs up a device, it captures that device's full running configuration — sensitive operational data. This page explains how those backups are stored and protected: durable encrypted storage, encryption in transit and at rest, tightly-scoped access, versioning and retention, and the guarantees that apply to on-premises and air-gapped deployments.
Backups live in redundant object storage, not on an ephemeral server disk — they survive restarts, redeploys, and hardware failures.
Encrypted in transit (TLS) on the way to storage and encrypted at rest in the store — with a customer-managed key option for regulated environments.
Private storage with public access blocked; the platform reaches it through a tightly-scoped, short-lived credential — never a shared or public link.
Versioning guards against accidental overwrite or deletion; a configurable retention policy prunes old backups automatically.
Backups are written to object storage — the same class of highly-durable, redundant storage that underpins modern cloud platforms — rather than kept on a single server's local disk. This matters: a local disk is tied to one machine and is lost if that machine is replaced. Object storage replicates every backup across multiple devices and facilities, so a backup you took months ago is still there after upgrades, restarts, and infrastructure changes.
In the Versus SaaS, that store is a managed cloud object store. For on-premises deployments, it is a store you control (see below). In both cases a backup is addressed by a unique key and never exposed on a public path.
A backup is protected the entire way from the device to storage:
The platform reaches backup storage through a least-privilege credential scoped to a single bucket and to only the actions it needs (read, write, delete). On AWS, the recommended and default production posture uses an IAM role attached to the compute — which issues short-lived, automatically-rotating credentials — so there is no long-lived secret stored anywhere for an attacker to steal. Access is auditable through the storage provider's access logs.
Backup storage is versioned. If a backup were ever overwritten or deleted — whether by mistake or otherwise — the prior version is retained and recoverable. Combined with the provider's multi-facility replication, this means a backup is protected against both infrastructure failure and accidental loss.
You set a retention policy (in days). Versus automatically prunes backups older than the window and reclaims their storage — so you keep exactly the history you need without unbounded growth. When a backup is removed, its stored object is deleted along with its record, in one operation.
For customers who run Versus in their own datacenter, backup protection is designed around a single principle: your data stays in your network.
Backups can be written to your own object store — an in-house MinIO, your enterprise S3, or a persistent volume — so device configurations never leave your perimeter, and data-residency requirements are met by construction.
When a device is reached through a Versus collector, the device credential is injected locally by the collector and is never sent to the cloud. The backup bytes stream back over the collector's outbound bearer-authenticated WSS tunnel; the collector itself stores nothing.
| Protection | Versus SaaS | On-premises |
|---|---|---|
| Storage | Managed, redundant cloud object store | Your MinIO / S3 / persistent volume |
| In transit | TLS (+ bearer WSS via collector) | TLS (+ bearer WSS via collector) |
| At rest | Server-side encryption (KMS option) | Your store's encryption |
| Access | Scoped IAM role, short-lived creds | Credentials you control, in-network |
| Versioning | Enabled | Configurable in your store |
| Data residency | Region of your tenant | Never leaves your network |