Encrypted backups and recovery
Create, verify and transfer encrypted site backups, and request a guarded restoration from the dashboard.
- Check readinessOpen Site Backups as an active God account. Confirm that backup processing is configured, enabled, and that the remote destination is available.
- Create or synchroniseRequest a manual backup or synchronise the remote inventory. Both actions queue work; the notice is not proof that an archive completed.
- Verify the archiveCheck status, recorded SHA-256, remote verification, manifest, created time and expiry. The retention window shown by the page is seven days.
- Transfer or restoreTransfer an eligible archive when needed. Restoration requires a complete, verified, unexpired archive and a deliberate confirmation with fresh MFA.
- Track completionUse Recent Operations to follow queued, running, completed or failed work. Resolve the reported failure before requesting another operation.
Access and readiness
The Site Backups page is available only to an active God account. Before requesting work, read the readiness indicators: configuration, enabled state, remote availability, destination readiness and retention. Backups are encrypted archives with a manifest and integrity hash. Do not infer that backups are healthy from a button being present; the system health page separately reports the last successful verified backup. If the readiness state says unconfigured or unavailable, stop and route the issue to the platform operator rather than repeatedly queuing work.
- Open Site Backups and inspect every readiness indicator and the displayed retention period.
- Check Recent Operations for work already queued or running before starting another run.
- If readiness is false, capture the non-secret status and escalate through the authorised operations channel.
Create and synchronise
Create requests a manual backup and Sync requests an inventory synchronisation. Each returns a queued status because a worker performs the actual work. Refresh the page and inspect the operation row until it reaches a terminal state. A completed record should include a named encrypted archive, checksum, non-empty manifest and expiry. Do not treat a queue acknowledgement, local-ready state or old record as a verified remote backup.
- Choose Create for a new manual archive, or Sync only to reconcile the remote inventory.
- Wait for the operation status to change and open the latest backup row.
- Confirm complete status, hash recorded, remote verified and a future expiry before relying on it.
Seven-day retention
The configured retention shown in the page is seven days. The displayed creation and expiry timestamps are UTC; use them when deciding whether an archive remains eligible. Expired archives are not valid restoration points. Plan recovery within the window and do not assume an archive remains available indefinitely after transfer. Keep any operational record of the backup reference in an approved restricted system, not in public documentation.
- Read the UTC creation and expiry columns for the selected archive.
- Select a recent archive that remains unexpired and has remote verification.
- If the needed point has expired, do not attempt to restore it; escalate and use the next verified recovery point.
Transfer and integrity
Transfer is available for completed, local-ready and certain failed records that have a checksum; the worker handles transfer and verification. Restoration has stricter eligibility: complete status, matching archive name, valid SHA-256, non-empty manifest, remote verification and a future expiry. The page exposes the checksum and verification state so an operator can identify incomplete or inconsistent records. Never edit metadata or attempt to replace an archive outside the managed workflow.
- Use Transfer on the intended record and wait for its operation to finish.
- Check that remote verification is recorded and that the checksum remains present.
- If transfer fails or integrity data is missing, read the failure code and escalate without bypassing eligibility checks.
Request a restoration
A restore is a high-impact queued operation, not an immediate page action. The active God user must have completed MFA within the previous ten minutes. In the confirmation dialog, provide a reason of at least twelve characters, enter the exact backup identifier and displayed production host, and accept the consequence checkbox. The server validates these values against the selected backup and configured host. A successful submission records and queues the approved request; it does not prove that the restore worker completed.
- Open Restore only for a complete, remotely verified, unexpired eligible archive and complete fresh MFA.
- Enter the reason, exact backup identifier and displayed host; tick the explicit confirmation.
- Submit once, then follow Recent Operations and the resulting status; investigate failures before any new request.
Failure handling
The page displays failure alerts, operation status and a failure code. Common causes include unavailable destination, incomplete archive metadata, failed remote verification, expired recovery point or missing fresh MFA. An in-progress operation may still be running; do not submit duplicates. System Health provides a separate last-success indicator alongside scheduler and disk status. Escalate persistent failures with the operation status and code, while keeping secrets, private endpoint values and customer data out of the report.
- Read the operation type, status, timestamp and failure code from Recent Operations.
- Check readiness and System Health for the related queue, disk, scheduler and backup indicators.
- Retry only after the cause is understood and the previous operation is terminal; report unresolved infrastructure faults.
Frequently asked questions
Does the success notice mean the backup is ready?
No. It means the request was queued. Confirm a completed record, checksum, remote verification and unexpired status.
How long is an archive retained?
The configured page reports a seven-day retention window. The expiry column is the authoritative value for each record.
Who can create or restore backups?
Only an active God account can access the page, and every mutation requires fresh MFA for that same user.
Why is Restore unavailable?
The record may be incomplete, unverified, missing a valid manifest or checksum, or expired. Restore is deliberately limited to eligible archives.
What confirmations does a restore need?
A reason of at least twelve characters, the exact backup identifier, the displayed host, an accepted consequence checkbox and fresh MFA.
Where do I see whether work finished?
Use Recent Operations on Site Backups. A queued response alone is not completion evidence.