Sep 15, 2026 · Andrius
DRIUS never writes to Okta without showing you first
Every Okta admin I've talked to asks some version of the same question about restore tools: "What is this actually going to do to my production org?"
It's a fair question. A restore is a write. If the tool gets it wrong, you've turned one problem into two. So we built restore in DRIUS around one rule: nothing gets written to Okta until you've seen exactly what will change and approved it.
What you see before a restore
When you pick something to restore, a group, a policy, a network zone, DRIUS builds a plan first. For every field that would change, you see three things side by side: the field, what's in Okta right now, and what's in the backup.
The plan also calls out the changes that deserve a second look, like a rule that denies access, a network zone change, a new object being created, or members being removed from a group. Those don't get buried in a long list.
If nothing would change, the plan tells you that too, and there's nothing to approve.
Okta gets checked three times
Okta doesn't stand still while you're reading a plan. Someone else on your team might be making changes at the same moment. So DRIUS reads your live Okta three times during one restore:
- When the plan opens, so you see the current state.
- When you click Queue restore, to make sure nothing changed while you were reviewing.
- Right before the write, as a last check.
If Okta changed at any point, DRIUS stops and shows you a fresh plan. It won't apply a plan you approved against an Okta that no longer looks like that.
All three checks are reads. We have a test that runs every kind of restore plan and confirms that every request DRIUS sends to Okta during the preview is a read. If someone ever accidentally added a write to the preview code, that test fails.
Big restores get split, not half-done
Okta's rate limits are real, especially on smaller orgs. If a plan would take too long to build or too many API calls, DRIUS doesn't push through and leave you with a partial picture. It tells you the restore is too large to review at once and asks you to split it into smaller pieces.
Removing group members is opt-in
By default, restoring a group adds back the members who were in the backup. It doesn't remove anyone who's been added since. Removing people from groups can lock them out of apps, so that's not something a tool should do quietly.
If you do want the group to match the backup exactly, you can tick "also remove members not in the backup." Before anything happens, you see the names of the people who would be removed. It's off by default, only owners and admins can use it, and every removal is recorded in the audit log.
Why this matters
A backup is only as good as your confidence in restoring from it. If you're nervous about what restore will do, you'll put it off until things are already bad. The goal is that clicking restore in DRIUS feels boring: you see the plan, it matches what you expected, you approve it.
If you run Okta and want to try it on your sandbox org, request early access at drius.io.