Media archive with legal retention and cross-region recovery
MediaCo stores 480 TB of video masters and marketing clips in an Object Storage Standard bucket in us-ashburn-1. Versioning is enabled. A lifecycle rule deletes all objects 90 days after creation to control cost. Legal now requires 12 TB of contract masters to be retained for seven years, immutable even against tenancy administrators, and placed on legal hold when litigation is reasonably anticipated. Marketing needs 90-day hot access, then a year of occasional access; about 5% of assets are requested after 90 days and must be retrievable within 4 hours. Cross-region DR to us-phoenix-1 must meet RPO 15 minutes and RTO 2 hours. A recent 2 TB restore from Archive took 9 hours. The rendering team also mounts an OCI File Storage file system on 40 Linux nodes and reports NFS latency during frame writes.
1. Design the bucket, lifecycle, and retention model. How do you protect the 12 TB from deletion while still allowing the marketing lifecycle to delete other objects?
Read the worked answer
Separate the legal masters from the marketing library at the bucket boundary. A single bucket-level lifecycle rule that deletes everything after 90 days cannot coexist safely with a seven-year immutable retention requirement for a subset. Create a dedicated contract-masters bucket, enable versioning, and apply a locked retention rule with a retain-until date at least seven years out. If the region supports object-level legal holds, apply them to the litigation subset; otherwise use a separate litigation bucket with an indefinite retention rule so the hold is unambiguous. Do not attach a delete lifecycle rule to that bucket. Keep the marketing library in a different bucket with its own lifecycle: Standard for 90 days, transition to Infrequent Access for the next year, and only then archive objects that are not expected to be recalled. Retention rules are bucket-level controls, so bucket separation is the cleanest way to avoid accidentally protecting or deleting the wrong objects. Test by attempting to delete a protected object as an administrator; the request must fail and appear in Audit.
2. The 5% post-90-day retrievals must complete within 4 hours, but Archive restore took 9 hours for 2 TB. What tiering and restore strategy would you choose, and what limits would you communicate?
Read the worked answer
Do not use Archive for the 5% that must be available within four hours. Archive restore is asynchronous and is not designed for a four-hour retrieval SLA; a 9-hour restore for 2 TB is evidence of that. Keep the 90-day-to-one-year window in Infrequent Access, which provides immediate access at lower storage cost than Standard. Use Archive only for objects that are cold and have no four-hour requirement, and communicate that restore time is a job, not an API read. If a small set is unpredictably requested, consider keeping it in Standard or using an auto-tiering bucket that can move between Standard and Infrequent Access based on access patterns, but do not assume auto-tiering solves Archive recall. For large restores, initiate the restore job early, monitor it, and copy restored objects to a Standard bucket for the access window. The design should make the tier choice follow the retrieval SLA, not the other way around.
3. Design cross-region DR and address File Storage NFS latency. Include replication mechanics, failover, and performance checks.
Read the worked answer
For Object Storage, create a replication policy from the ashburn bucket to a destination bucket in phoenix. Replication is asynchronous; monitor replication metrics and test that the RPO 15 minutes is actually met rather than assumed. The destination is read-only while replication is active, so plan the failover runbook to stop or reverse replication before writes, update DNS or client configuration to the phoenix namespace and bucket, and verify object versions and retention metadata. RTO 2 hours also requires pre-provisioned compute, network, and load balancer capacity in phoenix. For File Storage, latency usually comes from placement or undersizing. Put the mount target in the same availability domain and private subnet as the rendering nodes, use NFSv3 over the private network, and verify that traffic is not hairpinning through NAT. Check file system and mount target throughput limits, export options, and client mount parameters. If frame writes are highly concurrent, use multiple file systems or local NVMe scratch for intermediate frames, and keep the shared file system for final assets. Measure with nfsstat, mount latency, and OCI metrics before and after changes.