What a Cold OpenShift DR Site Actually Has to Keep Ready

A cold recovery site can have no running OpenShift cluster and still require a surprising amount of infrastructure to be ready before the incident starts. If Veeam Kasten protects the production cluster to external object storage, the backups may survive a site loss while the recovery team still has to rebuild the platform that can use them.

One workable model looks like this: Kasten runs on the production OpenShift cluster, application backups and Kasten Disaster Recovery metadata are exported to S3-compatible object storage, and the recovery site does not keep a second OpenShift cluster running. The recovery cluster is built only after DR is invoked.

The design saves steady-state compute, but it moves work into the recovery clock. The important question is not whether a backup exists. It is whether the site can reproduce OpenShift, storage, Kasten, credentials, networking, and the application dependency chain fast enough to meet the recovery objective.

Cold does not mean empty

A cold site should not be confused with an unprepared site. The application platform may be absent, but the recovery dependencies cannot be discovered during the outage.

For this model, I would keep the bare-metal capacity identified, BMC access tested, recovery VLANs and IPAM reserved, API and ingress addressing defined, DNS and load-balancer changes documented, NTP reachable, firewall rules pre-approved, installer assets retained, and the required release, operator, Kasten, and application images available from a registry that survives loss of production. The S3 backup target, recovery credentials, and runbooks also have to remain reachable without the production identity or management stack.

Documented Red Hat documents a three-node compact Agent-based Installer topology whose three master nodes also act as worker nodes. The Agent-based Installer supports multiple installation platforms, including baremetal, vSphere, external, and none, and the prerequisites vary with that choice. For platform none, DNS name resolution and load-balancing infrastructure are explicit prerequisites, including API and application Ingress load balancing.[1] A cold build is reproducible only when the inputs for the chosen platform are already controlled.

Kasten gives the recovery data a place to survive the cluster

Documented Veeam Kasten distinguishes in-cluster snapshots from external backup locations. Its Location Profiles are what let Kasten create backups from snapshots, move application data across clusters, and import those exports into another cluster. S3 and S3-compatible object storage are supported location types.[2]

That makes external object storage the persistent recovery data plane in this design. Production can disappear, the recovery cluster can be nonexistent, and the exported application restore points can still be waiting somewhere independent of both.

That only works if the backup location survives the same event. The bucket must be in a failure domain separate from production, or replicated to one that is. An object store that disappears with the source site is not the recovery anchor this design assumes.

Documented Object Lock strengthens that role for Kasten backup workflows that support immutability. Kasten can use object-locking storage for immutable backups, and its documentation describes a protection period that keeps repository blobs locked long enough for an organization to detect and recover from an impact event. Generic Storage Backup and Shareable Volume workflows are exceptions: when they use an immutable-enabled location profile, Kasten treats the profile as non-immutable and ignores the protection period.[3] Immutability still does not provide compute, DNS, a registry, credentials, or an application database. It protects the recovery data while the rest of the recovery system is rebuilt.

KDR is what gets the backup control plane back

Losing the production cluster also means losing the Kasten instance that knows about policies, profiles, restore points, and its own catalog. Kasten Disaster Recovery exists to recover that Kasten state after events including destruction of the Kubernetes cluster.[4]

Documented Current Kasten documentation says a recovery on a new cluster starts by installing a fresh Kasten instance, recreating access to the backup location, supplying the original Cluster ID and KDR recovery material, validating the available KDR restore points, and then recovering the Kasten catalog before restoring applications.[4] Kasten also warns that the source Cluster ID, KDR passphrase or external secret-manager details, location profile information, and location credentials must be retained because catalog recovery is not possible without them.[4]

For cross-cluster recovery, exported restore points are the important part. Kasten documents that Quick DR modes can recover exported restore points on another cluster, while local restore points depend on the original storage snapshot references and can be unavailable after recovery on a different cluster.[4]

Architecture point The offsite backup is not enough by itself. The KDR metadata and the credentials required to rediscover that backup belong in the same recovery design.

The recovery platform comes before the application

A cold-site restore is a build sequence first and an application restore sequence second.

The recovery team activates the site network, provisions the designated bare metal, installs OpenShift, installs and validates the target storage layer, installs Kasten, reconnects the external object store, restores KDR, and only then has the control plane required to start application recovery. The recovery design should either reproduce the Kubernetes resource assumptions the application needs or predefine and rehearse Kasten restore transforms for target differences such as container image URLs and StorageClass settings.[6] If the application uses external databases, object stores, identity services, certificates, queues, or search platforms, those dependencies have their own recovery steps before the application is ready for users.

Red Hat's etcd backup belongs to a different problem. Red Hat documents etcd backup and restore as a way to return an OpenShift cluster to a previous cluster state, and it requires the backup to match the same OpenShift z-stream used for the restore.[5]

Architecture point I would keep etcd backup for supported recovery of the original cluster state, but I would not use etcd restore as the portability mechanism for a new cold-site cluster. Kasten exports and application-specific recovery procedures are the cleaner cross-cluster path.

The recovery clock is mostly serial

