BizBarrel Data Safety
User data is sacred. This page explains what protects your information during the Founding Member Alpha, and the Safety Launch Protocol we are building toward.
1. Core principle
No deployment, update, or maintenance action should proceed unless backup layers are healthy and recent. Production is a protected environment. The full protocol is documented for operators in Safety Launch Protocol.
2. What protects you today
- Account isolation — your trees, posts, and settings are tied to your signed-in account.
- Encrypted transit — TLS on live deployments where HTTPS is configured.
- Operator pre-flight backups — before schema migrations and album storage changes, operators back up the database and
uploads/(see ops runbook). - No secrets in the repo — live DB/mail config stays in
live/, not committed source. - Staging discipline (process) — changes are developed and checked before promotion; direct FTP surgery of production is prohibited by protocol.
Guest (trial) Cockpit data stays in the browser until you sign in. Guest Photo Album uploads are capped, not stored on the server, and cleared when the guest session ends.
3. Version history available now
Partial product versioning already exists; universal restore for every item type is still phased.
- Photo Album — photo versions (prior image states).
- Blog — post revisions for the blog owner.
- Stash Box — put away / restore owned tree nodes from Archive, Research, and Teams (Group).
4. Safety Launch Protocol (target)
- Daily full DB snapshots off-server, retained ~30 days; hourly incrementals ~48 hours.
- Triple-copy redundancy — production, mirrored read-only, cloud archive (S3/B2/Wasabi).
- User-level versioning — chains, notes, feeds, Organizer items with restore; admin global restore.
- Pre-launch backup lock — deploy blocked until fresh DB/file snapshots and mirrors sync.
- Staging-first — promote from staging after automated checks; production write lock (manual unlock, auto-revert ~30 minutes).
- Shadow copies & point-in-time recovery; Disaster Recovery Mode (read-only mirror) if production is unstable.
- Backup Health Dashboard — last backup, size, mirror sync, restore-test results, failure alerts.
- Weekly automated restore tests — spin up, restore, validate, destroy.
Full CPR text for operators and agents: docs/safety-launch-protocol.md.
5. Retention & recovery (honest)
Until scheduled off-server snapshots and restore drills are in production, recovery depends on operator-taken backups and host-level snapshots (if any). There is no published point-in-time guarantee for alpha.
When the target layers ship, this page will state concrete schedules and what users can expect to restore.
6. Your controls
- Export and full self-serve restore packs are phased — use version history / Stash where available, and keep personal backups during alpha.
- Account and preference data follow the same safety rules as content; see Privacy Policy for collection and use.
- Alpha expectations for testers: Alpha Tester Guide.
7. Privacy & related
Data Safety covers protection and recovery discipline. Privacy Policy covers what we collect and how we use it. Terms of Use and Accessibility cover use of the service and access.