Validate backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to ensure backups are reliable for disaster recovery and ransomware response scenarios.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Validate backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to ensure backups are reliable for disaster recovery and ransomware response scenarios.
Verifying backup integrity before relying on backups for ransomware recovery
Building automated backup validation pipelines that run after each backup job
Auditing backup infrastructure to confirm recoverability for compliance (SOC 2, ISO 27001, NIST CSF RC.RP-03)
Detecting silent data corruption (bit rot) in backup storage before a disaster occurs
Validating that immutable or air-gapped backups have not been tampered with
Do not use for initial backup configuration or scheduling. This skill focuses on post-backup validation.
Common Misconfigurations & Verification
Archive integrity ≠ data integrity: a gzip -t pass or a valid restic check only proves the container is well-formed — the files inside can still be corrupted or pre-encrypted. Always hash individual files (SHA-256) against a baseline manifest, and run restic check --read-data / borg check --verify-data so the actual data blocks are read, not just the index.
The most-missed failure is trusting a backup that predates detection but not infection: if the ransomware dwell time exceeds the backup age, your "clean" restore point already contains encrypted files or the implant. Scan restored data for ransomware extensions, ransom notes, and high file entropy (>7.9/8.0) before certifying it recoverable.
Broken incremental chains fail silently: a single corrupted incremental invalidates every restore point after it, yet the backup job still reports success. Verify the full chain restores end-to-end, not just the latest snapshot.
Weak/odd hashing and "immutable" that isn't: MD5 is broken — use SHA-256/SHA-3. And confirm immutability is real (S3 Object Lock, Azure immutable blob) by attempting a delete/overwrite and confirming it's denied, plus verifying air-gapped copies haven't been silently re-mounted to the network.
Concrete verification it worked: restore to an isolated environment, then diff sorted baseline vs restored manifests (zero deltas), reconcile file counts and total size, run DB consistency checks (pg_restore --list, row counts), and confirm validation runs on a schedule with alerting on failure — a silently-logged failure is the same as no validation. Confirm the 3-2-1 layout actually holds (3 copies, 2 media, 1 offsite).
Prerequisites
Access to backup storage (local, NAS, S3, Azure Blob, GCS)
Python 3.9+ with (standard library)
hashlib
Backup manifests or baseline hash files for comparison
Isolated restore environment for restore testing
Backup tool CLI access (restic, borgbackup, rclone, or vendor-specific)
Workflow
Step 1: Generate Baseline Hash Manifest
Create a cryptographic fingerprint of every file at backup time:
# Generate SHA-256 manifest for a directory
find /data/production -type f -execsha256sum {} \; > /manifests/prod_baseline_$(date +%Y%m%d).sha256
# Verify manifest formathead -5 /manifests/prod_baseline_20260319.sha256
# e3b0c44298fc1c149afbf4c8996fb924... /data/production/config.yaml# a7ffc6f8bf1ed76651c14756a061d662... /data/production/database.sql
Step 2: Verify Backup Archive Integrity
Check that the backup archive itself is not corrupted:
Step 3: Perform Restore Test to Isolated Environment
# Restore to isolated test directory
restic -r s3:s3.amazonaws.com/backup-bucket restore latest --target /restore-test/
# Generate hash manifest of restored data
find /restore-test -type f -execsha256sum {} \; > /manifests/restored_$(date +%Y%m%d).sha256
# Compare baseline and restored manifests
diff <(sort /manifests/prod_baseline_20260319.sha256) \
<(sort /manifests/restored_20260319.sha256)
Step 4: Validate Data Completeness
# Count files in original vs restoredecho"Original: $(find /data/production -type f | wc -l) files"echo"Restored: $(find /restore-test -type f | wc -l) files"# Check total sizeecho"Original: $(du -sh /data/production | cut -f1)"echo"Restored: $(du -sh /restore-test | cut -f1)"# Database consistency check after restore
pg_restore --list backup.dump | wc -l # Count objects in dump
psql -c "SELECT schemaname, tablename FROM pg_tables WHERE schemaname='public';" restored_db
Step 5: Detect Ransomware Artifacts in Backups
Before trusting a backup for recovery, scan for ransomware indicators:
# Check for common ransomware file extensions
find /restore-test -type f \( \
-name "*.encrypted" -o -name "*.locked" -o -name "*.crypt" \
-o -name "*.ransom" -o -name "*.pay" -o -name "*.wncry" \
-o -name "*.cerber" -o -name "*.locky" -o -name "*.zepto" \
\) -print# Check for ransom notes
find /restore-test -type f \( \
-name "README_TO_DECRYPT*" -o -name "HOW_TO_RECOVER*" \
-o -name "DECRYPT_INSTRUCTIONS*" -o -name "HELP_DECRYPT*" \
\) -print# Check file entropy (high entropy = possible encryption)# Files with entropy > 7.9 out of 8.0 are likely encrypted
python agent.py --entropy-scan /restore-test
Step 6: Automate and Schedule Validation
# cron-based validation schedule# Run nightly after backup window04***/opt/backup-validator/agent.py--validate-latest--notify-on-failure# Weekly full restore test06**0/opt/backup-validator/agent.py--full-restore-test--config/etc/backup-validator/config.json
Key Concepts
Term
Definition
Hash Manifest
File containing cryptographic hashes (SHA-256) for every file in a dataset, used as integrity baseline
Bit Rot
Gradual data corruption on storage media that silently alters file contents
Immutable Backup
Backup that cannot be modified or deleted for a defined retention period
Restore Test
Process of recovering data from backup to an isolated environment to verify recoverability
File Entropy
Measure of randomness in file contents; encrypted files have entropy near 8.0 bits/byte
3-2-1 Rule
Keep 3 copies of data, on 2 different media types, with 1 offsite copy
Backup Chain
Sequence of full and incremental backups that must all be intact for recovery
Tools & Systems
Tool
Purpose
Restic
Encrypted, deduplicated backup with built-in integrity verification
BorgBackup
Deduplicating backup with archive verification
Rclone
Cloud storage sync with checksum verification
AWS S3 Object Lock
Immutable backup storage with WORM compliance
Azure Immutable Blob
Tamper-proof backup storage for compliance
sha256sum
Standard hash computation for file integrity
pg_restore
PostgreSQL backup validation and restore testing
Common Pitfalls
Never testing restores: The most common failure mode. Backups that are never restored are untested assumptions.
Checking only archive integrity, not data integrity: A valid tar.gz can contain corrupted file contents. Always hash individual files.
Trusting last backup without scanning for ransomware: Backups may contain encrypted files if the infection predates the backup.
Ignoring incremental chain integrity: A single corrupted incremental backup can break the entire restore chain.
No alerting on validation failures: Backup validation must be monitored with alerts, not just logged silently.
Using MD5 for integrity: MD5 is cryptographically broken. Use SHA-256 or SHA-3 for integrity verification.
References
NIST SP 800-184: Guide for Cybersecurity Event Recovery
