1. Purpose and scope
Backups support recovery from infrastructure failure, corruption, accidental operational change and security incidents. The available FormEsque operator procedure is designed to capture application database records and objects held in FormEsque-managed Supabase Storage; each successful run records the exact database capture method and limitations in its backup manifest.
FormEsque does not currently rely on managed provider backups or point-in-time recovery as its primary backup method. Those capabilities apply only when they are enabled and verified on the active provider plan.
2. Creation, encryption and verification
When direct database credentials are available, an authorized operator creates a PostgreSQL custom-format dump. Otherwise, the current fallback exports REST-visible public application tables through a service credential. That fallback is not a transactionally consistent point-in-time database snapshot and does not capture provider-managed authentication or internal schemas. Storage objects are archived separately.
When the procedure runs successfully, backup artifacts are encrypted with AES-256-CBC using PBKDF2 key derivation. The passphrase must be stored separately from the artifacts and limited to authorized operators. A backup is not considered usable merely because a command completed; its manifest, checksums, decryption and expected database and Storage contents must pass the independent verification procedure.
3. Frequency and retention
Backups are operator initiated and must be completed and verified before material production schema changes and according to the operating schedule. The operating target is to retain at least seven daily, four weekly and twelve monthly encrypted backup sets, including an encrypted copy stored separately from the primary operator machine.
A stated schedule is an operational requirement, not a guarantee that a particular recovery point exists. Recovery depends on the most recent backup that completed verification and remains accessible with its separate decryption material.
4. Recovery validation
Recovery procedures use an isolated, non-production Supabase project. Operators inspect the database archive before restoration, restore Storage objects only to the isolated target, reconcile migration history and run tenant-isolation plus proposal, signing and invoice checks before declaring a backup usable.
A restore exercise should be completed at least quarterly and after a material change to the backup format or recovery process. Production is never overwritten as an initial restore step.
5. Retention, deletion and provider capabilities
Encrypted backup sets are removed when their approved retention period ends unless a legal hold, investigation or incident requires longer preservation. Data deleted from active systems can remain in an encrypted backup until that backup set expires; backups are not restored for ordinary customer access to an individual deleted record.
If managed provider backups or point-in-time recovery are added later, their actual retention window and successful configuration must be verified before FormEsque relies on or represents those capabilities.
6. Customer responsibilities
Backups are not a substitute for customer recordkeeping or exports. Customers should retain independent copies of records required for legal, tax, warranty or business-continuity purposes and should not rely on FormEsque to restore an individual record deleted through an authorized action.
7. Limitations and incidents
No backup design can guarantee zero data loss or immediate recovery. Restoration priority depends on incident severity, integrity checks, provider availability and security review. Material recovery events are handled under the Incident Response Policy and communicated as required by law or contract.
