Backup
A backup is a separate, restorable copy of data kept so that the original can be recovered after it is lost, corrupted, deleted or encrypted by an attacker. Its entire value is in the restore: a backup that cannot be turned back into working data is only a cost. Backups protect against hardware failure, human error, software bugs, theft, fire and flood, and in recent years above all against ransomware, which encrypts live files and demands payment.
The best-known planning guideline is the 3-2-1 rule: keep at least three copies of the data, on two different kinds of storage media, with one copy held off-site. The rule was popularized by the photographer and author Peter Krogh and is now standard advice. The three copies are the live data plus two backups; two media types, such as an internal disk and a cloud object store or tape, avoid a shared failure mode; and the off-site copy survives a local disaster. Modern variants add a fourth requirement, an immutable or offline copy that cannot be altered or deleted for a set time even by an administrator, because attackers who take over an account often try to destroy the backups first.
Backups differ in how much each run copies: a full backup copies everything, an incremental backup copies only what changed since the last backup of any kind, and a differential backup copies everything changed since the last full backup. Full backups are simple to restore but slow and large. Incremental ones are fastest and smallest to take, but a restore needs the last full backup plus every incremental after it in order, so one damaged link breaks the chain. Differentials grow day by day but need only the last full plus the latest differential. Real tools add deduplication, compression and snapshots, and many keep an incremental-forever scheme that periodically synthesizes a new full backup from existing pieces.
Two numbers turn the vague wish to be safe into a design target: the recovery point objective (RPO) and the recovery time objective (RTO). RPO is how much recent data can be lost, measured as time, so a nightly backup implies an RPO of up to a day. RTO is how long it may take to be working again after a failure. A shorter RPO needs more frequent copies or continuous protection, and a shorter RTO needs faster storage, standby systems and rehearsed procedures, and both cost money, which is why a payroll database and a scratch directory deserve different policies. These targets belong to the wider practice of disaster recovery, which also covers people, networks and application dependencies.
The most common failure is never testing a restore, and the most common confusion is treating replication or sync as backup. Backup jobs can quietly fail, write empty files, miss a database that was being written, or produce archives that are unreadable because the encryption key was lost along with the machine. Regularly restoring a sample, or whole systems in a drill, is the only proof. Replication, such as RAID mirroring, a synced cloud folder or a database replica, keeps copies current in real time, which is excellent for availability but means a deletion, a corruption or ransomware encryption is faithfully copied too. A backup keeps history, with older versions that can be rolled back to; replication keeps the present. Today these ideas also apply to machine-learning work, where training data, model checkpoints and experiment records are expensive to recreate.
Read backup as a promise measured only at restore time: independent copies in more than one place, an agreed limit on lost data and downtime, history that replication alone cannot provide, and a practiced recovery proving the copy actually works.