Backup and restore

Full backups are installation-wide disaster-recovery archives. Website-scoped comment, review, and structured-content transfers belong under Import / Export and are not substitutes for a full backup.

BK2 archive contract

DynoStatic creates password-encrypted BK2 archives. A backup stored beneath the document root uses the protected .dynostatic-backup.php extension; a backup stored outside it may use .dynostatic-backup. The archive records the exact product lineage, migration head, canonical schema fingerprint, ordered table catalog, per-table restore policy, row counts, referenced-file manifest, and SHA-256 values.

The table catalog is complete, but security and transient tables have a clear policy and contribute no archived rows. Those tables include sessions, one-use/recovery tokens, rate-limit state, transient jobs and deliveries, backup records, and CMS API tokens. Durable content is restored. Database fields encrypted by the source installation are decrypted in memory and re-encrypted with the destination installation's existing application key.

Only database-referenced protected uploads are transported: every verified DynoStatic-held original in current or historical immutable media revisions, legacy CMS media not yet represented canonically, and attachments referenced by decryptable form submissions. A locator reused by metadata-only media revisions is included once; conflicting metadata or hashes fail closed. Remote WordPress, Drupal, and Joomla sources and local-workspace-only copies are recorded in database state but their bytes are not falsely included as server-held files. Cache, logs, backup files, runtime configuration, application-key files, temporary exports/imports, avatar cache, and unreferenced uploads are excluded. A missing, changed, unguarded, linked, duplicated, case-colliding, oversized, hash-mismatched, or unverifiable referenced file aborts backup or restore.

Create, download, and validate

Only the installation owner can create, download, upload, validate, restore, or delete full backups. Admin → Tools → Backups shows the BK2 version, application version, schema head, table/row/file counts, creation time, size, and recorded SHA-256.

Creation is successful only after DynoStatic can decrypt and validate the new archive. Upload validates before retaining the file and validates the protected stored bytes a second time. Passwords are never stored and cannot be recovered. Keep a downloaded archive and its password in separate protected locations.

Restore guardrails

Restore requires the archive password twice, the exact phrase RESTORE, a complete BK2 manifest, the exact current baseline head/fingerprint, every current table and file entry, and valid hashes. Historical DynoStatic backups, Panel Comments archives, BK1 development archives and future or undeclared heads are rejected before database work. The owner's one historical instance was converted offline; production contains no historical archive adapters.

The destination host keeps its own database connection, base URL, application key, SMTP/cache/filesystem settings, and infrastructure credentials. DynoStatic never overwrites the destination secrets file. Provider-backed sources restore paused and require refresh or reconnection.

Before any destructive statement, DynoStatic creates and validates exactly one encrypted pre-restore snapshot of the current installation. It stages and verifies protected uploads in a sibling directory. Database replacement, the upload-directory swap, and a restore commit marker are coordinated through a protected journal:

Without the transaction-bound commit marker, interruption recovery restores the old upload tree and rolls the database transaction back.
With the marker, recovery retains the committed database and new upload tree.
Normal traffic is unavailable until an unresolved journal is recovered or fails closed for operator attention.

On success, DynoStatic retains the pre-restore backup and old upload rollback directory for operator verification, repairs stable discussion numbers, clears caches, enumerates cleared security/transient tables, revokes all current and archived administrator sessions, and requires a new sign-in. Never unpack an archive over a live installation by hand.

Operational drill

Test create → validate → restore on a disposable installation with the same PHP, Sodium, ZIP, and MySQL/MariaDB capabilities as production. Use a different application key on the target. Confirm websites, administrators, roles, discussions, comments, reactions, reviews, form submissions, widget publications, encrypted site secrets, current and historical server-held media originals, remote-source metadata, and form attachments survive. Confirm the destination key file and host configuration are byte-for-byte unchanged, cleared-policy tables are empty, protected files remain guarded, and the pre-restore/rollback paths exist.

Also test a wrong password and an intentionally interrupted restore. If a drill fails, retain the original archive, pre-restore archive, rollback directory, operation/request ID, protected log, PHP version, database version, and extension list. Do not repeatedly restore over the only healthy copy.

Compatibility boundary

The current baseline is 202610110001. It creates the complete current database directly and accepts only archives written for that baseline and its canonical fingerprint. Historical migration ledgers are refused. New installations use configuration schema 3 and a protected instance key; historical configuration aliases and inline-key upgrades are unsupported. See Fresh baseline transition for the one-time conversion and verification record.

Current contributor restores preserve ownership, workflow versions, submissions, operations, revision provenance, captures and upload metadata. Grant and management-session hashes and key versions are cleared, and those credentials are revoked while their history remains. Browser sessions and Automation credentials also continue to clear. Restored account access requires a renewed current account session and an explicit retained owner binding; a saved address or actor snapshot grants no access. Existing proposal recovery still requires newly authenticated sessions and current owner/delegate/grant authority, including expiry and revocation.

Contributor originals use the protected contributor_upload file purpose with an exact site/upload path and mandatory payload hash and size. Restore validates contributor relationships, the same-workflow current-version pointer, entry/schema binding, workflow definition hash, and the correspondence between complete upload rows and archived private-file metadata before committing or swapping files. Original bytes retain their PHP guard and 0600 file permissions. Unsupported schema heads are refused before file restoration. These custody checks do not implement contributor workflow configuration, management endpoints or public media delivery.