PROTECT YOUR DATA. RESTORE WITH CONFIDENCE.

We solved the problem of Kubernetes-native disaster recovery.

The Backup Company Retour backs up resource manifests and persistent volumes without complex configuration hassle. It can complete the full disaster recovery cycle. Simply point to a deployment and it will discover volumes automatically.

Protect Your Clusters, Today.

Get started Contact us

retour backup

$ kubectl apply -f backup.yaml
backup.retour.thebackup.company/my-backup created

$ kubectl get backups
 NAME         PHASE      PROGRESS   AGE
my-backup    Completed  100%       2m

$ kubectl apply -f restore.yaml
restore.retour.thebackup.company/my-restore created

$ kubectl get restores
 NAME         PHASE      PROGRESS   AGE
my-restore   Completed  100%       1m

Built for the way you work

Operator-driven, storage-agnostic, and designed for production. Retour discovers corresponding volumes automatically. No need to manually type resources, PVCs, or paths. Suited for novice and expert alike. Drills restore your backups on a schedule, so you know they work.

Built with reliability in mind by a Team of Site Reliability Engineers, based on years of experience managing fleets of cloud and on-premise infrastructure with interesting incidents, including witnessing burning a datacenter.

Kubernetes-native

Every resource is a Kubernetes object. Retour backs up data along with the manifest for easy recovery. No custom formats or migration tools. Migrate between clusters on different providers with ease.

Volume snapshots

Native CSI volume snapshots for consistent, crash-consistent backups of your persistent data. If your Kubernetes cluster has driver supporting CSI snapshots, Retour can support it.

Encryption at rest

Backup data can be encrypted with custom keys at rest. Use rclone crypt remotes for your storage. Secure important data in the age of LLMs.

OIDC & SAML

Connect as many identity providers as you run: Okta, Keycloak, Entra ID, Ping, JumpCloud, OneLogin, CyberArk, Dex, or any OIDC issuer. Each gets its own button on the login page, and groups map to Retour roles per provider.

Filtering and paths

By default Retour backs up everything. Filters exclude resource types, names by regex, or labels, and pvFilters narrow a volume to the directories you care about, so you do not snapshot a whole disk to keep one folder.

Scheduled backups

Run backups on a cron schedule with configurable retention. Keep last N successful backups, automate disaster recovery.

Declarative & GitOps

Define backups and restores as Kubernetes CRDs. Version control your backup config, apply with kubectl. GitOps-ready.

Secrets

Secrets stay in the cluster by default. Bring them back with an external secret operator, IAM roles, or plain Kubernetes Secrets, whichever fits your security model. To put them in the backup instead, the opt-in encrypted stream needs a cluster-admin switch, an encrypted backend, and a passphrase of its own.

Dedicated UI

Retour is Kubernetes-native and can run without a UI. We also supply a web UI with OIDC and a YAML creator to help you build manifests for your infrastructure.

Observability

Track backup status, metrics, and logs. Prometheus-compatible. Know when backups succeed or fail.

Rclone-powered

One tool, 60+ storage backends. S3, Ceph, local, WebDAV, and many more. Mix and match to fit your infrastructure.

Restore drills

Schedules restore their newest backup into a scratch namespace on their own cron, run a check pod against the restored volumes, then clean the scratch namespace up. The outcome lands in the CR status, a Kubernetes event, and a Prometheus metric.

Verified on upload

Verification runs by default. After the transfer, the carrier compares what landed on the backend against the still-mounted source and decodes the stored metadata. A failed check fails the backup, so a Completed phase never sits on top of an empty bucket.

Immutable backups

S3 Object Lock retention is stamped on every uploaded object: volume data, metadata, and manifests. Nothing can delete them while the lock holds, not even Retour, and a lock that cannot be applied fails the backup.

Incremental forever

The optional kopia engine deduplicates and uploads only what changed, run after run, on S3, Azure Blob, and Google Cloud Storage. Backup windows and storage bills stop growing with the cluster.

File-level restore

Browse a backup's file catalog in the UI, pick the paths you need, and restore only those, into the original claim or a different one. Getting one deleted file back does not require rolling back a namespace.

Whole-cluster & dynamic discovery

Protect a whole cluster with one CR. Discovery mode enumerates every resource type the API server serves, so operator CRs are captured instead of missed by a fixed list. Sensitive kinds are filtered out before anything is listed.

KMS & BYOK custody

AWS KMS or Vault Transit can wrap the encryption material, so only ciphertext is stored. Each job unwraps it into a short-lived secret, rotation is a rewrap, and a key-custody condition says whether the provider is down or access was denied.

Application-consistent databases

