Guest Post: Barry Gordon, Head Coach & Founder at Identity Coach
Best Backup Practices for Okta
As with many things, there is no singular method for backing up data for Disaster Recovery.
There are different approaches for different scenarios.
Okta, as a provider, will make sure the system is available. However, you are responsible for your data. This begs the question: How should my data in Okta be backed up?
Often, one of two common approaches comes to mind:
Snapshots and Continuous Backup.
Each of these approaches has its own set of benefits and challenges. However, only one is appropriate for your Okta data backup.
Let’s explore each of these.
As implied by the name, a snapshot is a complete “picture” of the entire state of a system at a specific point in time. This allows recovery to a known good state. Snapshots are particularly useful when restoring a system as the whole state is more beneficial than restoring individual components or when troubleshooting a corrupt state would be impractical or take longer than recovery.
A common use case for snapshots would be the backup of entire physical and virtual servers.
Multiple snapshot creation and management methods exist, each with pros and cons.
The challenge with snapshots for Okta recovery is that you don’t have access to the underlying data directly. It is possible to make pseudo-snapshots by regularly dumping object data via the API and using that data to rebuild the state. However, it will never be a true replica of the original state. The process of importing may change identifiers, timestamps, and other relevant attributes.
Recovery from a snapshot will require reconciliation to address broken object relationships and references to return to a functional state.
Continuous backup, also known as real-time backup or incremental backup, involves the continuous and automatic copying of data from a source to a backup location. This backup system constantly monitors changes in the source data and transfers only the modified or new portions to the backup destination.
This minimizes the amount of data transferred and reduces the backup time compared to full backups.
Regarding Okta, continuous backup usually involves monitoring the system log for object changes. When an object changes, the Okta APIs can be used to capture the updated state of the object.
This approach offers some advantages over snapshots for Okta backup.
Recovery points become much more numerous and precise. Individual items can be restored to a specific point in time without changing other objects in the tenant. Alternatively, the entire state of the tenant can be reconstructed from any point in the backup history.
Continuous Backup offers greater flexibility to Okta backups than snapshots.
Given the advantages, continuous backup will be the most effective approach to backup Okta in most circumstances. Snapshots are not inherently a poor approach but are better suited for situations where direct data or bare metal are accessible. In cases where continuous backup is impractical due to a lack of resources, snapshots may be a practical alternative, albeit with some tradeoffs.
However, for most organizations, continuous backup will be the most effective way to backup and recover Okta.
Building a continuous backup system from the ground up can be costly and complex.
The labyrinth of object relationships and order of operations can make the task more taxing than simply copying data. Before going down the path of building your own, consider commercial Okta backup products such as acsense.
This will provide the benefits of continuous backup at a fraction of the cost of building it yourself.
You may also find these resources insightful: