Perryscope.ai
PlatformDocsRoadmapCompare
Request demo
Perryscope.ai

Self-hosted sensitive-data security for the AI era.

ProductsSecret SecurityPrivacy SecurityAI Guardienne
PlatformArchitectureSecurity modelGovernance syncObservability
DevelopersDocumentationAPI referenceCLIWebSocket eventsGet started
CompanyRoadmapCompareFAQSupportContactPrivacy policyTerms
© 2026 Perryscope. Flexible enterprise licensing.100% self-hosted · zero third-party calls
Documentation
StartGetting startedConfigurationDeployment
ScanningScanning modesFindings & workflowValidationPrivacy scanningAI Guardienne
IntegrateCLIAPI referenceWebSocket eventsGovernance sync
ReferenceSecurity modelDNS change runbookTransactional email deliveryMonitoring & alertingDisaster recovery & failoverSite recovery & backupsSecrets: leak prevention & rotationDependency & patch automation

Disaster recovery & failover

This page defines how quickly perryscope.ai can be restored if the primary hosting environment fails, and the procedure used to do it. It extends the site recovery & backups runbook, which covers rebuilding the site from source and backups; this page covers doing that quickly and in a controlled way.

Recovery targets

RTO
4 hours
Max acceptable downtime before service is restored.
RPO
Last commit
Site content, assets, and infrastructure configuration are version-controlled, so recovery restores to the most recent commit. Work not yet committed sits outside the recovery boundary.

Failover approach

Failover redeploys the mirrored repository to a fresh project on the same hosting provider, then repoints DNS — rather than maintaining an always-on standby host on a second provider. This is sufficient for the 4-hour RTO on a static site and avoids the cost of standing secondary infrastructure.

DNS cutover procedure

  1. Confirm the redeployed target is live and serving correct content at its provider-assigned URL.
  2. Update the A/CNAME records in Cloudflare DNS to point to the new target.
  3. Allow for propagation per the current record TTL.
  4. Verify: site loads over HTTPS, robots.txt/sitemap.xml resolve, spot-check a docs page.
  5. Update the DNS record snapshot to reflect the new state once stable.

Credentials used during recovery

DNS and hosting changes during a recovery event use the same access path as routine administration. Use is expected to be logged and MFA-protected.

Recovery exercises

Recovery exercises are scheduled quarterly, and after any change to the hosting or DNS architecture. Each exercise simulates the primary as unavailable and times a full recovery against the 4-hour RTO using only the documented steps above — no undocumented knowledge. Any step that requires information not on this page is recorded as a gap, fixed, and re-tested at the next cycle. Exercise records are retained internally.

Control:Required to keep restoration time and data loss within agreed limits if the primary hosting environment fails.

← Monitoring & alertingSite recovery & backups →