Select a result to preview

Backup & Recovery

Document: 30-backup-recovery.md
Version: 1.0.0

Purpose

This document defines the backup and disaster recovery standards used across all Rundown projects.

Backups protect applications and client data from accidental deletion, infrastructure failures, software defects, and operational mistakes. Recovery procedures ensure that services can be restored quickly and predictably when failures occur.

The objective is not simply to create backups, but to ensure reliable recovery.

Backup Philosophy

Backups exist to enable recovery.

A backup should never be considered successful until it has been verified through restoration testing.

Recovery capability is more important than backup frequency.

Responsibilities

The backup strategy owns:

Non-Responsibilities

Backups should not replace:

Backups are a recovery mechanism, not a substitute for engineering discipline.

Backup Scope

Every production project should evaluate the following:

Database

Backup:

Database backups are mandatory.

Media

Backup:

Media recovery should maintain references stored within the database.

Configuration

Backup:

Configuration should be reproducible even if the server is lost.

Backup Frequency

Backup frequency should reflect business requirements.

Typical guidance:

The chosen schedule should balance operational risk with storage costs.

Retention Policy

Backup retention should follow a documented policy.

Typical considerations include:

Old backups should be removed according to policy rather than accumulated indefinitely.

Storage

Backups should be stored separately from the production server.

Production infrastructure should never be the only location containing recoverable data.

Where practical, backups should exist in geographically separate locations.

Restoration Testing

Recovery procedures should be tested periodically.

Testing should verify:

A backup that cannot be restored should be treated as a failed backup.

Recovery Objectives

Projects should define:

Recovery Time Objective (RTO)

The acceptable amount of time required to restore service.

Recovery Point Objective (RPO)

The acceptable amount of data loss measured in time.

Recovery objectives should reflect business requirements rather than technical preferences.

Disaster Recovery

Recovery procedures should document:

Recovery documentation should allow another engineer to restore the application without relying on undocumented knowledge.

Security

Backups should:

Backup credentials should never be stored within application source code.

Engineering Decision

Recovery-Focused Backup Strategy

Status: Accepted

Decision

Every Rundown production project must implement a documented backup strategy with verified restoration procedures.

Reasoning

A recovery-focused approach:

Backup Checklist

Before production launch, verify:

Summary

Backup and recovery protect Rundown applications against operational failures and unexpected events.

By treating successful restoration—not backup creation—as the primary objective, Rundown ensures that production systems remain recoverable, resilient, and capable of supporting long-term business continuity.