Backup & RecoveryGlossary

A copy of your files, applications, or systems kept somewhere safe so you can restore them if the originals are lost, corrupted, deleted, or encrypted by ransomware. Different from disaster recovery — backups are the data; DR is the plan for getting the business running again using them.

Why it matters: Backups are necessary but not sufficient. Without verified, tested backups, recovery from a ransomware event isn't possible. Without a documented recovery plan around them, restoring is slow and chaotic.

Related: Disaster Recovery, BCDR, Backup Verification, Local Backup, Cloud Backup

A backup copy of your data stored on a device physically in your office or building — a NAS, an external drive, a backup server. Restores are fast because the data is right there; the trade-off is that anything destroying the originals (fire, flood, ransomware on the network) can destroy the backup too.

Why it matters: Local backups give the fastest restores for everyday "I deleted a file" scenarios. The 3-2-1 rule says: have at least one local backup AND one offsite (usually cloud) backup, so you're covered in both common and rare disaster cases.

Related: Cloud Backup, Backup, 3-2-1 Rule, Hybrid Backup

A backup copy of your data stored in a cloud provider's data centers rather than on a physical device in your office. Restore from anywhere with internet, survives local disasters (fire, flood, theft), and scales without buying more hardware.

Why it matters: Local-only backups can be destroyed by the same event that took out the originals — ransomware that finds the backup drive, a fire that destroys the server room, a stolen NAS. Cloud backups separate the copy from the disaster.

Related: Local Backup, Backup, Immutable Backup, Egress Fees, Hybrid Backup, 3-2-1 Rule

A backup strategy that combines local backup (for fast restores) with cloud backup (for offsite disaster resilience). The local copy handles everyday restores; the cloud copy survives events that destroy the office. The practical implementation of the 3-2-1 rule for most small businesses.

Why it matters: Cloud-only backups make small restores (a single deleted file) painfully slow over the internet. Local-only backups can be destroyed by the same event that hit the originals. Hybrid avoids both problems and is now the default for most managed-backup services.

Related: Local Backup, Cloud Backup, 3-2-1 Rule

A backup that captures the entire system — operating system, applications, settings, and data — as a single image file. Restoration recovers the entire machine in one operation, including booting back into a fully configured OS.

Why it matters: Image-based backups make full server or workstation recovery dramatically faster than rebuilding from scratch. After a ransomware or hardware-failure event, you restore the image instead of reinstalling Windows, then your apps, then your settings, then your data.

Related: File-level Backup, Disaster Recovery

A backup that copies individual files and folders — not the operating system or applications. Smaller backups, faster to run, easy to restore individual items, but doesn't help recover a fully crashed system without first rebuilding the OS.

Why it matters: File-level backup is sufficient for data-only protection. For full system recovery, image-based backup is faster. Most managed backup tools today do both: image-based for system recovery, file-level for granular restores.

Related: Image-based Backup

A complete copy of all selected data — every file, every time. Largest in storage, slowest to run, but simplest to restore from (one backup contains everything). Often the starting point in a chain of incremental or differential backups.

Why it matters: Full backups are typically run weekly or monthly; daily backups are usually incremental or differential to save time and space. Restore speed is fastest from a full backup; rebuilds from incrementals require multiple steps.

Related: Incremental Backup, Differential Backup

A backup that includes only the data that has changed since the LAST backup (full or incremental). Smallest and fastest to run, but restoring requires replaying the full backup plus every incremental in sequence — slower and more failure-prone.

Why it matters: Incrementals make daily backups practical even for large datasets. The trade-off is restore complexity — losing one incremental in the middle of a chain can compromise everything after it.

Related: Full Backup, Differential Backup

A backup that includes everything that has changed since the last FULL backup (not the last incremental). Grows over time until the next full backup resets the baseline. Restore requires only the full backup plus the most recent differential — simpler than incremental chains.

Why it matters: Differential sits between full and incremental: bigger and slower than incremental, faster and simpler to restore from. Useful when restore speed matters more than backup-window length.

Related: Full Backup, Incremental Backup

The combined plan for keeping your business running during disruptions (continuity) and getting back to normal operations after (recovery). Covers everything from ransomware to power outages to natural disasters.

Why it matters: Most businesses without a BCDR plan don't survive a major disruption. Cyber insurance now typically requires documented plans.

Related: Business Continuity, Disaster Recovery, RTO, RPO, Failover, Backup

The maximum acceptable downtime for a system or business function before significant impact. "Our email RTO is 4 hours" means we'd consider it a serious problem if email was down longer than 4 hours.

Why it matters: Setting RTOs forces you to think about which systems matter most — and to size your backup/recovery solutions accordingly.

Related: RPO, BCDR, MTTR, Disaster Recovery

The maximum acceptable amount of data loss measured in time. "Our RPO is 1 hour" means we can tolerate losing up to 1 hour of work in a recovery scenario, so backups must run at least hourly.

Why it matters: RPO drives your backup frequency. If your last backup was 24 hours ago and you have an hour-RPO requirement, you're not actually meeting it.

Related: RTO, BCDR, Disaster Recovery

The documented plan, processes, and infrastructure that get a business back up and running after a major disruption — ransomware, fire, flood, hardware failure, or extended outage. DR uses backups, failover systems, and trained people to restore operations within a defined recovery window.

Why it matters: Backups by themselves aren't a plan. DR is the plan: who restores what, in what order, with what target time. Cyber insurance increasingly requires a documented DR plan as a policy condition.

