Backup, Replication & Recovery

We start with a business impact analysis; targets come from what the business needs, not from what a product can do.

The analysis asks two questions: how long can this system be down (RTO), and how much data loss is acceptable (RPO). The questions go to the business unit that uses the system, not to the technical team, because both answers are commercial.

The resulting targets are set per system, and tiering is essential here: the platform that takes payments and the internal reporting tool do not need the same target. Holding everything to the most aggressive target spends most of the budget on low-priority workloads.

Once the targets are set, the method follows: a daily RPO is met with periodic backup, an hourly RPO with frequent snapshots or log-based recovery, a minute-level RPO with replication. Each step costs differently, and the decision is made with that cost visible.

With regular recovery drills. The fact that a backup was taken does not mean it can be restored.

A backup job can report success and still be broken: a missing database file, an inconsistent snapshot, a configuration file needed at recovery but never backed up. These only become visible when you try to restore.

In a drill, we actually restore into an isolated environment: the data loads, the application starts, integrity is checked, elapsed time is measured. The measured time is compared with the target and the gap goes into the report.

The report stays with you and serves two purposes: it is your audit evidence that recovery has been tested, and it sets the agenda for the next drill. Over time, the reports also show a trend: if recovery time is getting longer, the environment is drifting away from the plan.

Two mechanisms work together, and neither is sufficient alone.

Immutable storage. A copy that no account, including the administrator's, can delete or alter for a set period once it is written. The period is chosen to be longer than it takes to notice an attack.

Identity separation. The backup infrastructure authenticates independently of the production directory service. Without this, an administrator account compromised in production can reach the backups directly, and that is the first thing an attacker does.

Ransomware today does not encrypt the moment it lands; it sits quiet for weeks, looking for the backup infrastructure first. The recovery point is therefore chosen differently as well: not from when the attack was detected but from when the infection began. The gap between those is usually days, which means enough history has to be retained to reach a clean point.

The storage location is decided with you and written into the contract.

If you have a data residency requirement, backups stay in data centers in Türkiye; the location of the secondary copy is defined the same way. Where there is no such requirement, location is chosen by balancing recovery speed against cost.

There is a detail here that is often missed: besides the backup itself, the backup system's metadata (which file was backed up when, which server belongs to which job) is also stored somewhere. In some cloud-based backup products that metadata is held in the provider's central system.

Copies are also kept in at least two distinct locations: two copies in the same facility count as one if something happens to that facility.

Yes. We work with Veeam, Commvault, NetWorker, Rubrik and the native hypervisor tools.

We only propose changing products if the current one cannot meet your targets, and then we explain why. Replacing a backup product involves more than new software: the old product has to stay running for as long as its backups are retained, which means operating two systems in parallel for a period. When that cost is not accounted for up front, the migration turns out more expensive than expected.

When we take over, we first establish what the current setup actually does: which jobs run at what frequency, which systems have fallen out of scope, what the retention periods are. Finding a system that has dropped out of scope is something we encounter in almost every takeover.

At its core, yes, but it falls short in the ransomware era.

The classic rule says: three copies of the data, on two different media, one of them offsite. It was designed for hardware failure and physical disasters. Against those two risks it still holds.

Where it falls short is when an attacker can reach all of the copies. If all three are reachable from the same network and authorized by the same identity system, then as far as the attacker is concerned there is one copy.

So the rule is usually extended: one of the copies must be immutable, and one must be offline or logically separated. Three copies, two media, one offsite, one immutable, zero unverified restores.

The last clause is the most frequently skipped: an unverified backup is a copy that does not count.

If badly configured, yes, and it is usually a window problem.

Backup means reading from disk and sending over the network, and both use the same resources as the production workload. The impact is felt when the backup window spills into business hours, or when the data volume grows beyond what the window can hold.

The order of fixes: incremental backup first, so each run copies changed blocks rather than a full image. Then snapshot-based methods, where copying happens from an image while production continues. Then bandwidth throttling, capping backup traffic. Last, if genuinely needed, a separate backup network.

The number to watch is backup duration as a share of the window rather than raw duration. Once it passes 80%, treat it as a warning: data keeps growing and the window will overflow within months.

Retention has to meet three separate requirements at once, and the longest one sets the period.

Operational need: restoring a file deleted by accident usually needs a few weeks of history. How long it takes to notice a deletion sets this.

Ransomware need: reaching back to the start of an infection needs longer history, because detection comes weeks later.

Legal and contractual need: the retention period set by regulation or by customer contracts. This is usually the longest and the least negotiable.

These combine into a single retention policy: daily backups for a short period, weekly and monthly copies longer, annual archives longest. This is called tiered retention, and it is what keeps cost under control: keeping every daily backup for seven years is both unnecessary and expensive.

Retention has a flip side too: personal data held longer than required under KVKK becomes a finding in itself.

It depends on method and preparation rather than data volume, and that distinction explains why most estimates do not hold.

In a classic restore the data is copied over the network to the target system; the time depends directly on volume and bandwidth. At terabyte scale that means hours.

With instant recovery the virtual machine is started directly from the backup repository and the data moves in the background. The system is up within minutes and runs at reduced performance for a while. This is the method of choice for critical systems.

But the time is usually set by preparation rather than copying: the target environment existing, the network being ready, knowing who approves what and when. Without that preparation a "two-hour recovery" actually takes half a day, and only a drill shows you that gap.