Backups — Term Reference

A copy of data preserved for recovery in the event of data loss, corruption, hardware failure, cyberattack, or disaster. Planning a backup strategy requires decisions across six dimensions: total data volume, backup type (full, incremental, snapshot), backup media (tape, disk, cloud), storage location (on-site, off-site), backup/recovery software, and schedule (hourly, daily, weekly, monthly). Each decision affects recovery speed, storage cost, data loss tolerance, and the security of the backup data itself.

A backup stored at the same physical location as the production systems it protects. Advantages: no WAN or internet link required for backup or restore; data is immediately available; generally lower cost than off-site storage. Limitation: vulnerable to site-level disasters — fire, flood, ransomware affecting the entire facility, or physical theft — that could simultaneously destroy both the production data and its on-site backup. Best used for fast, everyday restoration; complemented by off-site backups for disaster protection.

A backup stored at a geographically separate location from the production systems — a remote data center, third-party storage facility, or cloud storage. Data is transferred via internet, WAN, or physical media shipment (tapes). Primary advantage: protection from site-level disasters that destroy the primary location. The backup survives a building fire that destroys the production systems. Restoration requires network connectivity and takes longer than on-site restore. Most organizations maintain both on-site and off-site backups for rapid local recovery plus disaster resilience.

How often backup jobs run — hourly, daily, weekly, or monthly. Frequency directly determines the Recovery Point Objective (RPO): if daily backups run at midnight and failure occurs at 11:45 PM, up to 23 hours 45 minutes of changes are lost. Different systems warrant different frequencies based on how fast data changes and how much loss is tolerable. Organizations typically maintain multiple backup sets at different intervals (daily + weekly + monthly) to balance storage cost against recovery flexibility across different time horizons.

The maximum acceptable amount of data loss, expressed as a time interval, following an incident. RPO directly determines required backup frequency: an RPO of 1 hour requires hourly backups; an RPO of 24 hours requires daily backups. Lower RPOs demand more frequent backups, more storage, and more network bandwidth. RPO is set by business requirements — a payment processing system may have an RPO of minutes; a reference data server may have an RPO of a week. Backup strategy must be designed to meet each system's RPO.

Encrypting backup data so that backup media contains only ciphertext, readable only with the correct recovery key. Protects against data exposure when backup media is stolen, lost in transit, or accessed by unauthorized parties at storage facilities. Essential for cloud backups where data is stored in a third-party environment. Critical dependency: recovery keys must be stored separately from the backup media and must themselves be protected and available when needed — an encrypted backup with no accessible key is permanently inaccessible. Backup encryption converts a physical theft into a media loss event with no data breach.

A point-in-time copy of an entire system (virtual machine, volume, or cloud resource) captured instantly with a single operation. The initial snapshot captures the full state of the system; subsequent snapshots typically capture only the changes since the previous snapshot (incremental). Snapshots are the dominant backup method for virtual machines and cloud infrastructure: fast to create, fast to restore, and easy to take before significant changes so the system can be reverted if the change causes problems. Example: Monday 100 GB full → Tuesday 40 GB changed → Wednesday 20 GB new — each day's snapshot adds only the delta.

After the initial full snapshot, each subsequent snapshot stores only the data that changed since the previous snapshot — not the entire system state. This reduces storage consumption and backup time compared to taking a full copy every day. To restore to a specific day, the system applies the full initial snapshot plus all incremental snapshots up to the target date. Incremental snapshots make daily VM backups practical even for large systems, because the daily delta is typically much smaller than the total data volume.

The practice of actually restoring data from backup to a test environment and verifying the restored data is complete, consistent, and usable by applications — not just that backup files exist. An unverified backup is an unverified assumption. Backup jobs can complete successfully while producing corrupt or incomplete backup files. Recovery testing must cover all backup types (daily, weekly, monthly) and must verify application functionality against restored data, not just file presence. Periodic audits (weekly, monthly, quarterly) maintain confidence that the backup program is actually working.

Continuous near-real-time synchronization of data from a source to one or more remote destinations. Unlike periodic backups (which capture state at scheduled intervals), replication propagates every change within seconds or minutes. The replicated site always has a current copy. Essential for hot site disaster recovery: when the primary site fails, the hot site has up-to-date data and can take over immediately. Important limitation: replication propagates all changes — including ransomware encryption or accidental deletions — overwriting the good data at the destination. Periodic backups are still needed for historical recovery points; replication cannot replace them.

A write-ahead logging technique that protects file systems and databases from corruption caused by interrupted write operations (power failures, system crashes). Before writing data to its final storage location, the system first records the intended change in a sequential journal log. If power fails during the journal write: the storage data is untouched and remains consistent. If power fails during the storage write: the journal entry allows the system to replay and complete the operation on next startup. Once both writes complete, the journal entry is cleared. Modern file systems (NTFS, ext4, XFS) use journaling as a standard feature.