After eradicating malware from a file server, the team plans to restore from backup. Which action best validates the backup is clean before restoration?
Select an answer to reveal the explanation.
Short Explanation
Think of a backup like a sealed evidence bag: if the seal is broken, it doesn't matter how clean it looks. You verify the hash and integrity against a known-good baseline first, then restore. The trap is scanning after you've already put the data back into service.
Full Explanation
Restoration is the recovery phase, but it only works if the source image is trusted. A hash and integrity check compares the backup artifact to a known-good baseline or original backup manifest, proving it has not been altered, corrupted, or poisoned by malware. This is performed before restoration because the goal is to validate cleanliness of the source, not merely detect problems after deployment. An isolated restore and scan can support investigation, but it still restores untrusted data before validation and may miss dormant or polymorphic content. File size and timestamp comparison is too weak because malware can preserve metadata and size while changing payloads. Scanning the production server after restoration reverses the control order, because once data is back in service the incident may recur and containment is weakened. Exam caveat: CompTIA often distinguishes recovery from verification, so choose the pre-restoration integrity action when the stem asks to validate backup cleanliness. Operational check: Compare the backup's cryptographic hash and manifest against the stored baseline, then document the verified artifact ID before initiating the restore.