CompTIA A+ Core 2 (220-1202), Domain 4.0, Objective 4.3 focuses on recovery and backup testing, which means proving you can get systems and data back after something goes wrong. Recovery is the act of restoring service and data to a usable state. Backup testing is the practice of restoring on purpose, on a schedule, to confirm the backups work. This objective matters on the exam because it tests judgment, not just terms. It also matters at work because a backup that can't restore is only a file that takes up space.
You'll learn how to choose between in-place (overwrite) recovery and alternative-location recovery, and how to set a practical backup testing frequency based on risk.
What recovery means in real life, and why the exam cares
Recovery has one goal: get the user or business working again with the right data, with the least risk. That sounds simple, yet failures tend to arrive in messy combinations. A laptop drive dies, and the last sync didn't run. A ransomware alert appears, and no one knows when the infection started. An update breaks a line-of-business app, so the "fix" might be rolling back the system, not just restoring files.
It helps to separate three related terms:
- A backup is a stored copy of data (and sometimes system state) made earlier.
- A restore is the action of copying that data back from the backup set.
- Recovery is the larger outcome, which includes restores plus the steps needed to return to normal use (permissions, apps, settings, validation, and user access).
The exam cares because technicians often rush to restore. Rushing can overwrite good data, reintroduce malware, or restore the wrong version. In practice, recovery is a controlled decision under time pressure.
Common triggers show up repeatedly in tickets and incidents:
- Drive failure or file system damage
- Ransomware or other malware
- Bad patch, driver, or firmware update
- Accidental user deletion
- Data corruption from crashes or power loss
To make recovery choices quickly (and answer exam questions cleanly), keep a short decision checklist in mind:
- What happened? Hardware failure, deletion, corruption, or suspected malware?
- How much loss is acceptable? Minutes, hours, or days of missing work?
- How fast must service return? Is this a "right now" outage or a slower repair?
- Where will the restore land? Same location (overwrite) or a separate location for review?
Treat every restore as a change to production data. If you can't explain the risk, pause and re-check your assumptions.
Quick terms you must know: RTO, RPO, and restore point
RTO (Recovery Time Objective) is how fast you must be back online. A small office POS system might need a 1-hour RTO because sales stop without it. A home user might accept a 1-day RTO because the impact is lower.
RPO (Recovery Point Objective) is how much data you can afford to lose. If a team saves work all day, a 24-hour RPO can be painful. In contrast, a personal photo archive might tolerate a longer RPO if changes are rare.
A restore point (or a chosen backup version) is the point in time you restore to. Shorter RPO targets push you toward more frequent backups and more careful version selection. Tight RTO targets often push you toward faster restore methods, but speed should not ignore safety.
Common recovery mistakes that cause extra downtime
- Restoring without checking free space: Confirm destination capacity first, then restore.
- Restoring encrypted data without keys: Verify keys, certificates, or recovery passwords before you start.
- Restoring to the wrong device or path: Double-check the target volume and folder, then proceed.
- Skipping a malware scan after an incident: Scan the system and the restored data before user access.
- Assuming permissions will "just work": Validate access control lists and ownership after the restore.
- Failing to document what you did: Record the restore point, steps, and results for repeatability.
In-place (overwrite) recovery, when it fits and when it can backfire
In-place (overwrite) recovery means you restore data back to the original location, replacing what is there now. For example, you restore C:\Users\Alex\Documents\Budget.xlsx over the current copy. This method often feels fastest because the user's workflow stays the same. Paths do not change, shortcuts still work, and apps find their files where they expect them.
In-place recovery fits best when the situation is clear and contained. A user deleted a folder and you have a known-good backup from last night. A file became corrupted, and you can confirm the earlier version opens correctly. In these cases, overwriting reduces steps and speeds the handoff back to the user.
However, overwrite restores can backfire.