Most ransomware recovery failures don't happen because backups didn't exist; they happen because the attacker deleted or encrypted the backups too. Object Lock closes that gap by making objects immutable for a set period: nobody can overwrite or delete them before the retention period ends, not even an account administrator.
How it works
Object Lock uses a write-once-read-many (WORM) model. When you write an object to a locked bucket, it's given a retention date. Until that date passes, the object can be read and copied, but never modified or deleted; a request to delete it is simply rejected by the storage layer, regardless of who's asking.
Governance mode vs. compliance mode
| Mode | Can retention be shortened? | Best for |
|---|---|---|
| Governance | Yes, by an account holder with special permissions | Internal backup policies where an admin may occasionally need an override |
| Compliance | No, not by anyone, including Storivo | Regulatory retention requirements (finance, healthcare, legal) |
1. Enable Object Lock when you create the bucket
Object Lock has to be turned on at bucket creation; it can't be added to an existing bucket. If you're migrating from another provider, create your new Storivo bucket with Object Lock enabled before you copy data in. See the migration guide if that's you.
2. Set a default retention period
You can set a bucket-wide default (so every new object is locked automatically) or set retention per object at write time. A common starting point:
- 30 days: daily operational backups, where you mainly need protection against an active ransomware event being noticed within a month
- 90 days: standard business backups, giving enough buffer to detect a slow-moving compromise
- 1 year or more: compliance-driven retention (financial records, healthcare data, legal holds)
3. Use separate credentials for backup writes and administration
Object Lock only protects you if the credentials your backup software uses can't also disable the lock. Create a dedicated access key scoped to write objects into the locked bucket, and keep account-level administrative credentials separate, stored offline or with an admin who isn't part of the automated backup pipeline.
4. Point your backup software at the locked bucket
Any backup tool that writes over the S3 API, including WHM/cPanel and Plesk's built-in remote backup destinations, can write into an Object Lock-enabled bucket without special configuration. See the control panel integration guide for the specific setup steps.
5. Test a restore before you need one
The only way to know your locked backups will actually save you is to restore from one. Pick a recent backup, restore it into a scratch environment, and confirm the data is intact, on a schedule, not just once.
Want Object Lock on your plan?
It's included by default on SMB Business and Business Pro plans, and available as an add-on on hosting partner plans.
See plans & pricing