2.4 Object Storage Replication, Versioning & Retention Rules (WORM)

Object Storage Architecture and Durability Principles

OCI Object Storage is an internet-scale, highly durable cloud storage platform designed for unstructured data, big data analytics repositories, document archives, and backup targets. Object Storage operates at the regional level, meaning it is inherently decoupled from specific Availability Domains or Fault Domains. Oracle stores redundant copies of each object across distributed storage locations in the region and automatically recovers from disk failures. Oracle states that Object Storage exceeds 99.999999999% (11 nines) durability. Durability protects against hardware loss; it does not protect against a regional outage, accidental deletion, or ransomware, which is why the features below matter.

To meet regulatory compliance mandates, safeguard against ransomware, and satisfy multi-region disaster recovery objectives, architects must leverage four core governance and resilience features: Bucket Replication, Object Versioning, Lifecycle Management, and Retention Rules (WORM).

---

Cross-Region Asynchronous Bucket Replication

For disaster recovery and geographic data proximity, OCI provides automated Cross-Region Bucket Replication:

• Replication Mechanics: You create a replication policy on the source bucket that names an existing destination bucket in another region. A source bucket can have only one replication policy and one destination, and a destination cannot itself be a replication source (no chaining). Objects uploaded after the policy is created are copied asynchronously, and objects deleted from the source after that point are deleted from the destination. Objects that existed before the policy are not replicated. Because Object Storage is regional, you must also authorize the Object Storage service in each region involved, for example Allow service objectstorage-us-phoenix-1 to manage object-family in compartment ObjectStore.
• Read-Only Destination: While replication is active, the destination bucket is read-only and is updated only by replication. A lifecycle policy that tries to delete objects in the destination does not work, although a destination lifecycle rule can archive objects.
• Stopping Replication for Failover: You can stop replication from either side. From the source, you delete the replication policy. From the destination, which is what you use when the source region is unavailable, you make the destination bucket writable. The destination then stops accepting replication and applications in the recovery region can write to it. To replicate to it again later, delete the old policy on the source and create a new one.

---

Object Versioning and Ransomware Mitigation

Accidental administrative deletion and malicious ransomware encryption present severe operational risks. Enabling Object Versioning on a bucket creates a historical ledger of every object change:

• Upload / Overwrite Behavior: When an object with an existing name is uploaded, OCI does not overwrite the data. Instead, it assigns a unique, immutable version ID to the new object (making it the latest version) while retaining all prior iterations with their original version IDs.
• Delete Behavior: When an object is deleted in a version-enabled bucket, OCI does not destroy data blocks. Instead, it places a Delete Marker over the object. Applications listing objects without version parameters will see the object as deleted; however, administrators can restore the object instantly by deleting the delete marker.
• Permanent Deletion: To permanently expunge an object, an administrator or lifecycle policy must explicitly specify the exact version ID during the delete operation.

---

Storage Tiers and Lifecycle Management Policies

Managing long-term storage costs requires automated tiering based on data access patterns. OCI Object Storage provides three primary tiers:

1. Standard Tier: High-throughput, immediate, low-latency access for hot data and active workloads.
2. Infrequent Access Tier: Optimized for cooler data accessed less than once a month. Storage costs are substantially lower than Standard tier, with identical low-latency retrieval, subject to a minimum retention period of 31 days and a per-GB retrieval fee. Auto-Tiering can move objects between Standard and Infrequent Access automatically based on access patterns.
3. Archive Tier: Cold storage designed for long-term compliance records, database dumps, and historical archives. Storage costs are up to 90% lower than Standard tier. Objects are not immediately readable; accessing an archived object requires a Restore operation first. Oracle states that restoration takes at most one hour from the restore request to the first byte. Archive objects have a 90-day minimum retention period.

Automated Lifecycle Rules

Architects define Lifecycle Management Policies containing rules that evaluate object age (days since creation) or object name prefixes. A typical lifecycle rule automatically transitions objects from Standard to Infrequent Access after 30 days, moves them to Archive after 90 days, and permanently deletes them after 365 days. Lifecycle policies can also be targeted specifically at non-current (historical) object versions to reclaim capacity while keeping active versions in the Standard tier.

---

Retention Rules (WORM Compliance) and Rule Locking

Financial institutions, healthcare providers, and legal entities face stringent data preservation regulations, such as SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC 1.31. These regulations mandate that electronic records must be preserved in a Write Once, Read Many (WORM) format where data cannot be overwritten, modified, or erased during a mandatory retention period.

OCI Object Storage satisfies these mandates via Retention Rules:

• Time-Bound Rules: Specifies a retention duration (for example, 7 years). The duration applies to each object individually, counted from the object's Last Modified timestamp.
• Indefinite Retention Rules (Legal Holds): Locks all objects in the bucket indefinitely until the rule is explicitly removed by an authorized compliance officer.
• Rule Locking: A rule is active as soon as it is created; the lock only controls whether the rule itself can change. Locking is irreversible, and Oracle enforces a mandatory 14-day delay before the lock takes effect so you can test, change, or delete the rule. After the lock takes effect, not even a tenancy administrator or Oracle Support can delete the rule, the duration can only be increased, and the rule can only be removed by deleting the (empty) bucket. Indefinite rules cannot be locked because they have no duration.

Oracle commissioned an independent Cohasset Associates assessment of retention rules against SEC 17a-4(f), FINRA 4511(c), CFTC 1.31(c)-(d), and MiFID II record-keeping requirements.

---

Secure Access: Pre-Authenticated Requests and Private Endpoints

Enterprise architectures must securely expose and ingest object data without compromising security postures:

• Pre-Authenticated Requests (PARs): A PAR generates a unique, cryptographically signed URL allowing external clients or partners to read from or write to a bucket or specific object without possessing an OCI IAM account or API signing key. Architects can restrict PARs by HTTP method (Read, Write, or ReadWrite) and must configure a mandatory expiration timestamp.
• Object Storage Private Endpoints: While Object Storage is a public regional service, enterprise security policies often prohibit compute instances from traversing public internet gateways or NAT gateways to access bucket data. A Private Endpoint provisions a private IP address within a customer's VCN subnet. All object API calls route privately across internal VCN subnets, allowing administrators to enforce Network Security Groups (NSGs) and strict firewall egress inspection.