Backup and disaster recovery planning are essential parts of Day 2 operations in any environment running stateful workloads. In OpenShift environments that support both virtual machines and containers, backup and DR must cover multiple object types: VM definitions, PVC-backed data, application objects, and storage policy dependencies.
This section focuses on operational readiness rather than product installation. The goal is to ensure that backups are trustworthy, failover workflows are rehearsed, and recovery outcomes are predictable.
PX Backup Integration
PX Backup provides a platform-aware method for protecting OpenShift applications and VMs. In a FlashArray and Portworx-backed environment, it should be treated as a core part of the operational recovery model rather than as an optional add-on.
This task is used to:
protect VMs and applications consistently
create restorable recovery points
support namespace, PVC, and VM recovery workflows
increase confidence in planned and unplanned recovery events
Protecting VMs and applications with PX Backup
Administrators should use PX Backup to define repeatable protection policies for the workloads that matter most. These policies should align to workload criticality, change rate, and recovery objectives.
At a minimum, operators should know:
which workloads are protected
how frequently backups run
where backup data is stored
which recovery targets are supported
who owns backup policy validation
ActiveCluster Failover Testing
ActiveCluster-backed workloads are designed for synchronous protection and zero RPO, but that design only has operational value if administrators periodically validate how failover actually behaves. Failover should be tested as a controlled Day 2 exercise, not discovered for the first time during an incident.
This task is used to:
validate synchronous replication behavior
confirm that the intended protection model works in practice
rehearse operator response during site or array disruption
identify procedural gaps before a real failure occurs
Validating synchronous replication failover behavior
Failover validation should confirm:
the correct workloads are using the intended ActiveCluster-backed storage class
backend replication is healthy before testing begins
operators understand the expected behavior of applications and VMs during failover
the post-failover state is recoverable and operational
A successful failover test should prove not only that storage remains available, but also that application and VM behavior is understood.
ActiveDR Validation
ActiveDR-backed workloads provide near-zero RPO recovery characteristics, but like any DR capability, the operational model must be validated regularly. Administrators should know how those workloads are expected to behave, how recovery is initiated, and what recovery state is considered successful.
This task is used to:
validate near-zero RPO recovery workflows
confirm that the intended workloads are protected correctly
rehearse operator response to DR activation
verify that recovery steps are documented and repeatable
Verifying near-zero RPO recovery workflows
Administrators should confirm:
the workload is using the intended ActiveDR-backed storage class
the replication and DR policy state are healthy
recovery workflow ownership is clear
the expected recovery sequence is documented
application owners understand what near-zero RPO means operationally
This validation should cover both storage behavior and workload behavior.