TOEIC Link — Data Backup and Disaster Recovery Plan Vocabulary Cluster

Losing data is a business event, not just a technical one, which is exactly why it shows up in TOEIC Link IT and operations passages. A backup memo, a recovery plan, or a post-outage report rarely tests whether you know a file was copied; it tests whether you can read the two numbers that govern the whole discipline — how much data an organization can afford to lose, and how long it can afford to be down — and whether you can tell an on-site copy from an off-site one. Those distinctions decide what the passage's questions are really asking, and a reader who fixes them first has the memo anchored before the options appear.

This guide walks the backup cycle from schedule to restore as a connected sequence, isolates the recovery-objective vocabulary the test leans on, and closes with a drill protocol. It builds on general IT support terminology and pairs with the IT helpdesk ticket and access request vocabulary cluster, since a failed restore often begins as a ticket, and with the orientation in what TOEIC Link measures.

The backup cycle as a schedule-driven sequence

The organizing fact is that a backup is not a single act but a repeating schedule, and the schedule decides how much can be recovered. The passage reasons about where a failure fell inside that schedule, so a reader who tracks the timeline reads the memo the way it was written.

A backup begins with a backup schedule — how often copies are made and of what. The most complete is a full backup (a copy of everything), which is slow and storage-heavy, so it usually runs weekly. Between full backups, an incremental backup copies only what changed since the last backup of any kind, while a differential backup copies everything changed since the last full one. A passage may hinge on this pair: recovering from incrementals requires the full backup plus every increment in order, so a single missing increment breaks the chain — whereas a differential needs only the full backup plus the latest differential. The test likes memos where one link is missing and expects the reader to infer that the restore is incomplete.

The copy has to live somewhere, and where decides how well it survives a disaster. An on-site backup (kept in the same building) restores fast but dies with the building; an off-site backup or cloud backup survives a fire or flood but restores slower. The disciplined pattern is the 3-2-1 rule — three copies, on two kinds of media, one off-site — and a passage may present an organization that had backups but kept all of them on-site, expecting the reader to see why a flood wiped out both the original and the copy.

The recovery-objective vocabulary — where the two numbers live

The heart of a disaster-recovery passage is a pair of targets, and the test concentrates its inference questions there. The two are the recovery point objective and the recovery time objective, and confusing them is the single most common trap.

The recovery point objective (RPO) is how much data the organization can afford to lose, measured backward in time from the failure. An RPO of one hour means backups run at least hourly, so a failure loses at most an hour of work. A passage that states "backups run nightly" and then asks about a crash at 4 p.m. expects the reader to infer that a full day's changes are gone — the RPO is a day, not an hour. RPO is about the backup frequency, and a shorter RPO demands more frequent copies.

The recovery time objective (RTO) is how long the organization can afford to be down before service must resume, measured forward from the failure. An RTO of four hours means systems must be back within four hours, regardless of how much data was saved. A passage frequently pairs the two to test whether the reader keeps them separate: a system can meet its RPO (little data lost) yet miss its RTO (took too long to restore), or the reverse. The judgment in these memos lives in that gap — "we recovered the data but not in time" is a specific, testable failure, and the vocabulary is the only thing that names it.

Around the two objectives sits the restore vocabulary. To restore is to write a backup back into production; a test restore (or restore drill) verifies the backup actually works before a real disaster, and a passage may turn on an organization that never tested its restores and discovered too late that the backups were corrupted — copied faithfully but unreadable. A backup that cannot be restored is not a backup, and the test rewards readers who catch a memo admitting the restore was never verified.

The failure and failover vocabulary — where continuity is decided

When the primary system goes down, the vocabulary shifts to how service keeps running, and this is where the harder passages live. The central term is failover.

Failover is the automatic switch from a failed system to a standby one. The standby may be a hot site (a fully running duplicate, instant but expensive), a warm site (partly ready, some delay), or a cold site (bare space and hardware, cheapest but slowest to bring up). A passage may state a budget and a required RTO and expect the reader to infer which site type fits — a four-hour RTO rules out a cold site, which takes days. Once the primary is fixed, failback returns operations to it, and a passage may hinge on a rushed failback that reintroduced the original fault.

The plan that governs all of this is the disaster recovery plan (DRP), usually nested inside a broader business continuity plan (BCP). The distinction matters and the test probes it: a DRP restores IT systems, while a BCP keeps the whole business operating — including people, facilities, and manual workarounds — while IT is down. A passage may present an organization whose systems recovered on schedule but whose staff had no procedure to serve customers in the interim, expecting the reader to see that the DRP worked but the BCP was missing. Escalation and notification vocabulary rounds this out, echoing the alerting logic in the workplace safety and incident report vocabulary cluster: an incident triggers the plan, an on-call engineer is paged, and a post-incident review records what to fix.

Retention and archive vocabulary

Once data is safe, the surrounding vocabulary governs how long it is kept, and passages test it. A retention policy sets how long backups are held before being purged (deleted to free space), and a passage may hinge on a customer or auditor who requested data that fell outside the retention window and no longer exists. Distinct from a backup is an archive — a long-term copy kept for compliance or reference rather than recovery, often on cheaper cold storage. The test likes memos that conflate the two: a backup is for restoring recent data quickly; an archive is for retrieving old data rarely, and using one for the other's job is a recognizable mistake, much like renewing a license too late in the software license and subscription renewal vocabulary cluster.

Verification vocabulary closes the loop. A checksum or integrity check confirms a copy is intact; a backup log or job report records whether the nightly run succeeded or failed; a monitoring alert flags a run that silently stopped. A passage may present a team that assumed backups were running because no one reported a problem, expecting the reader to infer that no news was not good news — the job had been failing unnoticed for weeks.

Drill protocol — reading backup and recovery passages under time pressure

Practice this cluster with a fixed routine so the continuity logic becomes reflex rather than recall.

First, on any recovery passage, separate the two numbers before reading the questions: RPO is how much data you can lose (points to backup frequency), RTO is how long you can be down (points to failover and site type). Deciding which one a question asks about predicts the answer more reliably than rereading the memo.

Second, locate where the copy lives — on-site, off-site, or cloud — because that single fact governs whether a physical disaster is survivable. A passage describing a fire or flood is almost always testing whether the backup shared the building's fate.

Third, watch for the untested restore and the unnoticed failure. When a memo says backups "ran" but never says they were verified, the passage is usually built around the moment the restore was attempted and failed. Reading the absence of a test is as important as reading the presence of a backup.

Drilled this way, backup and recovery passages resolve into two numbers and one location, and the vocabulary stops being a list of IT terms and becomes a map of exactly what the memo is testing.