What is data backup? Types, storage and recovery explained

Data backup is the process of creating recoverable copies of files, applications or systems so they can be restored after deletion, corruption, equipment failure or an attack. A useful backup plan specifies what is protected, how often copies are made, where they are stored and how recovery will be tested.

For a household, the priority might be documents, photos and a computer that can be rebuilt after a failed drive. For a business, it can include applications, databases, identities, configuration and the information employees need to serve customers. The right approach starts with what must be recovered and how quickly it is needed.

Data can become unavailable through an ordinary mistake as well as a major incident. Someone may overwrite a document, a storage device may fail, a laptop may be stolen or a site may become inaccessible. Malicious activity can affect both production information and recovery systems.

Backups provide an earlier state to recover from. They do not prevent every outage or undo the disclosure of stolen information. Their value depends on coverage, the age of the available copies, protection from the original incident and the ability to restore what matters.

For businesses, the practical consequences extend beyond missing files. An order-processing application may depend on its database, configuration and access accounts. Recovering only one component may leave the service unavailable. Identify these dependencies before choosing a backup product or schedule.

Backup creates and retains recovery copies. Recovery uses an appropriate copy to return information or a system to a usable state. A completed backup job is evidence that a copy was created; a successful restore test provides evidence that it can support the intended recovery.

Disaster recovery adds the wider arrangements needed to restore IT services: people, instructions, replacement infrastructure, access, communications and the order in which dependent systems return. Business continuity also considers how essential work continues during disruption. Backups support these plans, but do not replace them.

Choose the scope according to what you would otherwise have to recreate.

Files and folders. Protect working documents, financial records, customer information, photos and other material whose loss would matter. Include locations outside the folders selected by default, and review exclusions.

Disks and systems. A system-image backup can include the operating system, installed applications, settings, boot information and selected data volumes. It supports rebuilding a machine as well as recovering individual items where the chosen tool provides that capability. Check the selected disks and required partitions; an image does not automatically include every attached drive, online account or cloud-only file.

Business applications and services. Databases and transactional applications may need application-aware backup to produce a recoverable state. Include virtual machines, relevant host or management configuration, cloud workloads and SaaS information where your recovery requirements call for them. Confirm each workload against the solution's support documentation.

Keep the backup catalog, recovery instructions, required software and protected access to recovery keys available. A copy is less useful if the only credentials or instructions for restoring it were on the failed computer.

These methods describe which data a backup captures. They are separate from the choice between file-level and image-based scope.

Incremental backups usually reduce the data transferred by each job, but the complete recovery chain must remain available. Differential backups accumulate more changed data as time passes after the full backup. A full backup can simplify the restore set while requiring more time and storage for that job. Actual performance depends on the workload, storage and implementation.

Some products assemble a synthetic full backup from an existing full backup and subsequent increments. Others use an incremental-forever approach. Check how the product maintains dependencies, applies retention and reconstructs a restore point rather than assuming every implementation behaves identically.

If a product offers reverse-incremental or hot backups, ask how it preserves earlier restore points and application consistency. For backups taken while applications remain active, a recovery test should check that the application can use the restored information, not only that the backup job completed.

Local and removable storage can provide convenient access for routine recovery. An external drive or dedicated local repository still needs protection from damage, theft and unauthorised access. A copy kept beside the original can be affected by the same site incident.

Network storage, including NAS, can centralise backups from multiple devices. Its access controls, administration and recovery procedures matter as much as its capacity. Storage that compromised accounts can modify is not isolated merely because it is a separate appliance.

Cloud backup retains recovery data at a remote service. Evaluate connection speeds, restore methods, retention, access controls, storage location and charges for retrieving or exporting information. Plan a realistic recovery when internet access is limited or a large data set must be transferred.

Tape and other offline media can provide a separate retention or offsite option. Allow for compatible hardware, secure handling, catalog access and the time needed to retrieve and read the media.

A hybrid design combines local and remote copies. It can support a nearby restore path and a separate option for a site outage. Choose the combination against recovery requirements rather than assuming one medium is always fastest, cheapest or sufficient on its own.

The 3-2-1 approach means keeping three copies of important data: the working copy and two backups, across two types of media, with one copy offsite. US-CERT's Data Backup Options explains this approach for personal and business information.

Also consider whether an attacker could reach every copy through the same accounts or management system. Offsite and offline describe different protections. An offsite copy may still be accessible online; an offline copy is disconnected while it is offline. Immutability can restrict alteration or deletion for a configured period, but its implementation and administrative controls need review.

The joint StopRansomware Guide recommends offline, encrypted backups of critical data and regular testing of their availability and integrity. Use those precautions alongside access controls and recovery practice, rather than treating the copy count as proof that recovery will work.

Base frequency on the information you can afford to lose and the service you need to restore. Data volume alone does not determine the schedule: a small but frequently changing database can be more time-sensitive than a large archive.

Two objectives help make this decision:

Recovery point objective, or RPO, describes the point to which data needs to be recoverable, commonly expressed as the tolerable period of lost changes. Recovery time objective, or RTO, sets the target for how long the relevant system or resource can remain unavailable. NIST's contingency-planning guidance explains how these objectives inform recovery planning.

