How to Validate Backups Meet Recovery Time Objectives
A virtual file server was restored from last night’s backup. The service is online, but some finance users report missing spreadsheet changes and a few files show a 'recovered copy' timestamp. Which two checks should be completed before the team accepts the restore as successful? Select two.
⚠ Common exam trap
Many exam-takers assume a service being online and shares browsable is sufficient proof of a successful restore, ignoring the need for data integrity verification and application-level validation.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Compare restored data against backup hashes or a manifest to verify that the copy is complete and uncorrupted.
Comparing restored data against backup hashes or a manifest ensures the data integrity and completeness of the restore process. Even though the file server is online, missing spreadsheet changes and 'recovered copy' timestamps suggest possible corruption or incomplete restoration. Verifying hashes (e.g., SHA-256) against a known-good manifest confirms that every file was restored without bit-rot or truncation, which is a standard post-restore validation step in backup and recovery procedures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Compare restored data against backup hashes or a manifest to verify that the copy is complete and uncorrupted.
Why this is correct
Hash or manifest comparison confirms that the restored files match what was backed up and were not corrupted during storage or recovery. This is a direct integrity check and is more reliable than simply seeing that the server starts. It helps identify silent partial restores.
- ✓
Run an application-level validation test with finance users or sample transactions to confirm the data is usable.
Why this is correct
A backup is only successful if the restored data works for the business process that depends on it. Application-level validation catches issues that file-level checks may miss, such as incomplete documents, missing sheets, or inconsistent data structures. This also confirms the restore meets operational needs, not just technical ones.
- ✗
Assume the restore is acceptable because the file server is online and users can browse shares.
Why it's wrong here
A file server that comes online and allows users to browse shares only proves that the operating system and SMB/network services are functioning, not that the restored data is complete or uncorrupted. File-level corruption, missing directories, or a partial volume mount could leave the system looking healthy while critical files are unusable. Without comparing the restored files against backup hashes or a manifest, you are relying on visual availability that cannot detect silent, bit-level damage or verify that every expected object is present.
- ✗
Delete the previous night’s backup so the team will not accidentally restore it again.
Why it's wrong here
Deleting the previous night's backup immediately after a restore is risky because the restore has not yet passed integrity checks, and that older copy may be your only fallback if the new restore is later found to be incomplete or corrupted. The prior backup also provides a baseline for comparing file versions and can be used to re-restore specific items if the current restore has subtle gaps. Retaining multiple restore points until the new restore is fully validated is a fundamental data-protection practice that preserves recovery options and prevents you from being left with no usable copy.
- ✗
Expose the restored server directly to the internet so remote users can test it faster.
Why it's wrong here
Exposing a newly restored server directly to the internet is a serious security misstep because the integrity of the restored data has not yet been validated. Placing an unverified system on a public network exposes it to opportunistic attacks, and remote users may inadvertently access incorrect or partial data, creating a false sense that the recovery succeeded. Restore validation should take place in an isolated, controlled environment with security patching and no external reachability until the backup is confirmed to be complete and uncorrupted.
Go deeper
Related to this question
Learn chapter
Purple Team Operations
Key term
SHA-256
SHA-256 is a cryptographic hash function that takes any input data and produces a fixed 256-bit string of characters, like a unique digital fingerprint, used to verify data integrity and secure passwords.
Key term
Integrity
Integrity is the assurance that data has not been altered or tampered with in an unauthorized way, preserving its accuracy and consistency from source to destination.
About these practice questions
Courseiva writes every SY0-701 question from scratch — 1,030 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SY0-701 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SY0-701 exam.