Recovering when something goes badly wrong
Backups only matter if a restore works. This page describes our backup strategy at a high level, how we think about recovery, and what our continuity planning covers today.
Backup strategy
This page is maintained by RapidRoot to answer common security and privacy questions about our platform. It describes practices that are in place today and clearly labels anything that is planned. It is not a certification, an audit result, or independent verification.
- Customer data is held in managed database services with automated backups and point-in-time recovery capability provided by the platform.
- Configuration is defined as code so environments can be rebuilt rather than reconstructed from memory.
- Backups inherit the storage-layer encryption and access controls of the managed provider.
- We do not publish backup schedules, storage locations or retention counts, because those are operationally sensitive.
Recovery philosophy
Restore over repair
For data-layer failures, restoring from a known-good state is preferred to improvising a fix on live data.
Rebuild over patch
Because environments are configuration-defined, a compromised or broken environment can be rebuilt clean.
Communicate early
Customers hear from us while we are still working, not only once everything is resolved.
Continuity goals
Provider-level automated backups
In place todayManaged database backups with point-in-time recovery capability.
Documented recovery runbooks
In progressWritten, repeatable recovery procedures are being formalised.
Scheduled restore testing
PlannedRegular restore drills with recorded outcomes are planned; we do not claim them today.
Formal RTO and RPO targets
PlannedWe will publish recovery objectives once we can measure and stand behind them.