Multi-Cloud Mirroring: Why One Backup Isn't Enough
A single backup target (or a single cloud provider) creates predictable failure modes:
- Provider outage
- Account lockout / suspension
- Sync bugs and corruption
- Ransomware encrypting the sync root
- "Oops" deletion replicated everywhere
The fix is not "trust the provider more." The fix is redundancy + integrity + repair.
Mirroring ciphertext, not plaintext
Multi-cloud mirroring only makes sense if mirroring does not multiply exposure. The correct model is:
- Encrypt locally
- Mirror ciphertext blobs
- Keep keys off the providers
Necron's vault architecture is explicitly designed around "multiple synchronized storage locations," where each location holds encrypted vault data while the key material remains on the dongle.
What a mirrored vault actually is (implementation-level)
Stage 1 vault storage uses a per-vault root directory under each provider folder (sync root), with a split between:
- n/ (sealed node objects used to render the file tree)
- o/ (encrypted content objects)
- sys/ (vault system metadata)
This layout is intentionally non-revealing: storage providers see opaque IDs and encrypted objects, not human filenames.
Self-healing is an integrity feature, not a "sync trick"
Mirroring improves availability. Self-healing improves correctness.
Necron's architecture includes explicit "repair" behaviors across locations, including:
- A fast missing-object reconciliation pass (copy missing objects from a canonical good copy)
- A deeper integrity check + repair workflow that can classify copies as good/damaged/missing and repair accordingly
Those behaviors are described as part of the vault integrity strategy.
Why integrity repair matters
If a single provider silently corrupts data, a naive system happily syncs corruption everywhere. A robust mirrored system must:
- Verify integrity (AEAD tags / verification)
- Decide which copy is canonical
- Repair other mirrors from the canonical copy
Failure modes and how mirroring changes them
Provider outage
With N mirrors, "one provider down" becomes "degrade gracefully," not "data unavailable."
Account compromise
Attackers can delete mirrored ciphertext across providers if they compromise all accounts, but:
- Confidentiality remains intact if keys remain hardware-held
- Availability can still be protected via an offline mirror (e.g., external drive mirror) in addition to cloud mirrors
Sync conflicts and partial updates
A robust vault-on-sync-folders design must write safely:
- Temp-write + atomic rename
- "Write new object then update head pointer"
- Tolerate flaky mirrors (best-effort replication) while keeping the primary correct
These are explicit Stage 1 robustness rules: write blobs first, then update FileNode head, with best-effort replication and auto-heal on read when the primary is missing objects.
Choosing mirror targets: a pragmatic checklist
- At least one local mirror (fast recovery; control)
- At least one cloud mirror (offsite)
- Optional third mirror for resilience against provider lockout or regional outages
- Prefer heterogeneous failure domains (different providers, not just different folders)
FAQs
Does multi-cloud mirroring leak more data to providers?
Not if you mirror ciphertext only and keep keys off providers. Necron's vault model is designed around encrypted storage locations with dongle-held key material.
What if one mirror is corrupted?
Integrity verification should fail and the system should repair from another good copy. Necron's design includes missing-file reconcile and integrity repair strategies across locations.
Is mirroring the same as backup?
Mirroring is redundancy; backup is retention/history. Mirroring protects against outages and missing objects; versioned backups protect against deletion and "bad state replication."