validating-backup-integrity-for-recovery

验证备份完整性以用于恢复

何时使用

在以下情况下使用此技能：

• 在依赖备份进行勒索软件恢复之前，验证备份完整性
• 构建在每次备份作业后运行的自动化备份验证流水线
• 审计备份基础设施，以确认符合合规要求（SOC 2、ISO 27001、NIST CSF RC.RP-03）的可恢复性
• 在灾难发生前检测备份存储中的静默数据损坏（位腐）
• 验证不可变或气隙备份未被篡改

请勿使用于初始备份配置或调度。此技能侧重于备份后验证。

前置条件

• 可访问备份存储（本地、NAS、S3、Azure Blob、GCS）
• Python 3.9+ 及 hashlib（标准库）
• 用于比较的备份清单或基线哈希文件
• 用于恢复测试的隔离恢复环境
• 备份工具命令行访问权限（restic、borgbackup、rclone 或厂商专用工具）

工作流

步骤 1：生成基线哈希清单

在备份时为每个文件创建加密指纹：

# 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

步骤 2：验证备份归档完整性

检查备份归档本身是否损坏：

# 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

步骤 3：执行恢复到隔离环境的测试

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

步骤 4：验证数据完整性

# 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

步骤 5：检测备份中的勒索软件痕迹

在信任备份用于恢复之前，扫描勒索软件指标：

# 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

步骤 6：自动化并调度验证

# 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

关键概念

术语	定义
哈希清单	包含数据集中每个文件加密哈希（SHA-256）的文件，用作完整性基线
位腐	存储介质上逐渐发生的数据损坏，会静默改变文件内容
不可变备份	在定义的保留期内无法修改或删除的备份
恢复测试	将数据从备份恢复到隔离环境以验证可恢复性的过程
文件熵	文件内容随机性的度量；加密文件的熵接近 8.0 bits/byte
3-2-1 规则	保留 3 份数据副本，存储在 2 种不同介质类型上，其中 1 份为异地副本
备份链	完整备份和增量备份的序列，必须全部完好才能恢复

工具与系统

工具	用途
Restic	加密、去重的备份，内置完整性验证
BorgBackup	带归档验证的去重备份
Rclone	带校验和验证的云存储同步
AWS S3 Object Lock	符合 WORM 合规要求的不可变备份存储
Azure Immutable Blob	用于合规的防篡改备份存储
sha256sum	用于文件完整性的标准哈希计算
pg_restore	PostgreSQL 备份验证和恢复测试

常见陷阱

• 从不测试恢复：最常见的故障模式。从未恢复过的备份只是未经检验的假设。
• 只检查归档完整性，不检查数据完整性：有效的 tar.gz 可能包含损坏的文件内容。始终对单个文件进行哈希。
• 信任最后一次备份而不扫描勒索软件：如果感染早于备份，备份可能包含加密文件。
• 忽略增量链完整性：一个损坏的增量备份就可能破坏整个恢复链。
• 验证失败时没有告警：备份验证必须通过告警进行监控，而不能只是静默记录日志。
• 使用 MD5 进行完整性验证：MD5 在密码学上已被攻破。使用 SHA-256 或 SHA-3 进行完整性验证。

参考资料

• NIST SP 800-184：网络安全事件恢复指南
• NIST CSF 2.0 RC.RP-03：备份完整性验证
• CIS Controls v8：控制项 11 - 数据恢复
• CISA 勒索软件指南：https://www.cisa.gov/stopransomware