Maintenance Freeze, Backup, and Cleanup

Maintenance freeze supports operations that need writes paused, such as configuration restoration, preventing business configuration and control from changing during restoration.

Maintenance freeze

States follow OFF → ENTERING → ACTIVE → EXITING → OFF. Entry and exit may take time; rely on state-query results.

During freeze, protected configuration and control writes are rejected with business code 200162. Use the current entry and exit APIs, not removed Capability or staged-exit APIs.

Operation	API
Query state	GET /maintenance/state
Enter freeze	POST /maintenance/enter
Exit freeze	POST /maintenance/exit

Backup and restore

1. Save current settings with a configuration backup.
2. Enter maintenance freeze and upload a version-compatible backup file.
3. Check restoration results and cache rebuilding, then exit freeze after confirmation.
4. If templates need synchronization, reconcile the designated UDE types or instances afterward.

POST /ems-data/backup downloads a configuration backup. POST /ems-data/restore uploads it through the multipart file field. Configuration backups follow a backup manifest and are not full-device images. Check whether archive plans, runtime metadata, and other required items are included in your backup scope.

Cleanup by category

Batch cleanup handles data and configuration by category and rebuilds related caches. Cleaning raw or shared data may also affect configuration and group mappings. UDE cleanup includes rules and generated-object manifests.

Confirm selected categories and references before calling POST /ems-data/batch/clear. Categories execute separately; successful categories are not rolled back because another fails. Inspect each result individually.

Use Historical export for temporary data extraction and Periodic archiving for long-term retention. See Runtime configuration for how runtime parameters take effect.