mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-21 08:36:33 +03:00
Magnus HedemarkGitHubusername <username>factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>Add the resilience-and-recovery skill for designing, exercising, and evidencing graceful degradation, disaster recovery, and restoration behavior across systems and dependencies. - SKILL.md with both resilience patterns (graceful degradation and restore-based recovery), exercise-evidence requirement, HA vs recoverability distinction, context-dependent RTO/RPO, and structured plan-template fields - README.md with all five required human-facing sections - 7 reference files covering failure modes, recovery plan template, exercise design, RTO/RPO decision record, data integrity verification, recovery communication, and follow-up work ledger - 1 bounded discovery brief surveying SRE, platform, data, security, release, and incident-learning - 5 output-quality eval cases covering dependency outage, restore test, regional failure, degraded-but-available path, and recovery exercise with unowned gap escalation - Routing to site-reliability-engineering, platform-engineering, data-engineering, secure-software-engineering, release-engineering, and incident-learning; feeds production-excellence bundle - Root README catalog entry, skill-triggers index, and regenerated marketplace/Codex/llms.txt catalogs Co-authored-by: username <username> Co-authored-by: factory-droid[bot] <138933559+factory-droid[bot]@users.noreply.github.com>
3.1 KiB
3.1 KiB
Data Integrity Verification
Purpose
Verify that data is correct and consistent after a restore, failover, or recovery event. A successful restore that produces corrupted or inconsistent data is a failed recovery. Data integrity verification is a required step in every restore-based recovery exercise.
Verification levels
| Level | What it checks | When to use |
|---|---|---|
| Structural | Files exist, schemas match, row counts are expected | Every restore — fast, automated, catches gross failures |
| Checksum | Cryptographic hash of data blocks or files matches pre-backup hash | Every restore for systems where data corruption is a risk |
| Application-level | Business rules hold — foreign keys resolve, aggregates compute, workflows execute | Restores of critical systems; DR failovers |
| Reconciliation | Restored data matches an independent source of truth (e.g., event log replay, replica comparison) | High-assurance restores; financial/healthcare data |
Post-restore validation procedure
1. Pre-restore baseline
- Record expected row counts per table or collection.
- Record expected checksums for critical data sets.
- Record schema version and migration state.
2. Structural validation
- Restored files or database exist and are accessible.
- Schema version matches expected version.
- Row counts match expected counts within tolerance.
- Indexes are present and valid.
3. Checksum validation
- Compute checksums on restored data blocks.
- Compare against pre-backup checksums.
- Flag any mismatch for investigation.
4. Application-level validation
- Run application-level consistency queries: foreign keys resolve, no orphaned records.
- Compute key aggregates and compare against pre-restore baseline.
- Execute critical business workflows in a test context against restored data.
- Verify that application can connect to and query the restored data store.
5. Reconciliation (high-assurance systems)
- Replay event log against restored state and compare.
- Compare restored data against an independent replica or audit log.
- Verify that all committed transactions are present and no uncommitted transactions appear.
6. Sign-off
- Validation owner reviews all results.
- Any discrepancy is recorded in the follow-up work ledger.
- Validation owner signs off or escalates.
Common failure modes
| Failure mode | Detection | Mitigation |
|---|---|---|
| Backup is corrupted | Checksum mismatch | Multiple backup copies; periodic restore testing |
| Backup is incomplete (missing recent data) | Row count below expected; reconciliation gap | Verify backup completeness at time of creation |
| Restore process introduces corruption | Post-restore checksum mismatch | Use verified restore tooling; test restore procedure regularly |
| Schema migration mismatch | Application errors on connect; foreign key failures | Record schema version at backup time; validate compatibility |
| Replica lag captured in backup | Data inconsistency between related tables | Use consistent snapshot or transactionally-consistent backup |