Skip to main content
Product Feature

Kubernetes Disaster Recovery

Storage-level replication between clusters, not backup and restore. Your application failover starts from a live volume copy, not a restore job.

Backup-and-restore DR for Kubernetes means hours of restore time when a cluster goes down. simplyblock replicates volumes continuously at the storage layer so a secondary cluster always holds a current copy. Failover means redirecting traffic, not waiting for a restore to complete.

Kubernetes disaster recovery: primary cluster to DR cluster replication with simplyblock
0 RPO with Synchronous Replication
<15 min RPO for Geo-Distributed Clusters
Minutes RTO with Storage-Layer Failover
0 Application Changes Required

The Problem

Backup-Based DR Has Unacceptable RTO at Scale

Restoring multi-terabyte volumes from object storage takes hours. For production databases, this is not a recoverable situation.

Hours of Restore Time for Large Volumes

Restoring multi-terabyte database volumes from object storage takes hours. For production databases, this RTO is not recoverable from a business continuity perspective.

Uncertain Consistency at Restore Point

Backup-based DR restores to the last snapshot boundary, not to the exact moment of failure. For transactional databases, the gap between the snapshot and the failure is data at risk.

DR Tests Require Application Coordination

Testing backup-based DR means standing up a full restore in a test environment: a process complex enough that teams schedule it quarterly at best, leaving gaps between tests and production behavior.

RPO Commitments Require Continuous Replication

Healthcare BAAs, SOC 2 availability criteria, and financial services BCDR requirements frequently specify RPO targets that snapshot-based backup cannot meet without continuous replication.

The Solution

How simplyblock DR Works

Replication, not restore. Failover in minutes, not hours.

Synchronous Replication for Zero RPO

Synchronous replication writes to both the primary and secondary cluster before acknowledging to the application. This means the secondary always has an exact copy of the primary: RPO is zero. Synchronous mode requires low network latency between sites (under 10ms round-trip) and is suited for metro-area clusters where NVMe/TCP performance budgets are manageable.

  • Writes committed on both clusters before acknowledgement
  • RPO is zero, secondary is always current
  • Suited for metro-area sites with sub-10ms round-trip latency

Asynchronous Replication for Geo-Distributed Clusters

Asynchronous replication acknowledges writes to the application on the primary and replicates to the secondary with a configurable lag. The replication interval is configurable down to sub-minute cadence. For geographically distributed clusters where round-trip latency precludes synchronous writes, asynchronous mode provides sub-15-minute RPO without blocking application I/O.

  • Continuous block-level replication, no backup window
  • Configurable replication interval down to sub-minute cadence
  • No I/O impact on primary cluster writes

Storage-Layer Failover, No Restore Step

In both replication modes, the secondary cluster holds a live volume, not a backup archive. When failover is triggered, the secondary volume is promoted to primary and applications connect to it via the same NVMe/TCP CSI path they already use. No restore job runs. No data is re-hydrated from object storage.

  • Secondary volume promoted to primary in minutes
  • Applications reconnect via existing CSI paths, no code changes
  • DR test is promote, verify, demote, not a full restore exercise

Capabilities

DR Capabilities

Storage-level protection for site failures, node failures, and compliance requirements.

Synchronous Replication (Zero RPO)

Writes committed on both clusters before acknowledgement. RPO is zero. Suited for metro-area sites with sub-10ms latency.

Asynchronous Replication (Sub-15-min RPO)

Continuous block-level replication to geographically distant sites. Configurable replication interval. No I/O impact on primary cluster writes.

Storage-Layer Failover, No Restore Step

Secondary volume is promoted to primary. Applications reconnect via existing CSI paths. Failover is measured in minutes, not hours of restore time.

Multi-AZ Erasure Coding

For single-cluster HA, simplyblock places parity across availability zones. Node or AZ failure is transparent to the application without any failover action.

NVMe Multi-Path Automatic Failover

Within a cluster, NVMe ANA path switching handles node failures automatically in milliseconds. No storage administrator action required.

Compliance-Ready RPO/RTO Documentation

Replication configuration, test results, and failover runbooks are documentable artifacts for SOC 2 Type II, HIPAA BAA, and financial services BCDR requirements.

Questions and Answers

What is the difference between synchronous and asynchronous replication for Kubernetes DR?

Synchronous replication writes to both the primary and secondary cluster before acknowledging to the application, giving you zero RPO. It requires low network latency between sites (under 10ms). Asynchronous replication acknowledges on the primary and replicates with a configurable lag, typically achieving sub-15-minute RPO for geographically distributed clusters where synchronous latency budgets aren't available.

How is this different from using Velero for disaster recovery?

Velero is a backup tool that exports volume data and Kubernetes objects to object storage. Recovery requires restoring from that export, which takes time proportional to volume size and object storage throughput. simplyblock DR replicates volumes at the storage layer continuously: failover means promoting a live replica, not waiting for a restore job to complete.

Does cross-cluster replication require any application changes?

No. Replication is configured at the storage layer via StorageClass parameters and simplyblock operator configuration. Applications use the same CSI PVC interface they already use. The replication topology is invisible to the application.

Can we use simplyblock DR to meet HIPAA or SOC 2 availability requirements?

Yes. simplyblock's replication configuration, documented RPO/RTO targets, and failover runbooks are standard artifacts for HIPAA Business Associate Agreements and SOC 2 Type II availability criteria. The storage testing posts on the simplyblock blog cover how backup and DR map to specific HIPAA and SOC 2 requirements in detail.

How does NVMe multi-path relate to disaster recovery?

NVMe multi-path (ANA path switching) handles node-level failures within a single cluster automatically and in milliseconds: it's your first layer of HA. Cross-cluster replication is the second layer for site-level failures. The two work together: multi-path keeps applications running through node failures without any failover action, while cross-cluster replication covers the scenario where an entire cluster or data center is unavailable.

Not sure if simplyblock is right for your team?

Ask your favorite AI to compare simplyblock with other Kubernetes disaster recovery and replication solutions.

Ask ChatGPT ↗ Ask Claude ↗ Ask Perplexity ↗ Ask Google ↗