The hard part of cold-site RTO is that several steps cannot start until the previous one is usable. OpenShift has to exist before the storage operators and cluster services can settle. Storage has to be healthy before application PVCs can be restored. Kasten has to be running before KDR can repopulate the catalog. The application often has to wait for its database, identity, certificates, object data, and search services.

RTO is only half of the objective. For Kasten-managed workloads, the usable recovery point is bounded by the application protection and export cadence. If the DR object store is itself a replicated copy, replication lag also belongs in the RPO. The recovery test should record both the recovery point selected and the time needed to make it usable.

Some work can happen in parallel. Network activation, bare-metal preparation, credential retrieval, external database recovery, and application-team readiness can overlap when the dependencies allow it. The platform chain is still long enough that I would budget and measure each stage independently instead of writing one RTO number at the top of the design.

A useful recovery clock looks like this:

1. Declare the event, establish data authority, and select coordinated recovery points.
2. Activate the cold-site infrastructure, network, management, registry, and credentials.
3. Build OpenShift and the target storage platform.
4. Install Kasten, reconnect external object storage, and recover KDR/catalog state.
5. Recover native dependencies and Kasten-managed applications.
6. Validate privately, cut traffic, and start protection again from the recovery site.

Documented Kasten notes that restore time depends on the amount of captured data and the speed of the underlying storage because the data has to be rehydrated before application containers are recreated.[6]

In a cold-site design, repository-to-recovery-site throughput belongs in the RTO test for large PVCs. The object store, network path, data mover, and target storage can become the long pole even when the restore point itself is healthy. Measure those paths separately instead of using backup-job success as a proxy for recovery time.

External state breaks the simple restore story

Kubernetes resources and PVCs are only part of many packaged enterprise applications. The application may also rely on an external database, shared file data, search, object storage, identity, certificates, SMTP, APIs, and licensing services. Restoring the namespace does not make those services transactionally consistent with one another.

The runbook needs to state which system is authoritative for each data domain and how the recovery points are coordinated. A database recovery point that is twenty minutes older than the application files may be acceptable for one service and disastrous for another. That is an application decision, not something Kasten can infer from a successful export.

I would separate the protection methods instead of forcing everything through one repository. Use Kasten where Kubernetes resources and persistent volumes fit the workflow. Use native database, search, or object-store recovery methods where those products require their own consistency model. Bring them back together in the recovery order and test the whole application, not just the individual backup jobs.

Credentials can make good backups unusable

KDR is unusually clear about this failure mode. Kasten requires recovery information that is easy to leave inside the environment being protected: the original Cluster ID, KDR passphrase or external secret-manager reference, the location profile details, and the credentials for the backup location.[4]

If those values are available only through the failed cluster, its primary IdP, or one administrator's memory, the repository can be perfectly healthy and still be operationally useless. I would store recovery credentials in a system that survives loss of production, document a break-glass access path, and test the retrieval process during the recovery exercise.

The same rule applies to installer pull secrets, internal CA trust, registry credentials, BMC accounts, license activation information, and the administrative credentials needed to change DNS or load-balancer state. Recovery cannot depend on a management system that only exists inside the failed site.

Re-protection belongs in the runbook

Recovery is not complete when users can log in. The recovered environment has become production, so it needs a new protected state before the incident team starts relaxing controls.

Kasten applies a safety mechanism to a DR-restored instance so it does not immediately perform exclusive background maintenance on the same backup data. The documentation warns that ownership should transfer only when no other Kasten instance is accessing those backups because simultaneous ownership can corrupt backup data.[4] In a real site-loss event, I would place that ownership transfer next to the source-fencing decision, not treat it as post-recovery cleanup.

Kasten documents that background retention maintenance for immutable repositories runs only on the cluster that made the original export. Importing restore points into another cluster does not make that cluster extend the protection period for the imported points.[3] Once the recovery site is authoritative, I would enable Kasten policies there, create a new external restore point, and confirm monitoring and alerting before treating the service as stable. That gives the incident record a clear checkpoint: the first restore point created from the recovered production state.

What I would require before calling the cold site ready

The platform being powered off is not the readiness criterion. I would want the following proven before sign-off:

Then I would run the test from the state I actually plan to buy: no running recovery OpenShift cluster. Build it, restore it, validate it, and measure the complete timeline.

Documented Veeam's live Kasten release notes identify 9.0.7, released October 2, 2026, as the latest Kasten release listed there as of October 6. The preceding 9.0.6 release notes removed Kubernetes 1.31 support while explicitly stating that OpenShift 4.18 clusters continue to be supported; 9.0.5 had already added support for OpenShift 4.22.[7] Red Hat denotes even-numbered OpenShift minor releases as Extended Update Support releases, which includes 4.18; the applicable support phase still depends on the subscription and date.[8]

Architecture point I would treat OpenShift 4.18 as a deliberate compatibility baseline for this recovery design, not as a generic recommendation for every new deployment. Pin the exact OpenShift, storage, operator, and Kasten combination that was rehearsed. An outage is the wrong time to discover that the recovery assets drifted from production.

Source Notes

Product behavior changes. These sources were checked against public vendor documentation available on October 6, 2026.