1. Business impact
| Function | Impact if unavailable | Priority |
|---|---|---|
| Decision API used by customers' AI agents | Agents with SDK calls cannot get decisions; the SDK fails closed (blocks), except low-impact actions the customer explicitly allowed during an outage | 1 |
| Approvals and panel | Customers cannot approve actions or change policies | 1 |
| Audit log | Loss would remove customers' evidence | 1 (integrity) |
| Public vendor lookup and marketing site | Lost leads and lookups; no customer data at risk | 2 |
The main threats considered: loss of the VPS or its disk, accidental or malicious deletion of data, compromise of the server, prolonged outage at the hosting provider, and the Founder being unavailable.
2. Recovery targets (honest)
| Scenario | RPO (data loss) | RTO (time to restore) |
|---|---|---|
| Application failure, bad deploy | None | 1 hour (rollback, policy 03) |
| Database corruption or deletion, server intact | Up to 24 hours (last daily dump) | 4 hours |
| Loss of the VPS or its disk | Today: not recoverable - backups are on the same disk | Target after off-site backup: RPO 24 hours, RTO 24 hours |
These targets will be tightened once off-site backups and a restore drill exist.
3. Backups as they exist today (in place)
- A daily PostgreSQL backup runs at 00:15 (Brasília time) with
pg_dumpin custom format. - 14 daily copies are kept, on the same disk as the database.
- The backup was checked once by listing the dump's contents; a full restore drill has not been done yet.
- Whether Hostinger VPS snapshots are enabled for this server is not confirmed.
- Not covered by the backup today: files uploaded by vendors as evidence (stored on the server's local disk), the server
.envand keys, and Caddy configuration. The code is safe in the private GitHub repository.
4. Commitments (owner: Founder)
- Off-site, encrypted backup - copy each daily dump, the vendor evidence files, the audit-chain anchors and an encrypted copy of
.envto storage outside Hostinger, encrypted before upload, with checksums and at least 30 days of versions (target 2026-10-31). - Full restore drill - restore the latest dump to a separate database, run the audit-chain verification on it, check row counts against production, and record the time taken (first drill target 2026-10-31; then every quarter).
- Confirm Hostinger snapshots and, if available, enable weekly snapshots as an extra layer (target 2026-10-15).
- Written rebuild runbook for a new VPS from scratch, using
deploy/setup-server.shanddeploy/first-deploy.sh(target 2026-11-30). - Uptime monitoring and alerts (policy 04, target 2026-10-31).
5. Disaster recovery steps
- Declare an incident (policy 05) and set severity.
- Decide: restore in place (server intact) or rebuild (server lost or compromised). A compromised server is always rebuilt, never cleaned.
- Rebuild: create a new Ubuntu 24.04 VPS; apply the server baseline (policy 03); run the setup and first-deploy scripts from the repository; create a new deploy key; restore
.envfrom the encrypted copy and rotate every secret that was on the old server (policy 02). - Restore data:
pg_restorethe most recent good dump; restore vendor evidence files; run migrations; run the audit-chain verification against the latest anchors kept off the server (once in place). - Point DNS to the new server; Caddy obtains certificates automatically.
- Check login, MFA, API decisions and approvals; then tell customers the service is back and what, if anything, was lost.
- Post-incident review (policy 05).
6. Communication during a disruption
- Customers are informed by e-mail to each organization owner, sent through the transactional e-mail provider or, if that is down, from contato@semantiqwall.com.
- Commitment: a public status page (owner: Founder, target 2027-03-31).
7. Resilience limits we disclose
- A single VPS in a single datacenter; no standby server and no geographic redundancy. The datacenter location is to be confirmed with Hostinger.
- A single person operates the service. If the Founder is unavailable, no one else can restore it. Commitment: a sealed emergency-access procedure (where the credentials are kept and who may use them) with a trusted person, and a second operator at the first technical hire (target 2027-03-31).
- Physical and environmental controls of the datacenter (power, cooling, fire, access) are Hostinger's responsibility; we have not yet obtained its attestation (policy 09).
8. Testing and review
The plan is exercised at least once a year (a full rebuild drill on a scratch VPS) and after any significant infrastructure change. Results and fixes go in the security register.