Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
.claude/skills/validating-backup-integrity-for-recovery/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-15 | ✗→✓ | ▲ Improved | — | — |
| case-03 | ✗→✓ | ▲ Improved | — | — |
| case-01 | ✗→✓ | ▲ Improved | — | — |
| case-14 | ✗→✗ | = Same ✗ | — | — |
| case-08 | ✗→✗ | = Same ✗ | — | — |
Use this skill when:
Do not use for initial backup configuration or scheduling. This skill focuses on post-backup validation.
hashlib (standard library)Create a cryptographic fingerprint of every file at backup time:
bash# Generate SHA-256 manifest for a directory find /data/production -type f -exec sha256sum {} \; > /manifests/prod_baseline_$(date +%Y%m%d).sha256 # Verify manifest format head -5 /manifests/prod_baseline_20260319.sha256 # e3b0c44298fc1c149afbf4c8996fb924... /data/production/config.yaml # a7ffc6f8bf1ed76651c14756a061d662... /data/production/database.sql
Check that the backup archive itself is not corrupted:
bash# Restic: verify backup repository integrity restic -r s3:s3.amazonaws.com/backup-bucket check --read-data # Borg: verify backup archive borg check --verify-data /backup/repo::archive-2026-03-19 # Tar with gzip: verify archive integrity gzip -t backup_20260319.tar.gz && echo "Archive OK" || echo "Archive CORRUPTED" # AWS S3: verify object checksums aws s3api head-object --bucket backup-bucket --key daily/2026-03-19.tar.gz \ --checksum-mode ENABLED
bash# 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 -exec sha256sum {} \; > /manifests/restored_$(date +%Y%m%d).sha256 # Compare baseline and restored manifests diff <(sort /manifests/prod_baseline_20260319.sha256) \ <(sort /manifests/restored_20260319.sha256)
bash# Count files in original vs restored echo "Original: $(find /data/production -type f | wc -l) files" echo "Restored: $(find /restore-test -type f | wc -l) files" # Check total size echo "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
Before trusting a backup for recovery, scan for ransomware indicators:
bash# 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
yaml# cron-based validation schedule # Run nightly after backup window 0 4 * * * /opt/backup-validator/agent.py --validate-latest --notify-on-failure # Weekly full restore test 0 6 * * 0 /opt/backup-validator/agent.py --full-restore-test --config /etc/backup-validator/config.json
| 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 |
| 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 |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-14 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-08 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-17 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-02 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-13 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-15 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-19 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-07 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-18 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-05 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-03 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-20 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-16 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-11 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-22 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-01 | fail→pass | — | — | — | — | — | — | — | — | — | — | — | — |
case-04 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-10 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-06 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-09 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-12 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
case-21 | fail→fail | — | — | — | — | — | — | — | — | — | — | — | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 21 counted toward the lift figure. The other 1 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +14 percentage points is the difference between those two pass rates over the 21 comparable cases.
The per-case answers from this run were removed by the retention sweep, so the case table below shows the verdicts without the text either arm produced. The counts above were recorded at the time and are unaffected. Answers are now kept for 180 days.
Other measured skills in the registry, with their headline benchmark lift.