Backup Planning — More Variables Than "Just Back It Up"
The instinct to "just perform a backup" is correct but incomplete. An unplanned backup strategy creates a false sense of security — you have backups, but they may be in the wrong location, on the wrong media, at the wrong frequency, or unprotected. Effective backup planning requires decisions across six dimensions before the first backup job runs.
Total amount of data: Are we backing up megabytes, gigabytes, or petabytes? Volume determines media selection, transfer time, and storage cost. Type of backup: Full, incremental, differential, snapshot — each with different storage requirements and restore complexity. Backup media: Local hard drive, tape, NAS, cloud storage — each with different durability, cost, and access speed. Storage location: On-site, off-site, or cloud — each with different risk profiles. Backup and recovery software: Third-party enterprise products, operating system built-ins, or cloud-native tools — each with different capabilities and licensing costs. Schedule: How often to back up, and whether different data sets warrant different frequencies.
Each of these decisions interacts with the others. A large data set may make daily full backups impractical, leading to an incremental strategy. A regulatory requirement may mandate 7-year retention, which determines media selection. A tight Recovery Point Objective (RPO) may require hourly backups of transaction databases but only weekly backups of rarely-changing reference data. Backup planning is not a one-size-fits-all decision — it is a set of system-by-system trade-offs.
On-Site vs. Off-Site — Speed vs. Disaster Resilience
Where backup data is stored is one of the most consequential backup decisions, because the threat model for on-site and off-site storage is completely different.
On-site backups store data at the same physical location as the production systems. No internet or WAN link is required to perform the backup or to restore from it — data moves across the local network or directly to local media. This makes restoration fast: a large restore job that would take hours over a WAN link completes in minutes on a local network. On-site backups are also generally less expensive — no recurring fees for a remote storage facility or cloud subscription. The limitation is survivability: if a fire, flood, ransomware attack, or physical theft affects the primary location, it may also affect the on-site backups. Backups stored in the same room as the servers they are backing up provide no protection against a building-level disaster.
Off-site backups store data at a geographically separate location — a remote data center, a third-party storage facility, or cloud storage. The primary benefit is disaster resilience: if the primary location is destroyed, the off-site backups are unaffected and can be used to restore operations from a different site. The tradeoff: restoring from off-site requires network connectivity (WAN or internet) and takes longer than a local restore. Off-site storage also typically carries ongoing financial cost — storage fees, bandwidth charges, or transport costs if physical media is shipped.
Most organizations use both. On-site backups provide fast restoration for the common cases (file recovery, database restore after corruption). Off-site backups provide protection against site-level disasters (fire, flood, ransomware). The combination provides more copies of the data and more options when restoring — the two principles of backup resilience: redundancy and flexibility.
Backup Frequency — Matching Schedule to Risk
How often data is backed up determines the maximum amount of data that can be lost in the event of a failure — the Recovery Point Objective (RPO). If daily backups run at midnight and the system fails at 11:45 PM, up to 23 hours and 45 minutes of data changes are lost. If hourly backups run, the maximum data loss is 59 minutes. If replication runs continuously, the data loss can be near zero.
Not all systems warrant the same frequency. A production database processing thousands of transactions per hour needs much more frequent backups than a configuration file server whose contents change weekly. Most organizations maintain multiple backup sets at different intervals: daily backups that provide 30 recovery points per month, weekly backups that provide four recovery points covering the past month, and monthly backups that provide 12 recovery points covering the past year. This tiered approach balances storage cost (keeping every daily backup forever would be prohibitively expensive) against recovery flexibility (having only monthly backups would mean up to 30 days of data loss).
Backup scheduling also involves managing the performance impact of backup operations. Full backup jobs that run during business hours compete with production workloads for I/O bandwidth. Most organizations schedule full backups during off-hours and use incremental or differential jobs during the day. The schedule must account for backup window duration — the time required to complete the backup job — to ensure it finishes before the next business day begins.
Backup Encryption — The Stolen Tapes Problem
Backup media is an extremely attractive target for attackers. A single backup tape or backup file may contain a complete copy of an organization's databases, file servers, and application data — everything that an attacker would need. Unlike attacking a live system (which is monitored and defended), backup media is often stored, transported, and handled with far less security attention.
The scenario is not hypothetical. Backup tapes have been stolen from company vehicles during transport to off-site storage facilities, stolen from unsecured storage rooms, found in dumpsters after improper disposal, and accessed by unauthorized employees at storage facilities. In every case where the backup data was unencrypted, the theft resulted in a reportable data breach. In cases where the backup data was encrypted, the theft resulted in lost media — with no data exposure.
Encrypting backup data means that everything written to tape, disk, or cloud storage is converted to ciphertext readable only with the correct recovery key. Even if an attacker obtains the physical media or gains unauthorized access to the cloud storage bucket, they cannot read the data. This is especially important for cloud backups: when data is stored with a third-party cloud provider, the organization has no control over who within the provider's environment might access it, what other tenants share the infrastructure, or what happens during a provider-side breach. Encryption is practically mandatory for cloud backup storage.
The critical dependency of encrypted backups: the recovery key must be protected and available when needed. An encrypted backup without an accessible recovery key is permanently inaccessible. Organizations must store recovery keys separately from the backup media itself (a key stored on the same tape it encrypts provides no protection) and must ensure the key storage is itself resilient — a key stored only on the production server that was just destroyed by ransomware is no help at all.
Snapshots — Instant Point-in-Time Copies
Snapshots became the dominant backup method for virtual machines and cloud infrastructure because they make backing up an entire system as simple as clicking one button. A snapshot captures the complete state of a virtual machine — its operating system, configuration, all installed applications, and all data — at a specific point in time. The snapshot is set aside while the VM continues operating normally. If anything goes wrong — a bad patch, an accidental deletion, a malware infection — the administrator reverts to the snapshot, and the VM returns to exactly the state it was in when the snapshot was taken.
After the initial (full) snapshot, subsequent snapshots are typically incremental: they store only the data that has changed since the previous snapshot. This is similar to an incremental backup — not a full copy of the entire disk, just the delta. The initial Monday snapshot of a 100 GB VM captures all 100 GB. The Tuesday snapshot captures the 40 GB of files that changed since Monday — the 60 GB that remained unchanged are not duplicated. The Wednesday snapshot captures the 20 GB of new data added since Tuesday. Each day's snapshot is small and fast; restoring to any specific day is possible by applying the appropriate snapshot.
Snapshots are particularly valuable as a safety net before making significant changes: before applying a major OS update, before deploying new application code, before migrating configuration. Taking a snapshot immediately before a change means that if the change causes a problem, recovery is a few clicks and a few minutes rather than a full restore from backup. The ease and speed of snapshot operations is what makes them so widely used — a backup method that is fast and easy gets used; one that is slow and complex gets skipped.
Recovery Testing — A Backup Is Only Half the Job
Creating backups without testing restores is false security. An untested backup is an unverified assumption that the data can actually be recovered. Backup jobs can complete successfully while producing corrupted backup files. Backup software can report success while silently failing to capture critical data. Restore procedures documented in the DR plan can be outdated for the current backup software version. None of these failures are visible until a restore is attempted — and discovering them during an actual disaster is too late.
Recovery testing requires actually restoring data from backup to a test environment and verifying that the restored data is complete, consistent, and usable. This means not just that the files are present, but that applications can open and use them, databases return correct query results, and systems boot and function correctly. Restoring a file server is only half the test; the other half is confirming that the applications that depend on those files work normally against the restored data.
Recovery testing must cover all backup methods and all frequencies. If an organization runs daily, weekly, and monthly backups, the testing program should verify restores from all three. A monthly backup that was never tested may have been silently failing for months before anyone checked. Periodic audits — weekly for critical systems, monthly or quarterly for less critical ones — maintain confidence that the backup program is actually working.
Replication — Near-Real-Time Data Synchronization
Replication is fundamentally different from periodic backup. Instead of capturing the state of data at a scheduled point in time (every night at midnight, every hour on the hour), replication continuously synchronizes data from the source to one or more destination locations in near-real-time. When a file is saved or a database record is written at the primary site, that change is propagated to the replicated sites within seconds or minutes.
The result is that the replicated site always has a current copy of the data — not a copy from last night's backup, but a copy from the last few seconds. If the primary site experiences a failure or disaster, the replicated site can take over with minimal data loss. Replication is the technology that enables hot site disaster recovery: a hot site that is continuously receiving replicated data from the primary site can be activated within minutes because it already has all the current data.
The important distinction between replication and backup: replication propagates changes — including bad changes. If ransomware encrypts files at the primary site, replication may replicate those encrypted files to the replicated site within seconds, overwriting the good copies. Traditional periodic backups preserve a snapshot of the data at a point in time before the ransomware struck. This is why replication complements but does not replace periodic backups — replication provides fast recovery from infrastructure failures; periodic backups provide the historical copies needed to recover from data corruption or ransomware.
The Interrupted Write Problem
Storage systems write data in multi-step operations. A database transaction may require updating dozens of records across multiple files. A file save operation may involve writing data blocks, updating file system metadata, and modifying directory entries. If power is lost — or the system crashes — in the middle of this multi-step process, some operations complete and others do not. The result is a partially written state that is internally inconsistent: the data structures reference entries that don't exist, or the file size metadata doesn't match the actual data written, or a database record is half-updated.
This partial write corruption is often not immediately apparent. The file system may appear intact, the database may appear to start normally, and only specific queries or operations against the corrupted data reveal the problem. By the time corruption is discovered, the window for easy recovery may have passed. The options without protection are painful: restore the database from the last good backup (losing all changes since that backup) or attempt manual data repair (slow, expert-intensive, and imperfect).
How Journaling Works
Journaling (also called write-ahead logging) solves the interrupted write problem by inserting an intermediate step before data is written to its final location. Instead of writing changes directly to the storage target, the system first writes the intended change to a journal — a sequential log stored on the same device. Once the journal entry is confirmed written, the actual data write to the storage target proceeds. Once the storage write completes, the journal entry is cleared.
This two-phase approach creates a safety net for every possible failure point:
If power fails while writing to the journal: Nothing was written to the actual storage target yet. When power returns, the system starts up normally — the storage data is in exactly the state it was before the failed write. The incomplete journal entry is discarded. No corruption occurred.
If power fails between the journal write and the storage write completing: When power returns and the system starts up, it checks the journal. The journal contains an entry for an operation that has not been confirmed as complete. The system replays the journal entry — re-applies the intended write operation — and completes what was interrupted. The data is brought to a consistent state automatically during startup, before any application accesses it.
Once both the journal write and the storage write complete successfully: The journal entry is cleared, and the process starts again for the next operation. No record needs to be kept of successful operations.
The result is that a journaled file system or database can always recover from an interrupted write at startup, without needing to restore from backup and without losing committed data. Modern file systems (NTFS, ext4, XFS, APFS) and databases use journaling or similar transaction log mechanisms as a standard feature. The performance cost is small (one extra write per operation) compared to the recovery benefit.