Data Backup and Disaster Recovery Plan

Short answer: backup is not a copy job, it is a commitment about recovery. A system genuinely has backups only when three things are written down: how often backups run (in other words, how many hours of data you can afford to lose), how long a restore takes, and when the backup was last proven to open. Without those three, what you have is not a backup but a set of files you assume is one.

Two numbers: RPO and RTO

A disaster recovery plan rests on two figures, and both are business decisions rather than technical ones. You set them; the engineering team then builds infrastructure that meets them.

• RPO (acceptable data loss): when the system fails, how many hours of data can you afford to lose? On a brochure site, 24 hours is fine; on a store taking orders, even 15 minutes is too much.
• RTO (acceptable downtime): how long can the system stay down? This number decides where backups live — the gap between a warm copy on another server and an archive you have to download is measured in hours.
• Scope: database, user-uploaded files, configuration and environment variables, mail records. The most commonly forgotten item is uploads: the database comes back and the product images do not.

Any backup decision made before RPO and RTO are written down is guesswork. Once those two numbers exist, the required solution and its cost follow on their own.

The 3-2-1 rule and why it still holds

The oldest rule in backups is still the most useful one: three copies, two different media, one off-site. The reasoning is practical, not philosophical — backups usually fail not because a server burned down but because something inside the same account was deleted or encrypted.

• A backup on the same server is not a backup. When the server is unreachable, so is the backup.
• A backup in the same account is half a backup. If the account is compromised or suspended over billing, both copies go at once.
• Immutable copies against ransomware: a copy that cannot be deleted for a set retention period is the only answer to the scenario where the attack encrypts the backups too.
• Retention: keeping only the latest backup is not enough, because corruption can go unnoticed for a week. Daily backups for a month and weekly ones for a few months is the common setup.

An untested backup is not a backup

This is the most expensive mistake we see in the field: the backup job runs every night, the log looks green, and the file is empty or corrupt. Nobody finds out until the day it is needed. The fix is simple — the last step of the backup script should restore what it just produced into an empty database and confirm there is data inside.

#!/usr/bin/env bash
set -euo pipefail

# Gece yedegi: veritabani dokumu + dosyalar, sonra GERI YUKLEME TESTI.
STAMP=$(date +%F)
DUMP="/backup/db-$STAMP.sql.gz"

pg_dump "$DATABASE_URL" | gzip > "$DUMP"
tar -czf "/backup/uploads-$STAMP.tar.gz" /var/www/uploads

# Bos bir test veritabanina geri yukle: yedegin okunabildigini kanitlar.
createdb restore_check
gunzip -c "$DUMP" | psql restore_check >/dev/null
ROWS=$(psql -tA restore_check -c 'select count(*) from orders;')
dropdb restore_check

if [ "$ROWS" -lt 1 ]; then
  echo "YEDEK BOZUK: siparis tablosu bos" >&2
  exit 1
fi

# Kopyayi ikinci bir konuma (farkli saglayici) tasi.
rclone copy /backup remote-offsite:backup --max-age 24h
echo "Yedek dogrulandi: $ROWS kayit"

The value in that script is not the pg_dump line but the restore check: if the backup will not open, the job fails and somebody gets alerted. On top of that, run a manual drill once a quarter: bring up a brand-new environment from a backup and time it. An RTO you have never measured is an RTO you have guessed.

Where backups sit in the maintenance agreement

Backups are usually part of a maintenance service, but the scope stays vague in most contracts. These four points belong in writing; we broke down the annual cost lines in website maintenance cost.

• Frequency and retention: daily or hourly, and how far back can you go?
• Where the backup lives: same provider or a different one? The country the data sits in matters for data protection too — see GDPR-compliant website for the principles.
• Restore commitment: how many hours after a request is the system back up, and does that hold outside office hours?
• Handover of the backups: if the relationship ends, in what format and how quickly do you get your data? Without this clause your data stays locked at the provider.

The first hour of a real incident

The plan has to be short enough to read while it is happening. Nobody opens a thirty-page document mid-crisis; a one-page ordered list does the job.

• Stop first: if you suspect an attack or data corruption, stop writes. A system that keeps running pushes the corrupted data into the backups too.
• Then classify: is the server gone, is the data corrupted, or is it just a bad deployment? The three have different fixes, and a wrong diagnosis is where most of the time is lost.
• Restore into a separate environment: writing over production is how the same incident happens twice.
• Communicate: if the outage reaches customers, the comms plan starts before the technical fix.
• Write it up afterwards: what happened and which step was missing? For the preventive side, website security is a good checklist.

Conclusion

The real question is not "are we taking backups" but "when did we last manage to restore one". A setup with defined RPO and RTO, built to the 3-2-1 rule and tested regularly, turns data loss from an emergency into a routine procedure. If you would like us to check those three points on your current infrastructure, see our corporate solutions service or request a quote.