For example, suppose a team sets a one-hour RPO. A daily backup alone leaves a potential gap much larger than that target. If the same service must return within four hours, its recovery test must account for locating a clean recovery point, restoring dependencies and validating operation. Setting the objectives does not establish that the current setup meets them.

Different workloads can have different targets. Choose schedules, retention and storage that support those targets, then measure the result. Avoid a universal rule that every organisation needs the same weekly full and daily incremental schedule.

Assign responsibility. Name the owner of the backup policy and the people who review failures, manage access and approve recovery. Include an alternate who can act when the usual administrator is unavailable.

Inventory the scope and dependencies. Record systems, locations, business owners and approved backup methods. Include remote devices and cloud services, and revisit the inventory when the environment changes. Prioritise the services whose absence would interrupt essential work.

Set schedules and retention together. Decide how many recovery points you need and how long to keep them. Allow for delayed discovery of corruption or deletion. Apply the organisation's retention and disposal requirements rather than keeping everything indefinitely by default.

Prepare more than one recovery path. Decide how to restore a single file, a complete machine and a business service. Record where replacement capacity, recovery tools and authorised credentials will come from if the original site is unavailable.

Monitor and test. Review failed, missed and unexpectedly small jobs, capacity alerts and gaps in protected devices. Test representative restores and repeat relevant tests after major system, application or backup changes. Keep a record of results and unresolved problems.

Start with who can administer the service and change or delete recovery data. Use appropriately restricted roles, strong authentication and MFA where supported. Separate backup administration from routine user activity, protect the management environment and keep its software updated.

Use suitable encryption for stored data and transfers. Protect the associated keys and recovery information separately from the data they unlock. Encryption protects confidentiality; it does not stop an authorised or compromised account from deleting data it has permission to remove, and it does not make a damaged backup usable.

Use isolated or appropriately immutable recovery copies as part of the design, and test the configuration. Check what can change the retention settings and which accounts can remove protection. NIST's storage-security guidance addresses access control, isolation, encryption and restoration assurance as related parts of storage security.

Ask suppliers how they maintain and secure the software, handle vulnerabilities and support recovery. The NIST Secure Software Development Framework provides a basis for discussing development practices with vendors. Integrity checks can help detect changes, but unchanged data is not automatically free of malware or suitable for every compliance requirement.

Match the restore method to the problem. Granular recovery retrieves an individual file or supported application item. Volume recovery restores a selected storage volume. Whole-system or bare-metal recovery rebuilds a machine from suitable system-level recovery data. Some solutions can run a supported VM directly from backup while further recovery continues.

Before restoring, establish the cause and extent of the failure and choose an appropriate recovery point. If compromise is suspected, coordinate with the incident-response team and use an assessed recovery environment. Restoring the most recent copy without investigation can reintroduce the problem.

Check the destination and overwrite behaviour before starting. After recovery, verify the files, permissions, applications and dependent services that users need. Compare the measured recovery time and available data with the objectives. A readable file is a useful test; a critical business service also needs an application-level test.

For a personal computer, distinguish the files you need from the environment you would need to rebuild. A file backup can protect documents and photos; a suitable system image can support recovery of the operating system, applications and settings within its scope. Check both the product's platform support and the recovery method before relying on it.

For native Windows options and file-restoration instructions, use our Windows backup and restore guide. For the image-based approach, see the full system-image backup guide. Keep an offsite recovery option and try a restore before an emergency.

Compare the solution against your recovery plan, rather than a feature total. Verify workload and operating-system support, file and image coverage, application consistency, storage choices, schedules, retention, encryption and recovery-key handling. Check that monitoring exposes unprotected workloads and failed jobs.

Evaluate appliance, self-managed software, hosted service and hybrid deployment options according to who will operate them and where recovery must happen. Include licensing, storage growth, network use, retrieval charges and administrator effort in the cost assessment.

Test recovery of representative data before committing. For a business or MSP, also assess central administration, reporting, role separation and the ability to manage different policies. Confirm that security and backup components can work together in the intended configuration.

Acronis Cyber Protect offers file-level and full-image backup for supported business environments. MSPs can evaluate Acronis backup for managed services, including central management and supported granular or system recovery. For home computers, Acronis True Image provides personal file and system-image backup options.

Compare the current product, plan, supported workloads and storage options with your requirements. Configure protection, retain the required keys and recovery media, and test restoration. No product name or successful-job notification substitutes for that check.

Is cloud storage the same as cloud backup? Cloud storage holds information remotely. A backup service adds a defined protection process, retained recovery points and restoration tools. Synchronisation can propagate unwanted changes or deletion. Check the service's actual versioning and recovery controls instead of assuming a synced folder is an independent backup.

Does a snapshot replace a backup? Snapshots can support recovery, but their protection depends on where they reside and what they depend on. A snapshot tied to the same affected storage may not provide an independent recovery path. Evaluate isolation and restoration, not the snapshot label alone.

Does a full backup include everything? It includes everything selected and supported by that job. Review disks, folders, application requirements, external devices and exclusions. Do not assume that a device backup captures information stored only in an online service.

Can backups guarantee that no data is lost? No. Recovery depends on the available recovery points, their integrity, access and the tested restore process. A sound plan reduces avoidable gaps and makes the remaining limitations visible before an incident.