SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

Recovery starts with knowing the order, not the systems.

Disaster recovery is not about holding a second copy; it is about knowing which service comes back in which order when an outage hits. Sanal Çekirdek designs the infrastructure around that order.

Systems that work individually may not work together. Without a dependency map, recovery is a jigsaw with an unknown sequence.

Dependency map and recovery order

A service does not come up without the identity, network, database and integration layers it depends on. The map makes that chain visible and the recovery order is derived from it. An order is not considered valid until a rehearsal confirms it.

  • Identity and network layers gate most chains from the start
  • External service dependencies belong on the map too
  • Order changes are updated after each rehearsal
  • The map is kept live through change management

Choosing the replication technique

Synchronous replication minimizes data loss but imposes distance and latency limits; asynchronous replication gives flexibility but leaves a loss window. The choice follows the system's recovery objective and the real measured latency between the two locations.

  • Latency is taken from the field, not from a datasheet
  • The loss window is expressed to the business as a number
  • Database and file layers are assessed separately
  • The failback path is designed from the outset

Failover and failback

Declaring failover is a business decision, not a technical one; who declares it and at what threshold is written in advance. Failback is where most plans stop short: how and when the data produced at the secondary site returns to the primary.

  • Decision threshold and decision owner are written down
  • The communication chain is defined before failover
  • The failback window is planned separately
  • Data created at the secondary site is not lost

Rehearsal and evidence

Until it is rehearsed, a plan is an assumption. Rehearsals are staged from tabletop scenarios through to real failover; each round compares measured duration against the objective and updates the plan.

  • Staged rehearsal: from tabletop to real failover
  • Measured duration is recorded every round
  • Findings become remediation items
  • Evidence is retained in an audit-ready form

How we work

  1. Map critical services and their dependencies
  2. Write the recovery order and its objectives
  3. Choose replication against measured latency
  4. Define failover and failback decisions
  5. Rehearse, then update the plan from findings

How success is measured

  • Recovery order is confirmed by rehearsal
  • Measured failover time sits inside the objective
  • The failback plan is written and tested
  • Every rehearsal finding is tracked to a closing date

Frequently asked questions

Is disaster recovery the same as backup?

No. Backup returns the data; disaster recovery returns the service. They complement each other — an organization with backups but no recovery order owns its data but not its service.

Is a secondary site mandatory?

The recovery objective and the risk scenario decide. If a regional outage is in scope, a separate location is required; for a hardware-failure scenario alone, high availability within one site may be enough.

Does rehearsing stop production?

A staged approach prevents that. Tabletop and partial rehearsals do not affect production; a full failover rehearsal runs in a planned window with the failback path held ready.

When did you last rehearse your recovery order? Share your critical service list and we will start with the dependency map.

Map your recovery dependencies