You can restore Zscaler configuration data to recover from deletion, corruption, or misconfiguration. You can restore content to the same Zscaler tenant (in place) or to a different Zscaler tenant (out of place).
Restore destinations
| Destination | When to use |
|---|---|
| In place | Recovering from accidental deletion, corruption, or ransomware on the original Zscaler tenant |
| Out of place | Migration, disaster recovery to a new tenant, or restoring to a test or sandbox tenant |
Permissions and prerequisites
Restoring Zscaler data requires:
-
A completed backup containing the ZIA or ZPA categories you want to restore.
-
For in-place restore, the original Zscaler instance with valid OneAPI credentials.
-
For out-of-place restore, a separately configured destination Zscaler instance with valid OneAPI credentials and, for ZPA, the destination tenant's customer ID.
-
API roles with create and update permissions for all selected categories.
-
For ZIA restores, API role permission to activate pending configuration changes.
You can restore Zscaler configuration to the original tenant.
-
From the Command Center navigation pane, go to Protect > SaaS Apps.
-
Click the Zscaler configuration.
-
On the Backup History tab, select the recovery point that contains the configuration you want to restore.
-
Click Restore.
-
In the Select content section, choose the ZIA or ZPA categories to restore:
-
Browse the tenant tree and select specific categories.
-
Select the entire tenant to restore all supported categories from the recovery point.
-
-
In the Restore Destination section, select the original Zscaler instance.
-
Review the restore settings, and then click Restore.
Restore proceeds in parent-first order:
-
Categories are ordered to satisfy dependencies. ZIA labels, dictionaries, and engines precede policy rules; ZPA connector groups, trusted networks, and segment groups precede application segments and policies.
-
Each configuration object is matched by name in the target tenant. Existing objects are updated; missing objects are created when the target API supports creation.
-
For ZIA restores, Commvault automatically invokes ZIA activation after successful ZIA writes. Activation failure fails the restore job because changes would otherwise remain pending.
-
Authentication Settings is tenant-wide and update-only. Review the source configuration before restoring it because it can alter the destination tenant's authentication behavior.
You can restore Zscaler configuration to a different tenant.
-
From the Command Center navigation pane, go to Protect > SaaS Apps.
-
Click the Zscaler configuration.
-
On the Backup History tab, select the recovery point that contains the configuration you want to restore.
-
Click Restore.
-
In the Select content section, choose the ZIA or ZPA categories to restore:
-
Browse the tenant tree and select specific categories.
-
Select the entire tenant to restore all supported categories from the recovery point.
-
-
In the Restore Destination section, select the separately configured destination Zscaler instance.
-
Review the restore settings, and then click Restore.
Restore proceeds in parent-first order:
-
Categories are ordered to satisfy dependencies, same as for in-place restore.
-
The workload uses destination API lookups and remaps supported referenced objects by name, including relevant ZPA topology and policy references.
-
Object IDs are tenant-specific and not reusable across different Zscaler tenants. Restore uses name-based matching and remapping rather than ID-based matching.
-
Categories excluded from the supported hierarchy are skipped; do not use an out-of-place restore to migrate those unsupported configuration types.
Restore is not a delete or synchronization operation. Objects absent from a backup are not removed from the destination tenant.