One exec session is held open across the snapshot window, with ready-made profiles for PostgreSQL, MySQL, MongoDB, Redis, and qemu-guest freeze. CloudNativePG clusters are handed to the database operator's own point-in-time recovery instead.

VMs and block volumes

KubeVirt VirtualMachines and DataVolumes are in the resource registry, and raw volumeMode: Block claims have a real data path. The device is streamed as a single image, with a SHA-256 recorded at backup and checked while it is written back.

Warm standby DR

A RestoreSync on the standby cluster polls the shared bucket, reads the metadata to see what the primary wrote, and replays it from a restore template. The two clusters never talk to each other. Workloads can land scaled to zero and be started on failover.

Migrate off Velero

Point a Restore at a Velero bucket and Retour imports the manifests, plus the volume data for backups kopia wrote. Imported content passes the same checks as a native restore, and the Velero repository is only ever opened read-only.

Fleet view & policies

See what is protected across every cluster in one place, and push backup policies out to them. Quotas cap how much each team can consume, and an append-only audit trail records who asked for what.

Restore controls

Map namespaces and storage classes, rewrite image references, patch manifests on the way in, and say what should happen to objects that already exist. Dry-run first and read the plan before anything is applied.

60+ storage backends

Backup to multiple places. AWS S3, Ceph, Minio, Google Cloud, Azure, Backblaze B2, Dropbox, SFTP, and many more. Built on standard protocols such as WebDAV or Object Storage, they work out of the box.

Amazon S3 Backblaze B2 Google Cloud Storage Microsoft Azure Blob Minio Ceph Cloudflare R2 DigitalOcean Spaces Hetzner Object Storage Wasabi WebDAV SFTP Nextcloud Dropbox Google Drive OneDrive Proton Drive MEGA rsync.net Local filesystem Crypt (encrypt any backend) Combine (multiple remotes)

Plus Alibaba OSS, Oracle Cloud, IBM COS, Scaleway, Tencent COS, and 50+ more.

Because nothing in the format is tied to a vendor, the same backup moves data between data centers. Back up in one place, restore in another: on-premise Ceph to a cloud provider, one region to the next, or between two providers that share nothing but the network. Namespaces and storage classes are remapped on the way in, so the target cluster does not have to look like the source.

Simple manifests

Engineers see how easy it is. Declarative backup and restore.

Backups

Create one-off or scheduled backups. Point to resources or namespaces. Retour discovers volumes automatically.

Backup

apiVersion: retour.thebackup.company/v1
kind: Backup
metadata:
  name: my-backup
spec:
  storageBackend: s3-production
  namespacedResources:
    - resourceType: Deployment
      namespace: production
      name: webapp
    - resourceType: Service
      namespace: production
      name: webapp-service

Backup with resource filter

apiVersion: retour.thebackup.company/v1
kind: Backup
metadata:
  name: filtered-backup
spec:
  storageBackend: minio
  clusterResources:
    - resourceType: Namespace
      name: my-app
  resourceFilter:
    excludeResourceNames:
      - "^debug-"
      - "^test-"
    excludeResourceLabels:
      matchLabels:
        exclude-from-backup: "true"

Scheduled backup

apiVersion: retour.thebackup.company/v1
kind: BackupSchedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  storageBackend: s3-production
  namespacedResources:
    - resourceType: Deployment
      namespace: production
      name: webapp
  excludePVs: false
  successfulBackupsHistoryLimit: 7

Restores

Restore from a backup by name or from an external path. Restore everything or select specific resources.

Restore

apiVersion: retour.thebackup.company/v1
kind: Restore
metadata:
  name: my-restore
spec:
  backupName: my-backup
  storageBackend: s3-production

Restore with selective resources

apiVersion: retour.thebackup.company/v1
kind: Restore
metadata:
  name: selective-restore
spec:
  backupName: my-backup
  storageBackend: s3-production
  resourcesToRestore:
    - kind: Deployment
      name: webapp
      namespace: production
    - kind: PersistentVolumeClaim
      name: webapp-data
      namespace: production

Restore from external path

apiVersion: retour.thebackup.company/v1
kind: Restore
metadata:
  name: external-restore
spec:
  backupPath: /backups/2024-01-15/my-backup
  storageBackend: s3-production

Storage backends

Configure where backups are stored. S3, Minio, local, or wrap any backend with encryption.

StorageBackend (S3)

apiVersion: retour.thebackup.company/v1
kind: StorageBackend
metadata:
  name: s3-production
spec:
  type: s3
  s3:
    bucket: my-backup-bucket
    region: us-east-1
    secretRef:
      name: s3-credentials
      keys:
        accessKeyID: access-key
        secretAccessKey: secret-key

