Case study · Infrastructure / Security
Backup Modernization — legacy archives → content-addressed, encrypted, immutable
A sanitized engagement study of a backup estate moving from timestamped archives and mirror copies to a content-addressed Kopia repository, replicated across local, portable, cold and cloud tiers. Client-side encryption, weekly integrity checks, monthly restore tests and a 30-day immutable cloud data tier replaced an unverified recovery model.
- NIST CSF 2.0
- CIS Controls v8
- 3-2-1-1-0
Problem / Before
Opaque archives, repeated data
Timestamped compressed archives cannot deduplicate. The same unchanged data is stored repeatedly and then mirror-copied, so storage and transfer grow with time rather than change.
Untested recovery
No test restores were performed. Silent corruption could remain undiscovered until a disaster required recovery.
Unprotected offsite copies
Removable copies were plaintext and mutable. There was no client-side encryption or immutable tier to contain ransomware or deletion propagating through mirrors.
Method
Evaluate backup engines against 3-2-1-1-0, verification, encryption and scripting overhead. Kopia was selected for its deduplication, client-side encryption, policies and built-in verification. The storage decision supported encrypted offsite recovery, while an audit of sources and existing exclusion rules carried a trusted baseline into the new policies.
After / The architecture
One encrypted, deduplicated repository is replicated to portable, cold and cloud locations. Each unique chunk is stored once across snapshots.
The 3-2-1-1-0 mapping
- 3 / Copies
- Multiple copies across independent replica locations.
- 2 / Media
- Solid-state storage, disks and object storage.
- 1 / Offsite
- A cloud object-storage copy.
- 1 / Offline or immutable
- Disconnected drives and object-locked cloud data packs.
- 0 / Verified errors
- Weekly integrity verification and a monthly restore test form the verification layer.
Encryption before replication
Client-side AES-256-GCM keeps repository replicas encrypted; the repository password is required to read their contents.
Immutable data, writable metadata
A 30-day write-once-read-many lock protects immutable data-pack prefixes. Cloud replication is append-only; metadata remains writable so synchronization can complete. The storage token cannot remove the locks.
Automation with recovery checks
Three scripts handle daily snapshots and replication, weekly partial data verification and monthly restore tests. Sources are auto-enumerated so new projects are included without reconfiguration.
The lock covers data packs, not metadata. Restore tests demonstrate recoverability; a byte-for-byte comparison with source data remains a hardening step.
Before & after topology
Results
- Duplication eliminated at the data-model level: unchanged data is never re-stored.
- Config-folder capture reduced while preserving irreplaceable custom work.
- First tested recoverability: restores return files and are validated monthly.
- Encryption across replicas and an immutable cloud tier complete the 3-2-1-1-0 model.
- A dozen-plus scripts reduced to three, with new projects automatically included.
Lessons learned
Keep ignore rules at source roots
A child policy replaces rather than merges with its parent. Policy shadowing can silently change what is captured.
Lock data, not the whole bucket
The engine must rewrite metadata. Protect immutable data prefixes and replicate append-only.
Curate configuration explicitly
Use an allowlist, a size cap and an explicit credential/session deny-list; a blacklist alone is insufficient.
Plan restore material around encryption
Client-side encryption allows secrets needed for complete restores to travel inside the encrypted repository rather than a plaintext copy.
Break the recovery dependency loop
The password vault must reach a second device independently of the backup. A vault available only inside that backup cannot bootstrap recovery.
Review your backup architecture
Gaugon B2B contact · companies only.