Backup & Recovery Policy
BearCat treats recoverability as an operating requirement, not a marketing claim. The exact recovery method depends on what failed: site code/configuration, database records, uploaded files, DNS/domain settings, email, or a third-party integration.
1. Pre-launch restore point
Before a managed client site is approved for public launch, BearCat records a current recoverable code/configuration checkpoint or equivalent platform restore reference. Launch readiness remains blocked if the required restore point has not been recorded.
2. Material-change restore points
Before material BearCat-managed changes that could affect production operation, BearCat should create or identify an appropriate restore point where the hosting platform supports one. Small routine content edits may be grouped rather than creating a separate checkpoint for every text change.
3. Backup log
The BearCat Client Registry records the client, backup/checkpoint reference, date, notes, and whether a restore has been verified. The client portal surfaces the latest recorded backup date so “backup exists” is not merely assumed.
4. Health checks
BearCat records website-health checks in the client operations system. A health check may include site availability, HTTPS, important forms, critical links, and other client-specific functions. A recorded health check is a point-in-time observation and is not a guarantee of future uptime.
5. What a code/configuration checkpoint does not automatically cover
A site-code restore point may not restore database rows, email delivery history, analytics records, payment-processor data, externally hosted media, third-party booking data, domain-provider settings, or data stored by another service. Those systems have their own backup and retention capabilities.
6. Uploaded client assets
Customers should keep original copies of logos, photographs, video, music, documents, and other source assets they provide. BearCat-managed storage is not intended to be the Customer’s only archival copy of irreplaceable source material.
7. Recovery sequence
When a material production issue occurs, BearCat’s preferred sequence is: identify the failure → stop further harmful changes when practicable → preserve current evidence/logs → determine the affected system → restore or roll back from the most appropriate recoverable state → verify critical customer paths → document the recovery.
8. Restore verification
For launch-critical sites, BearCat can record whether a restore or rollback process has been tested. “Verified restore” means the relevant recovery workflow was actually exercised or otherwise verified; it does not mean every external dependency can be restored by BearCat.
9. Recovery limitations
No backup system eliminates all risk. Recovery can be affected by hosting-provider outages, corrupted source data, third-party retention limits, domain/DNS propagation, unavailable external APIs, account access, or events outside BearCat’s control. BearCat does not promise zero data loss or uninterrupted availability.
10. Customer responsibility
Customers should maintain access to their domain registrar and important third-party business accounts and should preserve original business assets. Customers should promptly tell BearCat about material changes to contact information, domain access, third-party tools, or staff authorized to control the site.
Policy version: September 29, 2026.