What Data for This Category Looks Like
This category’s data originates from backup systems, database logs, object storage, and disaster recovery platforms. Daily operation and maintenance documents include backup policies, recovery drill reports, disaster recovery switchover plans, and data verification records. Data update frequencies fall into three categories: daily (such as real-time backup logs, daily data verification records), monthly (such as one-off recovery drill reports), and quarterly (such as revised versions of disaster recovery switchover plans). Document fields include backup window, recovery point objective, drill execution time, data consistency verification results, and other standard fields used in operation and maintenance scenarios, with no custom units added.
Constraints Imposed on Permission and Data Isolation by These Characteristics
The data characteristics of this category create multiple constraints for permission and data isolation. Cross-system data sources require permissions to cover multiple nodes including backup systems, databases, and object storage. This prevents full-link disaster recovery data risks from single-node permission leaks. Documents with different update frequencies need to match corresponding permission timelines: daily backup logs require real-time access permission verification, while quarterly disaster recovery switchover plans must be fixedly bound to the permissions of a dedicated responsible person. Data consistency verification results directly relate to business continuity. Only authorized operation and maintenance duty personnel can modify verification records, to prevent misoperations from disrupting recovery processes. When an internal ticket covers a recovery application, the system must verify whether the applicant holds backup and recovery operation permissions for the corresponding business system.
Configuration Settings
The following configurations are based on FastGPT v4.17.0:
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
teamId | Configure by business system grouping, each group corresponds to a dedicated team | Matches the team attribution isolation requirement for cross-system backup and disaster recovery data in this category |
tmbId | Assign by disaster recovery drill execution group, no more than 5 people per group | Limits the participation scope of drill operations, prevents unauthorized personnel from executing recovery scripts |
| Team member knowledge base access permissions | Only allow access to backup policies and drill reports of the corresponding business system | Meets department isolation requirements for daily documents, prevents cross-department tampering of core disaster recovery data |
| Internal ticket approval permissions | Bind to the operation and maintenance duty responsible account | Ensures recovery applications require review by authorized personnel, avoids recovery timeout risks caused by misoperations |
| Data export permissions | Only granted to business continuity responsible persons | Prevents sensitive disaster recovery data leaks, complies with data security requirements in operation and maintenance scenarios |
| API call permissions | Only generate keys for applications under specified teamId | Restricts unauthorized subjects from calling disaster recovery-related APIs, prevents illegal recovery operations |
Three Common Misconfiguration Issues
- Symptom: Calls to disaster recovery-related APIs return a "no permission" status code. Cause: The corresponding
teamIdis not bound to the application, so the system cannot verify the calling subject's team attribution permission. - Symptom: Unauthorized members can view backup policy documents of other business systems. Cause:
teamIdis not configured by business system grouping, resulting in ineffective permission scope isolation. - Symptom: Deleted team members can still access disaster recovery data from their old team. Cause: The permission binding relationship for the corresponding
teamIdwas not updated synchronously, and leftover access tokens were not invalidated in a timely manner.
How to Confirm the Configuration Is Correct
- An account from an unauthorized team is used to log into the system. Access to backup policy documents of the corresponding business system is verified to be blocked, confirming that permission isolation is effective.
- A request is sent to disaster recovery-related APIs using a key not bound to a
teamId. A no permission prompt is verified to be returned. - An internal recovery ticket is submitted using an account that is not the duty responsible person. The approval process is verified to not be completable.
- The team member list is viewed, confirming that the accounts of deleted members have been removed from the corresponding
teamIdpermission group.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.