Continuity / Recovery

Getting the data back isn't getting the operation back.

Having backups and having a recovery plan are not the same thing. The day you lose the site, the files are no use if there is no compute to bring them up on, no network to connect them and no names that resolve. That gets built before, not during.

Backup or recovery

Cloud backup

Gives you your data back.

The copy leaves the site without changing how you operate.

See details

You are here

Disaster recovery

Gives you your operation back, running.

Compute to bring it up on, a network to connect it and names that resolve.

Having the first without the second means you have your files and nowhere to bring them up.

What goes down when there's nowhere to bring it up

The data is there, but there are no servers to start it on, and getting hardware in the middle of a crisis isn't a matter of hours.
The applications start and can't find each other, because the names still point to addresses at the site that went down.
Nobody knows what order to start things in, so the ERP tries to come up before the database it depends on.
The recovery time in the plan was never measured, so it's an estimate, not a number.

Two ways to recover

Server replication

When what has to come back up is whole servers.

An agent on each server replicates changes to a staging area in the cloud, and compute appears only when the failover runs.

Platform and database recovery

When legacy applications, containers and large databases coexist, and recovery today depends on coordinating several teams.

Both sites are built from the same code, databases replicate by sending only the blocks that changed, and failover and failback are orchestrated as an automated procedure. The drill runs in isolation, without touching production.

How it works

Continuous replication, not a nightly copy. A lightweight agent on each server sends changes as they happen to a staging area in the cloud. What you lose in an outage is what changed in the last moments, not the day's work.
Capacity materializes at failover. While there's no disaster, no servers are running on the other side, only the replication area. The compute appears when the recovery runs. That's the fundamental difference from maintaining a physical alternate site.
The way back is designed along with the way out. Once the crisis is over, you have to return to the original site. That path is defined from the start, because staying in emergency mode indefinitely has its own cost.

What's in scope

Partial loss. One or several servers fail while the site is still standing. Their recovery instances take over in the cloud and your users keep working through the same network.
Total site loss. The data center is down and so is its connectivity. Systems come up in the cloud and your people work remotely through virtual desktops, as if they were at the office.
Test failover. Recovery instances start in an isolated network to prove that systems come back and data is intact, without touching production.
Failback. When your site is back, everything that changed during the incident returns to it in sync, so nobody has to reconcile two versions of the truth.

How we work

We classify what has to come back first
Not every part of the environment deserves the same treatment. Workloads are ranked by what your operation stops doing without them, and that sets the recovery time and tolerable data loss objectives for each one.
We design the destination
Secure connectivity between your site and the cloud, name resolution and the startup order of dependencies. Most plans fail here, not in replication.
We replicate
The agent is installed on the servers in scope and left running until the replica is current, checking that it doesn't compete with production performance.
We test the failover on a subset
The recovery is actually run on a limited group of workloads, isolated from production, to see how it behaves and measure the time before involving the full environment.
We measure and write the runbook
The result isn't "it works". It's how long it took, what turned out differently than expected, and the step-by-step procedure for the real day, including the way back.

Why what happens next matters

A recovery plan ages faster than anything else in your infrastructure. A new server comes in and nobody adds it to replication. A dependency changes and the startup order is no longer valid. An application gets updated and the runbook falls behind.

A plan that isn't tested again stops being a plan and becomes a document. That's why recurring testing is the part that never ends, and it's something our team can take on.

Questions

What's the difference between high availability and disaster recovery?

High availability means a component fails and the operation carries on without anyone noticing. Disaster recovery means you lose an entire site and can bring the operation up somewhere else. One doesn't replace the other; they solve failures of a different scale.

Does replication affect my servers' performance?

The agent is designed to capture changes without competing with the application for resources. Even so, it's validated with measurements on your environment, because the behavior depends on how much data changes and on your link.

Do I have to replicate everything?

It rarely makes sense. Replicating everything equally raises the cost without improving recovery, because the real problem is the order in which things come back, not the volume. That's why the first step is to classify.

How much data could I lose?

With continuous block-level replication, typically seconds of changes. You can also go back in time: by default, AWS Elastic Disaster Recovery keeps a recovery point every ten minutes for the last hour, one per hour for the last day, and one per day for the retention you configure. That is what lets you recover to a moment before ransomware encrypted anything.

Can failover be automatic?

The execution can be. Alarms detect the failure, an orchestrated runbook starts systems in the right order and DNS moves users to the new site. The decision should not be. Declaring a disaster is a business call, so we design it for a person to make in one step and for automation to do the rest.

Do my applications need changes?

Sometimes one. Applications that point to fixed IP addresses need to point to names instead, so they can switch sites without being reconfigured. We find those during the design, not during the incident.

Is my internet link enough?

Continuous replication needs sustained bandwidth. We size it from your real rate of change before we start and tell you whether your current link is enough, needs traffic shaping or needs a dedicated channel for replication.

What do I receive at the end?

Editable architecture diagrams for replication, test, failover and failback. Tested failover and failback runbooks. The measured times from the test. Recordings of the working sessions, and training for your team so the plan does not depend on us.