OpenShift Backup and Restore (OADP + Cohesity)

Topic – OpenShift Backup and Restore (OADP + Cohesity)

Overview

Define how OpenShift clusters implement backup and restore using OADP (Velero-based), with Cohesity providing the backup storage target plus policy-driven protection and retention (and optional immutability controls when configured).

Note: "immutability" in this context refers to Cohesity immutability controls (for example, immutable snapshots) and depends on configuration; it should not be read as a blanket WORM or S3 Object Lock guarantee (see Cohesity DataProtect datasheet).

This topic describes the automation contract: Git-approved configuration, repeatable execution, and evidence-based restore testing.

This fits the broader cross-domain automation model described in intent-to-runtime-automation-flow.

Context

Backup and restore is part of Backup and Disaster Recovery. OpenShift-specific backup must be Kubernetes-native and must support:

• restoring Kubernetes objects (namespaces, CRDs, RBAC, selected cluster-scoped resources)
• restoring application data stored in persistent volumes (method depends on storage class)
• proving restore works through repeatable exercises (not just “backup succeeded”)

This topic is used by work packages that depend on restore capability:

• WP-16 Business Continuity and Disaster Recovery
• WP-13 Virtual Machines as a Service (VMaaS)

Protection modes (OpenShift + OpenShift Virtualization)

• Kubernetes-native (default): OADP/Velero protects namespaces, PVCs, and selected cluster-scoped resources; data lands on Cohesity SmartFiles.
• VM guest-level (when required): Cohesity agents inside VM operating systems protect file data; restores are file-level or full-VM.
• Cohesity platform registration (optional): register OpenShift in DataProtect; Cohesity deploys data mover pods to protect PVCs/namespaces under protection groups.

Applicable Principles

• Data Protection — backup and retention tiers are enforced.
• Reliability and Resilience — restore workflows protect continuity.
• Automation First — backups are scheduled and validated automatically.

Decisions

• Standard mechanism: use OADP as the supported operator for OpenShift backup and restore.
• Target storage: store backup data in Cohesity-provided object storage (S3-compatible endpoint, typically SmartFiles).
• Protection policy: Cohesity DataProtect protection groups apply retention and optional immutability controls (when configured) and provide run history in Helios.
• Change control: OADP installation and configuration (locations, schedules, retention parameters) are managed through Automation; production changes require Git review.
• Evidence: every environment must run periodic restore tests and retain outcomes as evidence for DR readiness.

Current State

Baseline design (target state)

• OADP operator is installed as a platform add-on.
• OADP configuration is expressed as Kubernetes resources (including DataProtectionApplication and Velero CRDs like BackupStorageLocation, VolumeSnapshotLocation, and Schedule).
• Backup data is written to the Cohesity SmartFiles S3 endpoint and registered in DataProtect protection groups for retention and optional immutability controls (when configured).

Automation flow (concrete)

1. Git defines OADP resources (DataProtectionApplication, BackupStorageLocation, VolumeSnapshotLocation, Schedule).
2. Argo CD syncs; OADP configures Velero and credentials.
3. Cohesity DataProtect applies protection group policy to the S3 target (retention and optional immutability controls when configured) and tracks run history in Helios.
4. Evidence comes from Velero Backup/Restore objects, Cohesity protection group run history, and restore drill results.

VM guest-level workflow (Cohesity agents)

1. Install Cohesity agents in VM operating systems used by OpenShift Virtualization.
2. Register VMs in DataProtect and assign protection groups.
3. Run backups; restore files or full VMs via DataProtect recovery workflows.

What “done” looks like

• A new cluster receives OADP via GitOps without manual post-install steps.
• A restore test can be executed from an isolated namespace into a clean target namespace and produces a pass/fail result.

Future Work

• Define backup tiers and schedules mapped to business RPO/RTO targets (see WP-16 Business Continuity and Disaster Recovery).
• Decide the persistent volume data protection method per storage class (CSI snapshots where supported, file-level backup where required).
• Define namespace and cluster-scoped restore boundaries (which cluster resources are allowed to be backed up and restored).
• Publish a minimal “restore drill” runbook used for acceptance and recurring exercises.