MCTS: Designing Storage Sovereignty for the Cloud

**Series: Multi-Cloud Tiered Storage (MCTS)** 1. Part 1: The NAS That Wasn't 2. Part 2: MCTS Architecture *(Current)* 3. Part 3: The Great Deduplication 4. Epilogue: The 400 GB Shortcut That Ran for Zero Seconds

Following the decision to retire my ten-year-old home server (documented in Part 1: The NAS That Wasn't), we needed to design its replacement.

The goal wasn't just to rent someone else's server in the cloud. It was to build a system that offered true data sovereignty without chaining a nomad to physical hardware.

We named this blueprint **Multi-Cloud Tiered Storage (MCTS)**.

---

The Three Sovereign Realms

Most home NAS setups degrade into landfills because they lack structural boundaries. When folders are shared casually across personal projects, studio assets, and collaborative files, duplication is inevitable.

In MCTS, we created three strictly isolated top-level realms:

1. **Studio Realm**: Shared commercial assets, release archives, media kits, and brand assets.
2. **Partner Realm**: Creative partner's dedicated workspace, raw assets, and project files.
3. **Personal Realm**: Private individual archives, personal documents, and historical records.

By enforcing isolation at the top level, cross-realm collisions are impossible. Each realm maintains its own taxonomy and permissions, preventing one user's reorganization from breaking another's workflow.

---

The Tiered Topology

Rather than relying on RAID arrays—which protect against disk failure but do nothing against silent corruption, accidental deletion, or physical disaster—MCTS decouples storage into three functional tiers:

[ Tier 1: Local Cache ]     MacBook SSD (Working files, zero latency)
       ↕ (Idempotent Sync)
[ Tier 2: Hot Master ]      Cloud Drive (5 TB centralized canonical hub)
       ↕ (Automated Sync)
[ Tier 3: Cold Archive ]    Cloud Storage Bucket (Archive class, disaster insurance)

• **Hot Master (Tier 2)** acts as the single source of truth (SSOT). All devices synchronize against this central hub.
• **Cold Archive (Tier 3)** serves as a immutable, geographic backup. It stores everything in an ultra-low-cost archival tier, protected from accidental overwrites.
• **Local Cache (Tier 1)** is strictly ephemeral. A laptop only keeps what it actively needs, freeing a nomad from carrying multiple external hard drives.

---

Why Vendor Sync Clients Fail

Traditional cloud sync clients (Dropbox, Google Drive Desktop, OneDrive) are built for general consumers. They hide sync state behind opaque status icons, choke on hundreds of thousands of files, and often create duplicate `(1)` conflict files rather than providing deterministic resolution.

For MCTS, we standardized on **`rclone`** as the universal engine:

• **Idempotence by Design**: Transfers are governed by explicit manifests (`--files-from`) and MD5 hash verification.
• **Server-Side Reparenting**: Reorganizing thousands of folders inside the cloud happens in seconds via server-side API calls, without downloading a single byte to the local machine.
• **Auditable State**: Every transfer produces structured logs, progress metrics, and deterministic exit states.

---

Next Step: The Great Deduplication

With the three realms defined and the topology established, we faced the next challenge: bringing 400,000 legacy files from the old server into this clean structure without carrying over ten years of duplicates.

*In Part 3: Deduplicating 400,000 Files Without Deleting One, I explain how we used hash-based quarantine scoring to safely reclaim hundreds of gigabytes.*