StorageBackend (S3 with Minio)

apiVersion: retour.thebackup.company/v1
kind: StorageBackend
metadata:
  name: minio
spec:
  type: s3
  s3:
    endpoint: https://minio.example.com
    bucket: retour-backups
    useSSL: true
    secretRef:
      name: minio-credentials
      keys:
        accessKeyID: access-key
        secretAccessKey: secret-key

StorageBackend (encrypted)

apiVersion: retour.thebackup.company/v1
kind: StorageBackend
metadata:
  name: s3-encrypted
spec:
  type: crypt
  crypt:
    backend: s3
    s3:
      bucket: my-backup-bucket
      region: us-east-1
      secretRef:
        name: s3-credentials
        keys:
          accessKeyID: access-key-id
          secretAccessKey: secret-access-key
    secretRef:
      name: crypt-credentials
      keys:
        password: encryption-password

Proof, continuity, and governance

Prove the backups restore, keep a standby cluster warm, sweep an entire cluster, and cap what each team can use.

Scheduled backup with restore drills

apiVersion: retour.thebackup.company/v1
kind: BackupSchedule
metadata:
  name: nightly
spec:
  schedule: "0 3 * * *"
  storageBackend: s3-production
  namespacedResources:
    - resourceType: Namespace
      name: shop
  retention:
    keepDaily: 7
    keepWeekly: 4
    keepMonthly: 12
  drill:
    schedule: "0 5 * * 0"
    check:
      image: postgres:17
      command: ["sh", "-c", "test -s /data/db-data/PG_VERSION"]

Warm standby (RestoreSync)

apiVersion: retour.thebackup.company/v1
kind: RestoreSync
metadata:
  name: shop-dr
  namespace: retour
spec:
  storageBackendRef: shared-dr-bucket
  pollInterval: 15m
  mode: Latest
  selector:
    scheduleName: nightly
    namespaces: [shop]
  restoreTemplate:
    namespaceMapping:
      shop: shop
    scaleWorkloadsToZero: true

Whole-cluster backup

apiVersion: retour.thebackup.company/v1
kind: Backup
metadata:
  name: cluster-sweep
spec:
  scope: Cluster
  storageBackend: s3-production
  resourceDiscovery: Dynamic
  excludedNamespaces:
    - staging
    - sandbox

Import from Velero

apiVersion: retour.thebackup.company/v1
kind: Restore
metadata:
  name: import-legacy-app
spec:
  veleroImport:
    backendRef: velero-bucket
    path: backups/daily-20260830020000
    volumeData:
      enabled: true
      repoPassword:
        name: velero-repo-credentials
  namespaceMapping:
    legacy-app: legacy-app
  dryRun: true

Immutable, incremental backend

apiVersion: retour.thebackup.company/v1
kind: StorageBackend
metadata:
  name: s3-locked
spec:
  type: s3
  engine: kopia
  s3:
    bucket: retour-immutable
    region: us-east-1
    serverSideEncryption: "aws:kms"
    immutability:
      mode: COMPLIANCE
      retainDays: 30
    secretRef:
      name: s3-credentials
      keys:
        accessKeyID: access-key
        secretAccessKey: secret-key
        kopiaPassword: kopia-password

Per-tenant quota

apiVersion: retour.thebackup.company/v1
kind: BackupQuota
metadata:
  name: team-a
spec:
  namespaces: ["team-a", "team-a-staging"]
  limits:
    maxActiveBackups: 2
    maxBackupsPerDay: 20
    maxSchedules: 5
    minScheduleInterval: 15m
    maxTotalSizeBytes: 500000000000

How it works

Create a Backup CR. Specify namespaces, PVCs, and storage backend.

→

Retour operator spawns worker pods. Volume snapshots are created via CSI.

→

Carrier pods use rclone to copy data to your S3, Ceph, or local storage.

Try Retour today

Deploy Retour with the operator, configure your storage backends, and start backing up. Easier and hassle-free.

Why this was created in the first place

You shouldn't need to be an expert. Point to the deployment. Unless you explicitly specify otherwise, Retour backs up all mounted volumes. No hassle of coding every resource, PVC, or path into configuration. During downtime there is no time for blaming tools, you need to get your data back up and running quickly.

With typical Kubernetes backup tools, you must explicitly specify which resources to backup, which PVCs, which paths, and which storage backends. Defaults often capture nothing useful. Configuration is verbose and easy to get wrong. Worse: many tools report backup status as Completed even when no Persistent Volume data was actually stored. You only discover the gap when disaster strikes.

Examples of issues: