BCP & DRP at Scalingo: Building and Testing Resilience

At Scalingo, we regularly talk about Business Continuity Plans (BCP) and Disaster Recovery Plans (DRP).

These acronyms come up in customer discussions, security audits, infrastructure projects, and post-incident reviews.

But unless you work closely with SRE or infrastructure teams, the difference between the two isn’t always obvious and they are often treated as interchangeable concepts.

Recently, Maxime from our own SRE team hosted an internal meet-up to explain what BCP and DRP actually mean, how they complement each other, and how we put them into practice at Scalingo.

We thought it would be useful to share some of the key takeaways from that discussion, along with an inside look into how resilience is put into practice across our platform.

BCP vs. DRP: What are they, and what’s the difference?

No system is immune to failure. A server can crash. A database can become unavailable. Data can be deleted by mistake. A network outage can suddenly prevent services from talking to each other. It’s a reality every cloud hosting provider has to deal with.

Most of the time, these incidents are small and quickly resolved. Sometimes, they’re not. Either way, running a cloud hosting platform means accepting that things will eventually go wrong, and being prepared when they do.

That’s where Business Continuity Plans (BCPs) and Disaster Recovery Plans (DRPs) come in. The two go hand in hand, but they don’t serve quite the same purpose.

A Business Continuity Plan (BCP) focuses on keeping critical operations running while an incident is happening. It considers the people, processes, and technologies needed to keep essential services available, even in degraded conditions.

A Disaster Recovery Plan (DRP) is about what happens next: how you restore systems, infrastructure, and data after a major disruption and get things back to normal.

Put simply, BCP is about keeping things running; DRP is about getting things back:

Together, BCP and DRP help limit downtime, reduce the impact of incidents, and make recovery more predictable. They’re two complementary parts of the same goal: making sure the platform can handle failure and recover from it. This all ties into something you’ll often hear us talk about: operational resilience.

One of the ways we make sure our Operational Resilience is effective, and that our Business Continuity and Disaster Recovery plans will work in practice, is through regular exercises.

BCP at Scalingo: Testing continuity in practice

A continuity plan can look good on paper, but the real test is how well it holds up when something goes wrong. That’s why BCP exercises are used to check that the procedures, assumptions, and technical safeguards behind the plan actually work in practice.

At Scalingo, these exercises are deliberately practical. Rather than discussing hypothetical scenarios, our SRE engineers introduce actual failures into controlled environments and observe how the platform reacts.

A typical exercise might involve shutting down an application instance, removing a node from a clustered service, or simulating the loss of part of the infrastructure. The objective is straightforward: critical services should continue operating with little or no manual intervention.

Depending on the component being tested, resilience comes from different mechanisms. Some services rely on redundancy and automatic failover. Others use clustering technologies that continue operating after losing part of the system. Increasingly, Scalingo also relies on reconciliation or "control" loops that continuously compare the platform's actual state with its desired state and automatically correct any drift.

For users, the ideal outcome is that nothing noticeable happens. Behind the scenes, however, these exercises validate that the platform's resilience mechanisms work exactly as designed.

To keep track, every scenario is documented beforehand: what is being tested, how the failure is introduced, what behavior is expected, and how success will be validated. Beyond testing the platform itself, these exercises also help share operational knowledge across the team and ensure engineers remain comfortable handling these situations.

DRP: Proving recovery is possible

A Disaster Recovery Plan begins where the BCP reaches its limits.

Some failures simply can't be absorbed through redundancy. If critical infrastructure is lost, backups need to be restored, or important internal services become unavailable, the objective shifts from maintaining availability to recovering the platform.

Disaster recovery exercises therefore focus on rebuilding.

They might involve restoring a database after accidental data deletion, rebuilding infrastructure components from scratch, or recovering services that other parts of the platform depend on. These aren't theoretical procedures, they're rehearsed regularly to ensure they remain effective as the platform evolves.

One scenario we practice is the loss of a database hosting node. In this scenario, Business-plan databases fail over to the secondary instance, providing service continuity, while Starter-plan databases remain unavailable until an operator successfully completes the DRP procedure, which involves restarting the host and the instances running on it. The exercise allows us to check that the expected failovers occur and that the recovery procedure can be carried out as planned.

The objective isn't simply to verify that recovery is technically possible. It's to answer practical operational questions.

Can the platform be restored within the expected timeframe? Are the backups complete and usable? Is the recovery procedure sufficiently documented? Could another engineer execute it confidently during a real incident?

Regularly replaying these scenarios ensures that recovery plans remain accurate instead of becoming outdated documentation that nobody has tested.

Measuring resilience with RTO and RPO

Two metrics are commonly used to define recovery objectives and to measure success: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The Recovery Time Objective defines how quickly a service should be restored after an incident. The acceptable recovery time depends on the criticality of the system. Highly available services are expected to recover almost immediately through automatic failover, while rebuilding larger infrastructure components may reasonably take longer.

The Recovery Point Objective addresses a different question: how much data loss is acceptable?

This metric directly influences backup strategies. For example, if backups are taken every hour, restoring from backup could mean losing up to one hour of recently created data. Different systems have different tolerance levels, and defining an RPO helps ensure backup policies match operational expectations.

Together, RTO and RPO provide a concrete way to evaluate whether recovery plans meet an organization's resilience objectives.

Resilience is also about people

One of the recurring themes during the meet-up was that operational resilience isn't purely a technical problem.

Even the best recovery procedures lose much of their value if only one person knows how to execute them.

For that reason, we’ve invested significant effort over the past few years into documenting BCP and DRP scenarios and making them part of our team's operational practices.

It's a way to ensure knowledge is shared across the engineering organization, recovery procedures remain accessible, and operational responsibilities don't become concentrated around a handful of individuals.

Every exercise is the opportunity to improve that documentation. Engineers regularly identify missing details, clarify ambiguous steps, or discover assumptions that previously existed only as tribal knowledge.

The human side of resilience also includes keeping users informed about what is happening, what impact they may experience, and how the situation is evolving. Communication goes hand in hand with BCP and DRP: our teams need to be prepared and comfortable both executing continuity or recovery procedures and communicating clearly with users throughout an incident. Just as we have processes for the technical response, we also have processes for incident communication, a topic that deserves an article of its own.

Designing & Preparing for failure

At Scalingo, whenever new infrastructure or services are introduced, SRE engineers work alongside the teams building them to identify critical components, think through failure scenarios, define recovery expectations, and evaluate operational risks. Questions such as How could this fail?, How will we recover it?, and Who knows how to operate it? are considered as part of the design process rather than after deployment.

That mindset shapes much of how we approach infrastructure. For us, BCP and DRP are simply continuous engineering practices that help us validate our assumptions, improve our platform, and ensure operational knowledge is shared across the team.

Frequently Asked Questions about BCP and DRP
What is the difference between a BCP and a DRP?

A Business Continuity Plan (BCP) focuses on keeping critical services available while an incident is happening. A Disaster Recovery Plan (DRP) focuses on restoring systems, infrastructure, and data after a major disruption when continuity measures are no longer sufficient.

Why do organizations run BCP and DRP exercises?

A documented plan alone doesn't guarantee resilience. Regular exercises validate that technical safeguards, operational procedures, and recovery processes work as expected, while helping teams remain familiar with them.

What are RTO and RPO?

The Recovery Time Objective (RTO) defines how quickly a service should be restored after an incident. The Recovery Point Objective (RPO) defines how much data loss is acceptable. Together, they help organizations define and measure their recovery objectives.

Why are BCP and DRP important for cloud platforms?

Cloud platforms rely on complex distributed systems where failures are inevitable. BCP and DRP help minimize service disruption, reduce data loss, and ensure recovery procedures are tested before they're needed.

Are BCP and DRP required for ISO 27001, HDS, or SecNumCloud?

Business continuity and disaster recovery are key requirements of frameworks such as ISO 27001, HDS, and SecNumCloud. While the exact expectations differ, organizations are generally expected to document, maintain, and regularly test their continuity and recovery procedures.

How does Scalingo validate its business continuity and disaster recovery plans?

At Scalingo, BCP and DRP aren't treated as static documents. Our SRE teams regularly run continuity and recovery exercises, document their findings, measure recovery objectives such as RTO and RPO, and continuously improve procedures as the platform evolves.