WORM compliance with custom OCI Database backups

When you move your databases to cloud, many times the (current) standard backup configuration what Oracle offers is not enough. That’s when you configure OCI Cloud Database backup module which allows more flexibility with your RMAN configuration and also allows to write backups to custom Object Storage bucket.

Question came up regarding this, can we achieve WORM compliance for database backups? In short, WORM is Write Once, Read Many. So we want to write our backups but also want to make sure we can’t modify or delete the files after they’ve been uploaded to Object Storage.

Object Storage Bucket Retention rules

When I started to look on this, I thought we can easily use Object Storage retention rules which allows to lock the bucket down. Once file is written, you can make it so that nobody can update/delete the file after it’s uploaded.

I configured backup module and set backups to go into my bucket named WORM. I set retention rule on for the bucket as seen below.

When running simple RMAN restore to bucket, I ran into an error.

Investigating the log file showed that the metadata.xml files which are created in the bucket are written first and then updated in another session. Setting retention rule basically prevents updating these files and stops backup module to work properly.

What about IAM policies?

So what about other options via IAM policies? I was thinking if we can write an IAM policy which identifies all *.xml files and allows modification / delete for these files but would not allow same for any other files. We can write IAM policy for attribute target.bucket.name, but NOT target.object.name, so this is not possible either.

Other option was to emit object events when new files are created and run OCI function, if file would match anything else apart from *.xml, add tag to object and write a policy restricting delete to non-tagged objects only. But we can’t tag objects so this wouldn’t work either.

Example basic IAM policy which only allows users to create objects in bucket.

Allow group ObjectWriters to read buckets in compartment ABC

Allow group ObjectWriters to manage objects in compartment ABC where any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'}

Next best option

Since achieving true WORM-compliance does not seem to be possible, there are few alternative ways to add additional layers of security.

• Limit bucket access to Database Cloud Backup user only (obvious)
• Enable object replication cross-region
• Enable object versioning

You would want to restrict bucket access as much as possible, while you can limit it to only one user, you still would have that user account which can delete and modify the files in the bucket.

Other option would be to enable object replication to another bucket and lock that bucket, but this would mean duplicating your storage footprint for backups which could bring additional costs. What stops you modifying the objects in source bucket and getting them replicated to destination though? I would also look then on lifecycle policies to bring down costs.

Object versioning, while this doesn’t lock anything down, it gives us way to see which files have been modified. This also showed that the *.xml files are being modified during backup. As you can see from below screenshot, xml file has two versions with two seconds apart.

If only the xml files are modified, this would be storage efficient way to see which files are modified.

Summary

While there doesn’t seem to be a way to achieve true WORM-compliance with custom OCI database backups, there are ways to restrict and limit access further due additional measures. If you have some other option which could work better, let me know!