Backups and restore

Overview

Backup and restore are part of administering any company in Ottili ONE. This article explains what is backed up, which backup types exist, how encryption at rest works, how you perform a restore, and which security and tenant rules apply. Everything on this page is derived from the Ottili ONE Backup Service and the Product Truth registries — it is rendered from a single canonical source and is not hardcoded or freely invented.

The overarching security architecture (tenant isolation, authentication, permissions, encryption, secrets management, audit) is described in [Security overview](/docs/security-overview). This article focuses on backups and restore.

Important status note:* On-demand backups and restore via the Backup Service are Live (v1)*. Scheduled/automated backups and point-in-time recovery (PITR) are In Development / qualified* — they are operational intent but not yet a verified, automatic guarantee. Encryption at rest is opt-in (qualified/Beta)*. What these terms mean is described in [Understand feature status labels](/docs/understand-feature-status-labels).

What is backed up (scope)

Ottili ONE backs up your company's platform-wide workspace data:

• PostgreSQL platform database (company-scoped):* customers, deals, quotes, orders, inventory, finance and audit events.
• Redis cache (optional):* an RDB snapshot of cache data when selected.
• File/object storage and configuration*, where applicable to your workspace.

All backups and restores are performed within your verified company context (company-scoped) and are permission-gated. Ottili ONE is tenant-scoped: a shared check rejects any request without or with an incorrect company context, and the database filters every platform row by the verified company_id. See [Tenant isolation](/docs/tenant-isolation).

Backup types

• On-demand backup (manual):* Create a backup from the *Backup & Restore* area in company administration or via the Backup Service. This is Live (v1)*.
• Scheduled/automated backups:* Status In Development / qualified*. The capability is operational intent, but we do not currently claim a verified, automatic point-in-time recovery, and we do not claim backups are "tested regularly". Plan your own restore drills (see below).
• Schema-specific backups:* Targeted backup of individual schemas (e.g. live, log, public) for focused restore.
• Backup rotation/retention:* Stale backups are rotated automatically according to a configurable retention policy.

Encryption at rest

Backups can be encrypted at rest with AES-256-GCM* when backup encryption is enabled and a passphrase is configured:

• Encryption is opt-in* and configuration-dependent (flag BACKUP_ENCRYPTION_ENABLED plus a configured passphrase).
• When encryption is not configured, backups are written unencrypted* — a deliberate, configuration-dependent behavior, not a universal guarantee.
• Encrypted backups carry the .enc marker; decryption on restore happens automatically when encryption is configured.

See [Privacy controls](/docs/privacy-controls) for the platform encryption details.

Restore

A restore is a write operation with wide impact, so it is guarded:

• Restore is performed from the *Backup & Restore* area and requires explicit confirmation* (confirm) plus a permission guard* (enabled by default).
• Encrypted backups* are detected by the .enc marker and decrypted automatically before restore when encryption is configured.
• Warning:* a restore overwrites existing data. For production, we recommend a dry run first, or restoring into a staging environment first.
• Restore drills* (targeted test restores) are a recommended best practice to demonstrate recoverability on a regular basis.

Verification & integrity

• Every backup gets a SHA256 checksum*; integrity can be validated (file present, decompressible, checksum matches).
• Backup rotation* deletes stale backups according to a retention policy (e.g. retention_days, max_count, minimum free space).
• Recommendation:* validate backups after creation and before a real restore rather than trusting the mere existence of a backup file.

Tenant isolation & security

• The Backup Service requires a verified company context (X-Company-ID); requests without context are rejected (HTTP 403).
• Restore is permission- and confirmation-gated; only authorized administrators can trigger it.
• Secrets are never backed up in plaintext.* Sensitive values are injected via environment variables and validated at startup; see [Privacy controls](/docs/privacy-controls) for secrets management.

Status / availability

Ottili ONE clearly distinguishes Live, Beta, Private Beta, In Development, Planned and Concept. What these terms mean is described in [Understand feature status labels](/docs/understand-feature-status-labels).

Related articles

• [Understand feature status labels](/docs/understand-feature-status-labels) — what the status terms mean.
• [Security overview](/docs/security-overview) — the whole security architecture at a glance.
• [Secrets management](/docs/secrets-management) — how configuration and integration secrets are protected.
• [Tenant isolation](/docs/tenant-isolation) — why your data stays isolated.
• [Manage your company](/docs/company-administration) — manage roles and access.
• [Data retention](/docs/data-retention) — storage, export, GDPR deletion.
• [Audit logs](/docs/audit-logs) — traceable, company-scoped logs.
• [Roles and permissions](/docs/roles-and-permissions) — who can do what.
• [Incident response](/docs/incident-response) — report vulnerabilities and handle incidents.
• [Vulnerability reporting](/docs/vulnerability-reporting) — disclosure channel and process.
• [Privacy controls](/docs/privacy-controls) — encryption, isolation, secrets, DPA.