https://linen.dev logo
Join Slack
Powered by
Hi, Does Permit, as a platform, provide any built-...
# permit-saas
m
Hi, Does Permit, as a platform, provide any built-in mechanisms for data backup and restoration? Specifically, does it support a defined Recovery Point Objective (for example, every 4 hours). Additionally, 1. Is there support for data restoration during accidental deletions? 2. For compliance reasons if we want to maintain a copy of the backup, is that currently supported through the platform?
a
Hi @Mihiru Kongahage, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
* Yes, Permit provides backup and versioning mechanisms: ​*Built-in Backup Capabilities:*​ • Git-backed policies for version control and policy auditing (1) • Backup & point-in-time restore to recover previous authorization states • Persisted PDP states to ensure fault-tolerant deployments ​*PDP Offline Mode & Backup:*​ The PDP can maintain local backup files for policy store state (both policy rules/code & data) . (2) • Policy store backup is done ​*periodically*​ (configurable via 
OPAL_STORE_BACKUP_INTERVAL
, default is 60 seconds) and also on graceful shutdown • You can customize the backup interval and file paths using these environment variables: • 
PDP_OFFLINE_MODE_BACKUP_DIR
(default 
/app/backup
) • 
PDP_OFFLINE_MODE_POLICY_BACKUP_FILENAME
(default 
policy_store_backup.json
) • 
OPAL_STORE_BACKUP_INTERVAL
(default 1 minute) ​*Regarding your specific questions:*​ 1. ​*Accidental deletions / restoration:*​ The documentation mentions "point-in-time restore to recover previous authorization states" and Git-backed policies for auditing. (1) However, specific details on restoring from accidental deletions aren't explicitly documented in the available sources. 2. ​*Maintaining your own backup copy for compliance:*​ The PDP configuration backup file is encrypted on disk using a key derived from your 
PDP_API_KEY
. Currently, OPAL's policy store backup file is ​*not encrypted*​, so you should secure the mounted host directory/volume where backup files are stored. (2) ​*What's not explicitly documented:*​ • A specific RPO guarantee (e.g., every 4 hours) from Permit's cloud side • A platform-level mechanism for exporting/maintaining compliance copies beyond the local PDP backups For more details on compliance-specific backup requirements or cloud-side RPO guarantees, I'd recommend reaching out via Email .
To learn more, see the sources I considered: [[1] Permit Strength Points](https://docs.permit.io/concepts/differentiator-checklist) [[2] Deploy Permit to Production](https://docs.permit.io/how-to/deploy/deploy-to-production)
a
Hey, I’m checking this with the team and will follow up shortly.
@Mihiru Kongahage We maintain internal backups as part of our disaster recovery processes (service-level recovery only, not customer restores). These backups aren’t customer-accessible, and we don’t offer a configurable RPO. We don’t support restore or rollback for accidental deletions. Deleted items can be re-created by re-sending them from your own systems via API/SDK. In most cases, the data you sync to Permit anyway comes from your systems (users, instances, etc.), so you can always resync what’s needed. For customers who need their own copies for compliance or audit purposes, we recommend exporting and backing up your Permit configuration & data on your side.
b
Hey thanks for the reply. Couple of follow-up questions 1. What's the default RPO on your end? 2. Docs mention about a PDP offline mode which uses a backup file in a mounted volume. Where can I get this backup? For some additional context, the reason for asking this question is, we're planning to use permit.io exclusively WITHOUT storing permission related relationship data (eg: role assignments) in our application database. Based on your response, it seems like you're advising against that. Could you please confirm? If we were to export the data that we have in our permit workspace, any suggestions for a good way to do it? (based on your experience maybe?)
o
Folks, the answer to these questions would highly depend on your relationship with Permit and what tier you’d be at. Assuming you intended to upgrade from the community tier these questions would be best directed to your customer success rep. then general support. I’d suggest you schedule a call via https://calendly.com/permitio/permit-enterprise , and fill out the associated questionnaire For Enterprise tier (and select PRO tier) customers we do provide data restore from backup.
What’s the default RPO on your end?
Our Soc2 enforced RPO is 24 hours
Docs mention about a PDP offline mode which uses a backup file in a mounted volume. Where can I get this backup?
That backup is stored locally on the volume the PDP is using per the configuration See 
PDP_OFFLINE_MODE_BACKUP_DIR
. It is literally included in this thread.
For some additional context, the reason for asking this question is, we’re planning to use permit.io exclusively WITHOUT storing permission related relationship data (eg: role assignments) in our application database. Based on your response, it seems like you’re advising against that. Could you please confirm?
That is very common usage pattern, and we encourage it - Permit can be your single source of truth for anything for permissions. Note: this isn’t the same as storing all the data you want to have permissions for in Permit.
If we were to export the data that we have in our permit workspace, any suggestions for a good way to do it? (based on your experience maybe?)
Per environment in your workspace you have 3 options (ordered by recommendation): 1. Via the PDP offline mode as described above 2. Via exposing OPA directly in the PDP and using its data API 3. Via the PDP API 4. Via the Permit control plane API
b
Thanks for the explanation Or, appreciate it! We're integrating permit to a product on behalf of a customer and they're already in Pro tier. I would not rather share additional details beyond that since this channel is public. We'll reach out through a direct channel if required.
@Ask Inkeep can you answer the following? 1. Is it possible to restore a permit.io environment to a previous state using a PDP offline backup? If yes, what things are restored? 2. Is it possible to restore to a new environment using a PDP offline backup of a different environment? 3. Why type of a synchronization is available between the permit.io cloud and the PDP? One way or two way? If there were to be conflicts, what's the reconciliation strategy? 4. What happens when a PDP is brought back online from the offline mode? Is locally cached data synced back up the permit.io cloud?
a
Thanks for tagging me @Bashwara Undupitiya. I'll look through relevant sources and get back to you shortly.
Based on the available documentation, here's what I can confirm: ​*1. Restoring a Permit.io environment using PDP offline backup:*​ The PDP offline mode backup is designed for ​*resilience/fault-tolerance*​ of the PDP itself, not for restoring the Permit.io cloud environment. (1) When offline mode is enabled, the PDP stores a local backup of configuration, data, and policies so it can continue operating if it loses connection to Permit's cloud. The documentation doesn't describe a mechanism to push this backup back to restore the cloud environment state. ​*2. Restoring to a new environment using another environment's backup:*​ This is not documented as a supported use case. The backup files are tied to the specific PDP instance and environment configuration. ​*3. Synchronization type between Permit.io cloud and PDP:*​ The synchronization is ​*one-way: from Permit.io cloud → PDP*​. (2) (3) The control plane (Permit.io cloud) manages policy and relationship metadata, while the data plane (PDP) receives and enforces it locally. OPAL streams policy and data updates from the cloud to PDPs. (3) The PDP fetches configuration from the control plane and receives real-time updates via WebSocket connections. (1) There's no documented mechanism for the PDP to push local changes back to the cloud—changes to users, roles, and policies are made via the Permit API/SDK, which updates the cloud, and those changes then propagate down to PDPs. ​*4. What happens when PDP comes back online from offline mode:*​ Based on the documentation, when the PDP reconnects, it will ​*sync from the cloud*​ (pull the latest policies and data) . There is no documented sync-back of locally cached data to the cloud. The PDP is a consumer of policy/data, not a source of truth. * ​*Summary:*​ The architecture is designed with the Permit.io cloud as the authoritative source. PDPs are read-only consumers that cache locally for resilience. For restoring environment state, you'd need to use the Permit API to re-sync data from your systems or use cloud-side backups (available for Enterprise/select Pro tiers as Or mentioned) . For specifics on your Pro tier entitlements regarding cloud-side restores, I'd recommend reaching out through your direct support cha
To learn more, see the sources I considered: [[1] Deploy Permit to Production](https://docs.permit.io/how-to/deploy/deploy-to-production) [[2] Control plane / Data plane](https://docs.permit.io/concepts/control-plane-and-data-plane) [[3] Permit's PDP (Policy Decision Point)](https://docs.permit.io/concepts/pdp/overview)
a
Hey Bash, does the AI's answer make sense or do you have any additional questions?
b
Hi Alon, I think I got most of my doubts cleared out. From the AI explanations it seems like a PDP offline backup cannot be used to restore a permit environment to a previous state (and that's by design since that's not it's intended purpose) -- correct? Regarding my requirement of restoring the state of a permit environment (similar to a point-in-time restore), My understanding is that I'll have to rely on the permit cloud APIs (like the bulk operation APIs) and build my own backup & restore solution around that which backs up the permit environment state (policies and data) periodically, could you please confirm? Just curious, has any of your existing customers requested this kind of a feature and what was your recommendation regarding that? Additionally, is there a way to add delete locks to permit projects or environments? I have not seen anything related to that in the UI, I suppose it's not a feature yet? Thanks in advance!
o
From the AI explanations it seems like a PDP offline backup cannot be used to restore an permit environment to a previous state (and that’s by design since that’s not it’s intended purpose) -- correct?
There’s no automatic way to do it ; but you can use the exported data through the API to recreate the stored state.
Regarding my requirement of restoring the state of a permit environment (similar to a point-in-time restore), My understanding is that I’ll have to rely on the permit cloud APIs (like the bulk operation APIs) and build my own backup & restore solution on top of it which backs up the permit environment state (policies and data) periodically, could you please confirm?
That’s essentially correct. But a more important question, is why would you need to backup and restore Permit environments?
has any of your existing customers requested this kind of a feature and what was your recommendation regarding that?
While requested from time to time (for different reasons), this is not a highly requested feature. Recommendations are as you received here.
is there a way to add delete locks to permit projects or environments?
• There’s the policy guard feature (currently API only) - https://docs.permit.io/how-to/policy-guard/policy_guard ◦ it allows you to lock policy objects from being changed • You can limit Editor (which includes delete) access to a project / environment only to a specific user or API-key
b
But a more important question, is why would you need to backup and restore Permit environments?
It's for insurance during a DR, breach or a mishap scenario. To make sure that we can revert back to a desired state. Additionally, it's also required to satisfy some compliance requirements. Thanks for the explanations Or. We'll try out some of these recommended approaches and reach out if we have any further questions.
😇 1
5 Views
Open in Slack
PreviousNext
Powered by