KubeDB

By AppsCode

CONTACT SALES

Business Continuity and Disaster Recovery (BCDR)

Kubernetes Database Disaster Recovery
with Near-Zero RPO and RTO

Lose a data center without losing your data or waiting on a war room. KubeDB fails your databases over to a second data center in about a minute, supports zero data loss with synchronous replication, and protects the engines you run with the right approach for each.

Best with:
KubeDB Operator
KubeDB Platform
Explore DR Options Schedule Demo

Zero

RPO with Synchronous Mode

45 s

Default Failover Timer

5+

Engines with Cross-DC DR

PITR

Backup

Why Database Disaster Recovery Matters

When a data center goes down, the database decides how long the business stays down and how much it loses. These are the pains KubeDB removes.

Outages Stop the Business

When a data center goes dark, every application that depends on its databases goes dark with it.

Lost Data Is Lost Trust

The orders, payments, and records written just before an outage are the hardest to get back.

Manual Recovery Is Slow

Runbooks, war rooms, and late-night decisions turn a short outage into a long one.

Untested Plans Fail

A recovery plan nobody has rehearsed is a hope, not a plan. KubeDB makes drills routine.

Your Infrastructure, Our Software

Disaster Recovery, Built In

KubeDB protects your databases across data centers and moves them when you need it to, so failover becomes a routine operation instead of an emergency.

You Provide:

Kubernetes in two data centers
A network path between them
A small third site to break ties, for automatic failover
Object storage for backups

KubeDB Provides:

Automatic failover, or failover your team approves
Continuous replication to your standby site
Only one site in charge at any time, even during a network split
Backup with point-in-time recovery
Automatic or manual • One site in charge at all times • Planned switchover is one command

Choose How Failover Happens

AspectAutomatic FailoverManual Failover
Who triggers itThe system, with no human in the loopYour team, after approving the move
Best forMany databases, and teams that cannot wait on a personTeams that approve every move, or run only two sites
Recovery time (RTO)About a minute by defaultDetection plus your team's response
Data loss (RPO)A few seconds at most, or zero with synchronous replicationZero with synchronous replication, or the last few seconds without
Planned switchoverOne command, with no data lostOne command, with no data lost
FootprintTwo data centers plus a small tie-breaker siteTwo data centers

Everything You Need to Recover with Confidence

Failover, replication, switchover, and backup, operated the same way for every database

Automatic Failover

Recovery that does not wait for a person, built for teams running many databases.

No pager call to start recovery
Only one site in charge, even during network splits
Same experience for every database

Manual Failover

Every data center move needs your approval, with the smallest footprint.

Your team stays in control
Fits two-site environments
Zero data loss with synchronous replication

Synchronous Replication

Acknowledge a commit only after the standby has it, so a lost data center loses nothing.

Zero data loss on unplanned failover
Cost: one network round trip per write
Turn it on only where it matters

Active-Active

For the strictest targets, a distributed SQL database keeps serving through a data center loss.

Zero data loss and near-zero downtime
Designed in from day one for new services
Works best with sites close together

Planned Switchover

Move the primary on purpose for maintenance or drills, with no data loss.

One command, with visible progress
Abort at any point to resume writes
Rehearse recovery without risk

Backup and PITR

Encrypted, incremental backups with point-in-time recovery, for the failures replication cannot undo.

Encrypted, incremental backups
Point-in-time recovery
Any S3-compatible object store
The Process

From Setup to Protected

Four steps to a database estate that survives the loss of a data center.

1
Step 1

Connect Your Data Centers

Run Kubernetes in two sites with a network path between them

2
Step 2

Choose How Failover Happens

Automatic or manual, to match how your team works

3
Step 3

Protect Your Databases

Deploy databases in disaster recovery mode, with backups switched on

4
Step 4

Rehearse and Prove It

Run planned switchovers and drills to measure your real recovery numbers

FAQ

BCDR Frequently Asked Questions

Everything you need to know about disaster recovery with KubeDB

With automatic failover, recovery typically takes about a minute by default. With asynchronous replication, data loss is a few seconds at most, and with synchronous replication it is zero. Planned switchovers are always zero data loss. Your actual numbers depend on your network and workload, so measure them in a drill.
Choose automatic failover when a data center failover must not wait for a person, you run many databases, and you can host a small third site to break ties. Choose manual failover when your team must approve every move, you have only two sites, or you want the smallest footprint. Choose active-active distributed SQL for new services that need zero loss and near-zero downtime and can accept the application changes.
Each write waits for the standby, so write latency grows by one network round trip between the data centers. In exchange, a lost data center loses no committed data. Many teams turn it on only for the databases that need it.
When you need zero data loss and near-zero downtime and can keep your data centers close together. A distributed SQL database keeps a full copy in each data center. It requires application changes, so it suits new services best.
In standard active/standby setups, yes. KubeDB keeps one data center in charge at a time, and the other follows. Active-active distributed SQL is the exception, by design.
KubeDB protects many of the popular relational, NoSQL, streaming, and search engines across data centers, using the best mechanism for each one. For some engines replication is asynchronous, so data loss equals the replication delay. See the documentation for the full list.
KubeDB makes sure only one data center is in charge at any moment, even during a network split. A site that loses contact stops accepting writes until it is safe to continue.
It rejoins as a standby and KubeDB brings it back in sync. When you are ready, a planned switchover returns the primary role with no data lost.
Yes. KubeDB provides encrypted, incremental backups with point-in-time recovery, so you can recover from failures that replication would copy to the standby, such as an accidental delete.
Run planned switchovers and scheduled disaster recovery drills, for example quarterly, and record the RPO and RTO each drill measures. KubeDB shows status and progress at every step.
Yes. KubeDB runs a highly available primary cluster with a live disaster recovery replica at a geographically separate site for a regulated mobile financial services platform. Read the TeleCash case study for details.

Still have more questions?

Contact our support team
Protect Your Data

Set Your RPO and RTO Before You Need Them

Pick automatic or manual failover, add synchronous replication or active-active where zero loss matters, and prove it in a drill.

  • Near-zero RPO and RTO across data centers
  • Planned switchover with zero data loss
  • Backup with point-in-time recovery
Schedule a Demo Read the TeleCash Case Study
45 s
Default Failover Timer
Zero
RPO, Synchronous Mode
PITR
Backup Recovery
24x7
Expert Support