A backup that can be deleted by a compromised administrator is not a backup—it’s a liability. In the OCI ecosystem, achieving true resilience requires moving beyond simple connectivity and into the world of Zero-Trust architecture.
To build a “Ransomware-Proof Vault” for your OCI workloads, we must follow the 3-2-1-1-0 Golden Rule. Here is how to architect it.
- 3 Copies of data.
- 2 Different media (Block vs. Object).
- 1 Offsite copy (OCI Cloud).
- 1 Immutable or Air-gapped copy.
- 0 Errors (Verified with SureBackup).
The goal of this architecture is to ensure that even a total compromise of your production environment doesn’t lead to data loss. We do this by separating the Storage, the Geography, and the Administrative Access.
The “Vault” Compartment: Logical Air-Gapping – Creating Data Resilient copy
The first step in a cyber-resilient strategy is Administrative Distance.
Do not store your backups in the same compartment as your production VMs. Instead, create a dedicated “Backup” Compartment
Instead of keeping your backups in the Prod_Compartment, you should create a dedicated Backup_Compartment, and Backup_Vault_Compartment.
- The Logic: You apply a strict IAM Policy that denies almost everyone except the Veeam Service Account from even seeing this compartment.
- Security Zone: Associate this compartment with an OCI Security Zone. This prevents anyone (even an admin) from accidentally making a bucket public or disabling encryption.
- Administrative Separation: Use different OCI user groups for “Production Admins” and “Backup Admins.”
- The Twist: Apply a Deny-All IAM policy for your primary Cloud Admin group on this compartment. Only a specific “Security-Officer” account should have the keys to modify these resources. This prevents a compromised admin from wiping both production and backups.
The Strategy: SOBR with MultiRegion
To manage this rule without breaking the budget, we use a Scale-Out Backup Repository (SOBR). This allows us to tier data between fast local recovery and long-term cloud residency.
1. Performance Tier (Short-Term & Immutable)
- Where: OCI Block Storage (Balanced/Higher Performance).
- Why: This is your “Immediate Recovery” zone. If ransomware hits, you use Instant VM Recovery to boot directly from this tier.
- Nugget: Use the Elastic Performance slider to keep IOPS costs low outside backup windows.
2. Capacity Tier (Offsite & Long-Term)
- Where: OCI Object Storage (Standard Tier) for example in the Riyadh Region. for Performance in Jeddah.
- Why Riyadh? For workloads that resides in Jeddah region, using the local Riyadh region minimizes latency for backup copies and ensures data residency compliance. for an Offsite copy. Ideally at a different compartment.
- Logic: Use SOBR Copy Mode to sync data immediately for that “Offsite” requirement.
Copy vs. Move: When to use what?
In your SOBR settings, you’ll see two checkboxes that define your “1” (Offsite) and your retention costs:
- Copy Policy (The “Safety First” choice): Copies backups to OCI Riyadh as soon as they are created. This satisfies the 3-2-1 rule within minutes of your job finishing.
- Move Policy (The “Cost Saver” choice): Moves backups to Object Storage only after they age out (e.g., after 14 days). This is your Long-Term Retention (LTR) engine, keeping your expensive block storage clean.
Pro Tip: For maximum protection, enable BOTH. Copy immediately for offsite safety, and move older data to keep your data resilient yet cost optimized.
Managing the Lifecycle: SOBR Copy vs. Move
A resilient strategy balances Recovery Time (RTO) with Storage Cost. We use the Veeam Scale-Out Backup Repository (SOBR) to achieve the right balance.
| Retention Type | Location | Storage Tier | Tier | Resilience Feature |
|---|---|---|---|---|
| Short-Term (14 Days) | Local (e.g. Jeddah) | OCI Block (HLR) | Performance | XFS Immutability + Fast Restore |
| Long-Term (Monthly Yearly) [GFS] | Regional (e.g. Riyadh) | OCI Object (S3) | Capacity | Logical Isolation + Cost Savings |
Wrapping Up the OCI Series
This architecture completes the journey we started in our previous posts. By combining our OCI Native VM recovery workarounds with a 3-2-1-1-0 SOBR design, you aren’t just backing up—you are building a fortress.
For a deeper dive into the theory behind this shift, I highly recommend watching this breakdown of the 3-2-1-1-0 rule. It explains why the “1” (Immutability) and the “0” (Verified recovery) are the only things standing between you and a total data loss.
This video is essential because it details the evolution of backup best practices into the 3-2-1-1-0 standard, providing the industry context needed to justify the architectural choices we’ve made in OCI.
Review other posts:
- Start with the OCI S3 Setup Guide to get connected.
- Use the Hardened Linux Repo Workaround to solve the immutability gap.
- Deploy the Full Machine Recovery methods when you need to boot that data back into production.
Leave a Reply