Publishing and operating reference

Plan a recovery rehearsal before a site update

Define the recovery point, required components and acceptance sample in a separate destination.

Published October 24, 2026Updated October 24, 2026Estimated reading: 3 min

GoRun pages list and publication status in English. — Existing product interface reference, not evidence of an executed publication, restore or migration.

GoRun administration reference that does not show an executed restore — Existing product capture, not evidence of a backup or successful recovery.

A backup file is a recovery input, not a demonstrated recovery. Before a site update, rehearse how you would bring the required content and files back in a separate environment. This exercise produces a short recovery record for your own GoRun deployment. It reports no completed restore or measured recovery time; those results must come from your actual rehearsal.

1. Write the recovery question

Choose the situation you want to prepare for: a failed update, a lost data disk or an accidental content change. List what must be available afterward: content, media, the selected child theme, settings and sign-in. Name the operator and who decides whether to switch traffic. A content-only preview may answer one question while leaving other parts of the deployment outside its scope.

2. Inventory the parts that travel together

Record the application version, database location, media storage, theme directories and deployment configuration. Keep the site secret and configuration with appropriate protection. The backup guide explains that default backups omit secret.key and gorun.toml; do not assume a database archive contains them. Record external storage or services separately, because a local file cannot prove those dependencies are recoverable.

3. Select a verified recovery point

Use the verified backup and its manifest under the procedure for the installed version. Note the capture time and any gap between database and file copies. If the task needs a consistent database-and-file point, arrange the necessary pause in writes. Copy the recovery material away from the same disk and restrict access: a backup may contain data that should not be available to every editor.

4. Rehearse in a separate destination

Use a new directory and an isolated environment, preserving the live site. Follow the installed version's recovery instructions instead of improvising commands from an older screenshot. A read-only preview is useful for examining content, but it does not sign into accounts or exercise jobs and external integrations. Do not connect rehearsal services to real mail, payments or scheduled actions just to see a green status.

5. Compare an agreed sample

Inspect counts by content type and language, a long article, an internal page, an archive, images and important links. Check that the expected custom theme is selected. If your rehearsal includes sign-in or external services, document their separate test conditions and permissions. Record a missing dependency as a gap rather than silently borrowing a live credential.

Decide what the rehearsal proved

Which recovery point and application version were used?
Which content and files were checked?
What remained outside the test?
Who owns each correction?
What is the cutover and recovery decision?

Keep the observed result and repeat the affected checks after a correction. Replacing an executable does not undo a database migration. Read backup and update guidance, deployment preparation and operating responsibilities before applying this plan to a production site.