Know What the Backup Does Not Cover
Cloud Restore recovers SafeSquid policy state tied to the activation key. It does not rebuild the host, restore networking, or recover third-party integration secrets — and a DR plan that assumes otherwise discovers the gap during the rebuild, with the outage clock running. Plan the backup around what it actually covers, and cover the rest separately.Understand the backup scope
Included in cloud backup- All policy configuration (
config.xml). - SSL root certificate and private key.
- User groups, identity rules, access policies.
- Extended policies such as DLP and anti-virus.
- System logs.
- Network interface settings, including IP and hostname.
- Operating system configuration.
- Third-party integration secrets, such as LDAP credentials and external database connections.
Match the scenario to the recovery
Set the backup cadence
- Automatic backup — triggered when you select Restart SafeSquid after making configuration changes.
- Manual backup — Support → Restart SafeSquid, selecting Yes for cloud backup.
- Retention — the latest backup overwrites the previous one. A single version is stored per activation key.
Disaster recovery checks
Disaster recovery checks
Before declaring production readiness, confirm:
- Activation key storage is recoverable without exposing the key contents.
- Configuration backup and restore are tested.
- Root CA material, if used, is backed up according to certificate-handling policy.
- Rebuild steps exist for appliance, cloud, or Linux deployment.
- DNS, PAC, GPO, MDM, firewall, and route rollback owners are named.
- A second node or restore target can use the same activation context when cluster or DR behavior requires it.
Disaster recovery site design
Disaster recovery site design
A DR stack keeps web security enforced during a regional outage. Without one, a site failure removes the control rather than degrading it, and users either lose internet access or get it unfiltered.Site requirements
- Geography — a different city, data centre, and power grid than primary. Co-locating the DR stack with production negates continuity.
- Capacity — mirror production sizing across CPU, RAM, NICs, and disk. The DR site carries full load during failover, not a fraction of it.
- Configuration — replicate policy through Configuration Sync or a documented manual procedure.
- RTO (Recovery Time Objective) — how long it may take to redirect traffic to the DR site.
- RPO (Recovery Point Objective) — how much policy and configuration lag is acceptable. Real-time sync approaches zero; manual replication does not.
Set the RTO and RPO targets with the business, then test failover on a schedule and keep the result as audit evidence. Quarterly is a common cadence.Missing: recovery-time figures per failover method are not stated here — the legacy source gives numbers, but they are undated and unverified. Escalate to the CTO for SLA-style claims.
Validate DR readiness
Validate on a non-production restore target, not on the production appliance:- The same activation key finds the expected backup.
- Policy state matches the intended version.
- SSL material restores correctly.
- Host-specific settings are re-applied where needed.
- Client traffic passes through the rebuilt system.
Capture backup evidence
Store these artifacts with the deployment record:- The date of the last tested restore, and the named owner of the next test.
- The activation key storage location and its access control.
- The list of items covered separately because the cloud backup excludes them.
- The agreed RTO and RPO, and who set them with the business.
Troubleshoot backup gaps
Next steps
- Configure Cloud Restore - set up the backup this page plans around.
- Configuration Sync - keep DR-site policy aligned with production.
- Proxy Clustering - add failover before relying on restore alone.