Related: Backup, BCDR, RTO, RPO, Failover, Failback, Image-based Backup, Business Continuity, Recovery Drill

The discipline of keeping critical business functions operating during and after disruption — not just IT, but people, processes, facilities, and vendors. Disaster Recovery is the IT-focused subset; Business Continuity is the broader plan that includes "how does the receptionist work if the office is closed?"

Why it matters: IT-only recovery plans miss things like "the building is inaccessible," "key staff are unavailable," or "our primary vendor is down for a week." A BC plan thinks through the business operations as a whole, not just the technology.

Related: BCDR, Disaster Recovery

The process of returning operations to the primary system after a failover event — once the primary has been repaired or replaced. Often more complex than the failover itself, because data accumulated on the standby system during the outage has to merge back to the primary.

Why it matters: Many organizations practice failover but skip failback testing — then discover at the worst time that returning to normal is harder than getting through the disaster. A complete recovery plan includes both.

Related: Failover, Disaster Recovery

The average time it takes to restore a system after a failure, measured across many incidents. Sometimes "Mean Time To Repair" (focused on fixing the broken thing) or "Mean Time To Recover" (focused on getting the business back up). The actuals matter; the words are often used interchangeably.

Why it matters: MTTR is the operational reality check on RTO. If your stated RTO is 4 hours but historical MTTR for similar incidents is 12 hours, the RTO is aspirational. Tracking MTTR is the way to know whether recovery capability is improving.

Related: RTO, Resolution Time

A backup stored in a way that prevents modification or deletion for a defined retention period — even by administrators with full system access. Implemented through object-storage "write once, read many" (WORM) policies or hardware-enforced lock periods. Ransomware can encrypt the originals but not the immutable copies.

Why it matters: Modern ransomware attackers specifically target backup systems, attempting to delete or encrypt backups before triggering the main attack. Immutable backups defeat this attack pattern — even compromised credentials can't reach the locked copies.

Related: Air-gapped Backup, Cloud Backup, Ransomware, 3-2-1 Rule

A backup that is physically disconnected from the production network when not actively being written or read. Could be tape rotated offsite, removable drives stored in a safe, or a backup system on an isolated network segment. Attackers on the production network can't reach data that isn't connected.

Why it matters: Air-gapping is one of the strongest defenses against ransomware reaching backups. The trade-off is operational friction — humans have to handle the disconnection / reconnection, and restores take longer. Often combined with immutable backups for layered protection.

Related: Immutable Backup, 3-2-1 Rule

The standard backup best practice: keep at least THREE copies of important data, on at least TWO different storage media, with at least ONE copy stored offsite. A modern variant (3-2-1-1-0) adds: one copy immutable or air-gapped, and zero errors verified.

Why it matters: The 3-2-1 rule directly addresses the most common backup failure modes: ransomware reaches connected backups (offsite copy), storage device fails (multiple media), local disaster destroys everything (offsite copy). Simple to remember; rare to actually do consistently.

Related: Local Backup, Cloud Backup, Immutable Backup, Air-gapped Backup, Hybrid Backup

The practice of automatically confirming that completed backups are valid — file counts match, checksums verify, backup catalogs are intact. Distinct from test restores, which actually attempt to use the backup to recover data.

Why it matters: A backup that runs successfully doesn't prove it's restorable. Many businesses discover during a real incident that years of backups were corrupted or incomplete. Continuous verification catches the problem when there's still time to fix it.

Related: Test Restore, Backup

The practice of periodically performing actual restorations from backups to verify they work end-to-end — files come back intact, applications start, systems boot. The only definitive proof a backup is usable.

Why it matters: Backup verification confirms files exist; test restores confirm the business can actually use them. A monthly or quarterly test restore is the standard practice; some compliance frameworks require it.

Related: Backup Verification, Recovery Drill

A planned exercise that simulates a recovery scenario — "the file server has been encrypted by ransomware, restore it." Includes restoration steps but also communication, decision-making, and coordination across the people who'd handle a real incident.

Why it matters: The first time a team executes a recovery should not be during the real disaster. Drills surface gaps in documentation, missing access permissions, and decision bottlenecks — all easier to fix in a planned exercise than under pressure.

Related: Test Restore, Disaster Recovery

Storage optimized for long-term retention of data that's rarely accessed — much cheaper per terabyte than active storage, but with retrieval delays measured in hours. AWS Glacier, Azure Archive Tier, and physical tape libraries are common implementations.

Why it matters: Cold storage is the right answer for backups that need to be kept for years (HIPAA records, financial audit data) but realistically may never be read. The cost savings are substantial; the trade-off is accepting that emergency restores will take longer.

Related: Hot Storage, Retention Policy

Storage optimized for fast, frequent access — backups can be restored in minutes, files can be opened directly. Most expensive per terabyte but necessary for recent backups that need to be ready for emergency restores.

Why it matters: A common backup architecture uses tiered storage: last 30 days in hot storage (fast restore), older backups moved to cold storage (cheap retention). The cost difference between tiers is often 5-10x.

Related: Cold Storage

The documented rules for how long backup copies are kept before being automatically deleted. Driven by recovery needs (how far back do we need to be able to restore?), compliance requirements (HIPAA mandates 6 years, SOX 7 years), and storage cost.

Why it matters: Without an explicit retention policy, backups either pile up forever (wasting storage) or get deleted prematurely (missing the data that's actually needed). Policies should be reviewed annually as compliance requirements and data volumes change.

Related: Cold Storage, HIPAA