Skip to content

Disaster Recovery

Every Retour backup is self-contained on the storage backend. Next to the volume data, the carrier writes a metadata JSON document (backup-operation-<id>-metadata.json) and the cluster manifest YAMLs (operation-cluster-metadata-<id>/). A restore is driven entirely from these documents, so you can restore a backup even when:

  • The backup was created in another cluster
  • The Backup CR was deleted but the data remains in storage
  • The whole cluster is gone and you're rebuilding from scratch

There's no discovery or import step. Point a Restore at the backup's path and go.

Restoring without a Backup CR

Create a Restore with spec.backupPath set to the backup's directory on the backend (the status.backendPath of the original Backup CR, if you still have it — otherwise list the bucket and pick the backup directory):

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

storageBackend is required with backupPath — it names the StorageBackend CR whose credentials the restore uses.

What happens under the hood

The operator adds a metadata-fetch init container to the restore worker pod. The init container downloads the backup's metadata documents and manifests from the backend into a volume shared with the worker. The worker parses them — filtered by the backup's job UUID, so other backups under the same prefix are untouched — recreates the PVCs and Kubernetes resources, and spawns carrier pods to copy the data back.

This is the same path every restore takes. Restores that reference a Backup CR by name just resolve the path from the CR's status first; after that, the backend metadata drives everything.

Backups from older Retour versions

Backups made before this architecture (when state lived in a database) also restore via spec.backupPath, as long as their data and metadata are still on the backend. The metadata format is versioned (schemaVersion in pkg/backupmeta) and older files are tolerated.

Restoring into a different cluster or data center

Nothing in the stored format is tied to a vendor: the data goes through rclone or kopia, and the manifests are plain YAML. A backup taken in one data center restores in another, whether that is on-premise Ceph to a cloud provider, one region to the next, or two providers that share nothing but the network.

The target cluster does not have to look like the source. spec.namespaceMapping and spec.storageClassMapping cover the differences, spec.imageRewrites handles a registry that moved, and spec.resourceModifiers patches anything else on the way in. Start with spec.dryRun: true and read status.plannedObjects before applying.

Two details matter when the clusters differ. Restored PVCs keep their original access modes and volume mode, so a claim that was ReadWriteMany comes back ReadWriteMany and needs a storage class that can provide it. And namespace SCC UID ranges from the source are dropped by default, so the target allocates its own; spec.preserveNamespaceUIDRange: true keeps them for the rare case where that is what you want.

Restoring on a schedule

A standby cluster can do all of this by itself: see RestoreSync.