Backups & Restore

Studio and Edge databases produce separate logical SQL artifacts. Media R2 objects and Worker configuration need separate preservation. These resources do not form one atomic site backup.

What a Backup Contains

Resource	Included in a Studio SQL backup?
Studio content, accounts, settings, and Media metadata	Yes
Password hashes, encrypted MFA/service credentials, and sessions	Yes
Audit records	Yes, subject to the data present at export time
FTS declarations and canonical searchable content	Yes; derived search rows are rebuilt after restore
Edge database rows	No; export Edge separately
R2 file bytes	No
Worker Secrets and deployment configuration	No

Keep the STUDIO_AUTH_SECRET that belongs to the database. Restoring encrypted rows without it does not restore usable TOTP or service credentials. Preserve Secrets securely and separately from the SQL artifact.

Availability

All workflows require Operations access. The dashboard checks each target’s actual state.

Studio mode	Export	Restore
operational	Readable Edge DB with ready Studio DB and administrator re-verification	Unavailable
maintenance	Available targets with administrator re-verification	Available targets with administrator re-verification
recovery	Available targets with Operations IP and token	Available targets with Operations IP and token

A readable Studio DB can be exported while its schema needs an upgrade. A new maintenance-mode Studio restore requires a current ready schema. Use recovery mode for an uninstalled Studio database or unavailable administrator credentials.

Pause other writers before export. For Edge, set the public Worker’s EDGE_MAINTENANCE_MODE=true; changing Studio’s mode does not pause that Worker. The exporter checks schema and row counts but does not hold a single snapshot across all reads.

Export Formats

Format	Intended use
Structure and data	Schema and rows for a portable restore
Structure only	Schema inspection; Studio does not restore this format
Data only	Restore into a target with the same schema fingerprint

Artifacts include a manifest, schema fingerprint, and integrity checksum. The checksum detects changes; it does not encrypt private account, credential, email, IP, or session data in the file.

Use Studio’s logical export for Studio D1. Cloudflare’s native D1 export does not support databases containing virtual tables, including Studio’s FTS5 indexes. The logical exporter accounts for those tables without requiring manual schema changes.

Restore

1. Select the generated artifact and review its target, format, and contents.
2. Keep the required site mode and Operations credentials available.
3. Confirm RESTORE DATABASE to replace the selected target’s data.
4. Wait for final schema, row-count, and foreign-key verification.
5. Rebuild Studio content search when requested, then return to operational mode.

Studio validates the artifact before execution. Current format-v2 and supported format-v1 artifacts can be restored; arbitrary or modified SQL is not accepted by this workflow.

Rows are restored in bounded requests. A failed request rolls back that request, not previously completed requests. If interrupted, keep the database out of normal service and restart from the same reviewed artifact using the reported operation state. A maintenance restore already in progress can use its operation record and token/IP boundary when account rows are incomplete.

State After Restoration

• Search rows are derived data. Rebuild the content index after restoring canonical content.
• Audit history returns to the backup’s point in time. Studio pauses new audit writes during restore and records completion after verification.
• An old Cloudflare Access requirement may still be bound to its original hostname. Use Access recovery before enabling it for a different origin.
• R2 objects, Worker Secrets, site mode, and the separate database are not restored by the selected SQL operation.

For code/schema mismatches and forward upgrades, see Maintenance & Recovery.