SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

The question is not whether you have a backup — it is whether you can return.

Data protection is measured by returning, not by copying. Sanal Çekirdek designs backup architecture backwards from recovery objectives: which data returns, to which point in time, and within how long.

An untested backup is not a backup. The existence of a copy can be reported; the ability to restore is only known by trying.

Starting from recovery objectives

Design starts with RPO (acceptable data loss) and RTO (acceptable downtime). Both numbers are set with the business, and technology is chosen afterwards. A single objective is never applied across every system — each criticality class gets its own.

  • Objectives are signed off by the business owner
  • Separate RPO and RTO per criticality class
  • Systems that cannot meet their objective are listed openly
  • Cost rises steeply as objectives tighten — said up front

Layered retention and immutable copies

Copies never live in one place. A layer close to production for fast return, a layer in a different location, and an immutable layer against ransomware are designed together. The isolated copy is reached through an identity path separate from production.

  • Immutable copies reject deletion and encryption attempts
  • The isolated copy uses a separate identity path
  • Retention is matched to legal and business requirements
  • Copy count and location are visible in one table

Restore testing and evidence

Restore capability is measured through scheduled tests. A test runs at application level, not file level: does the system come up, does it find its dependencies, is the data consistent. The result is recorded with its evidence.

  • Restore tests run at application level
  • Measured duration is reported against the objective
  • A failed test produces a remediation item
  • Evidence is usable in audit and insurance processes

Archiving and lifecycle

Backup and archive are not the same thing. Backup exists for return; archive exists for retention obligations. They are governed by separate policies — otherwise data past its retention period keeps living in backups, generating both cost and risk for nothing.

  • Separate policy and separate duration for backup and archive
  • Expired data is destroyed on a planned basis
  • Archive access is designed to be slow but complete
  • Destruction is recorded

How we work

  1. Set criticality classes and recovery objectives
  2. Measure current coverage and its gaps
  3. Build the layered retention architecture
  4. Put restore testing on the calendar
  5. Report results and revisit the objectives

How success is measured

  • Every critical system has a written RPO and RTO
  • Restore testing is scheduled and evidenced
  • Measured recovery time sits inside the objective
  • Immutable coverage grows and the gap shrinks

Frequently asked questions

Is cloud backup enough on its own?

It provides location diversity but is not sufficient alone. What matters is that the copy is immutable, that access is separated from production identity, and that restore time meets the objective.

How often should restores be tested?

Criticality class decides: regularly and on a schedule for the most critical systems, less often for the rest. Frequency matters, but so does testing at application level and recording the result.

Is backup enough against ransomware?

Backup is necessary but not sufficient. Attackers usually target backups first, so immutable copies, isolated access and a clean recovery environment are needed together.

When did you last prove a restore actually works? Share your recovery objectives and we will measure current coverage together.

Let's measure your recovery objectives