Is a snapshot automatically a sufficient backup?

Not always. Its consistency, retention, independence and ability to survive the relevant failure must be understood.

Does encryption make a backup recoverable?

Encryption protects confidentiality, but recovery also requires usable data, the necessary keys and a functioning restore procedure.

Can backups prevent an outage?

They support recovery after loss. Continuity during a failure may additionally require redundancy, failover and spare capacity.

AI Glossary / Data engineering and architecture / Beginner

Backup

Definition

A backup is a retained copy of data, or a recoverable representation of it, created so information can be restored after loss, corruption, unwanted change or another failure. Its usefulness depends on being complete enough, protected and actually restorable.

What it means

Saving a document updates the working copy. Backing it up preserves a recovery option beyond that working copy. The distinction matters when a file is deleted, a device fails or a damaging change goes unnoticed for several days.

A backup can cover individual files, databases, entire systems or selected application resources. It may preserve a complete state or combine a base copy with later changes. A recovery process must understand which pieces belong together.

For AI projects, useful coverage may include source data, labels, model artifacts, configuration and the information needed to reproduce or run a service. Keeping model weights alone might not preserve the feature definitions or tokenizer they require. The backup scope should follow what the team needs to recover.

How it works

A backup process selects data, captures it using an appropriate method, records the recovery point and stores the result under a retention policy. Full backups capture the chosen scope; incremental approaches capture changes relative to an earlier state and depend on their recovery chain.

Applications that change while being copied need consistency-aware methods. Database tools can coordinate a valid backup or combine a base backup with transaction logs. PostgreSQL, for example, documents SQL dumps, file-system approaches and continuous archiving as distinct techniques with different assumptions.

Recovery reverses the process: select a suitable point, obtain all required pieces, restore them into an appropriate environment and validate the result. A completed backup job is evidence that a process ran, not sufficient proof that the application can be recovered. Restoration exercises expose missing files, inaccessible keys and mistaken assumptions.

Three practical examples

A family preserves dated copies of photos separately from its everyday computer, then checks that sample images can be restored.
A small business backs up its operational database and tests restoration of representative records and application access.
An AI team retains a model release together with its configuration and required preprocessing assets, allowing an approved version to be reconstructed after accidental loss.

Think of it this way

Think of keeping a dated duplicate of an important notebook in another safe place. If the working notebook is damaged, the duplicate can help reconstruct what was known at that date.

The analogy has limits. A complex application resembles several linked notebooks, and copies taken at incompatible times may disagree. The safe place also needs protection: a duplicate stored beside the original can be lost in the same incident, and an unreadable duplicate is little help.

Worked example

Separating data loss from recovery time

An invented booking service has a usable backup representing its database at 09:00. A failure occurs at 10:20. If that backup is the only recovery material available, restoring it leaves an 80-minute gap between the recovered state and the failure. Changes made during that gap need another source or are unavailable.

Suppose the team restores the service by 12:00. The interruption from 10:20 to 12:00 is 100 minutes. These are different measures: the recovered data is 80 minutes behind, while service recovery took 100 minutes.

If valid archived transaction logs allow recovery through 10:15, the data gap becomes five minutes, but restoration might still take 100 minutes. Recovery point objective describes the acceptable data-loss window; recovery time objective describes the acceptable time to restore service. Neither objective is met merely by scheduling a backup job. These numbers are illustrative, not a guarantee of any backup product.

Illustrative case study

A fictional design studio stores client files in a synchronized folder and assumes the second device provides sufficient recovery. An accidental bulk deletion propagates to that device. During a review exercise, the studio discovers that its recovery options depend on the service's retained history and account access.

It establishes a separate backup process with defined retention and protected access. Staff practice restoring a project, including linked assets and the information needed to open it. The exercise also identifies who can retrieve encrypted backups if the normal workstation is unavailable.

The lesson is to verify a recovery path rather than infer one from the existence of another copy. This scenario is fictional and makes no claim about a particular synchronization provider.

Common misconceptions and mistakes

Treating live replication or synchronization as a complete backup strategy. Unwanted changes can propagate.
Keeping every recovery copy under the same exposed credentials and failure boundary.
Checking only that backup files exist, without testing whether they can be restored and used.
Forgetting encryption keys, configuration or dependencies needed to interpret the restored data.
Retaining only very recent copies when corruption may remain unnoticed for longer.

Business use

For a business, decide what must be recovered and how much interruption and data loss are tolerable. Assign an owner, define retention and protect backup access separately where appropriate. CISA advises offline, encrypted backups of critical data and regular recovery testing as part of ransomware resilience.

Balance recovery needs with storage, access and information-retention requirements. Verify what a managed service includes rather than assuming the subscription covers every application resource. Measure actual restore exercises, including verification and reconnection of dependent services. The useful question is whether the organization can return to an acceptable working state, not just whether its dashboard shows successful copies.

Check your understanding

A team backs up every hour but has never restored its database. Can it claim a ten-minute recovery time?

Answer: Not from that information. Backup frequency concerns recovery points; restoring, checking and reopening the service takes separate time that must be demonstrated.

Related terms

Point-in-time recovery
Replication (statistics)
Restore
Recovery point objective
Recovery time objective
Snapshot
Incremental backup
Replication
Disaster recovery
Data retention

Learn next

Choose a non-production example and document everything required to restore it, including keys and configuration. Restore it into an isolated environment, verify its contents and record elapsed time. Compare the outcome with the intended recovery objectives.

Sources

Primary sources: PostgreSQL backup and restore overview: https://www.postgresql.org/docs/18/backup.html ; PostgreSQL continuous archiving and recovery requirements: https://www.postgresql.org/docs/18/continuous-archiving.html ; CISA StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide . PostgreSQL documentation and relevant CISA indexed guidance reviewed; direct CISA page retrieval was unavailable. Timing calculations and the studio scenario are original illustrations.

Previous: Backtranslation Next: Backup validation