Validating Backup Integrity For RecoverySAFE

817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains ·

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: validating-backup-integrity-for-recovery
description: Validates backup integrity through cryptographic hash verification,
  automated restore testing, corruption detection, and recoverability checks to
  confirm backups are reliable for disaster recovery and ransomware response. Use
  before relying on backups for recovery, when building post-backup validation
  pipelines, auditing backup infrastructure for compliance, or checking immutable/air-gapped
  backups for silent corruption or tampering.
domain: cybersecurity
subdomain: incident-response
tags:
- incident-response
- backup
- integrity
- hash-verification
- restore-testing
- disaster-recovery
version: '1.0'
author: mahipal
license: Apache-2.0
nist_csf:
- RS.MA-01
- RS.MA-02
- RS.AN-03
- RC.RP-01
mitre_attack:
- T1486
- T1490
- T1070
- T1078
- T1489
mitre_f3:
  version: '1.1'
  tactics:
  - positioning
  - monetization
  techniques:
  - id: T1531
    name: Account Access Removal
    tactic: positioning
    source: attack
  - id: F1018
    name: Convert to Cryptocurrency
    tactic: monetization
    source: f3
  - id: F1047
    name: Transfer of funds
    tactic: monetization
    source: f3
  - id: F1017.001
    name: 'Conversion to Physical Monetary Instruments: Cash'
    tactic: monetization
    source: f3
---
# Validating Backup Integrity for Recovery

## When to Use

Use this skill when:
- 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.

## Prerequisites

- Access to backup storage (local, NAS, S3, Azure Blob, GCS)
- Python 3.9+ with `hashlib` (standard library)
- 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:

```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
```

### Step 2: Verify Backup Archive Integrity

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
```

### Step 3: Perform Restore Test to Isolated Environment

```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)
```

### Step 4: Validate Data Completeness

```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
```

### Step 5: Detect Ransomware Artifacts in Backups

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
```

### Step 6: Automate and Schedule Validation

```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
```

## 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 entrop

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

declared (1 observation(s))

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.