WP OctoDocs

Backups

How a site is backed up, where the copies go, what "completed" means, and how the records are kept honest.

What a backup is

A full backup of the site — files and database — made by the worker in steps small enough for shared hosting, written as chunks with a manifest, and verified before it is called complete. A backup can be kept on the site, in the workspace's object storage, or both, and can be restored from either copy.

Schedules

The site's package sets a backup interval: none, hourly, every four, six or twelve hours, daily, weekly or monthly. A site can override it. Daily and slower schedules land in a night window (four hours from one in the morning, in the workspace's timezone) at a minute of the site's own; sub-daily ones are spread once and then run exactly one interval apart. A manual backup never moves the schedule. A change of policy reschedules from now.

A slot the platform cannot honour — the worker is unreachable, or the policy needs external storage the workspace has not configured — produces a failed backup that says why, and one retry an hour later. A policy that needs external storage is never quietly downgraded to keeping the copy on the site.

Storage policies

PolicyThe site's copyThe external copy
Local onlykeptnone
Local and externalkeptuploaded and verified
Externalreleased once the external copy is verifieduploaded and verified

External storage is an S3-compatible bucket that WP Octo configures for your workspace; ask support to set it up or change it. The site never holds its credential. The choice offered on a site or package is restricted to what the workspace has.

What "completed" means

A backup reaches completed only after the platform has verified every chunk of every copy it promised: for the external copy, one read of each object's size and checksum against what the site computed, now, rather than trusting that an upload said it succeeded. A backup whose verification fails says which chunk.

Progress and failure

The platform drives the worker step by step and continues where the last step stopped. It decides that a backup has failed from the site's own reported progress: no change for a set time is a stall, and a backup older than its ceiling is a timeout. A slow backup is not a failed one. Nothing else ends a backup except the worker saying so.

The Backups page of a site shows each backup with its state and both copies, and offers Resume for one that stopped, Check copies to reconcile now, and Sync status to ask the site. The fleet-wide Backups page lists every backup in the workspace, with Restore offered only where a restore point exists.

The records are never the proof

Every hour, and after every backup, restore and delete, the platform reconciles its records against the site and the storage: the site says whether the local copy is there; the storage says whether every chunk of the external copy is; the platform's rows are corrected to match. A copy that cannot be asked is unreachable, not missing, and still counts until an answer says otherwise. Nothing is deleted on either side by reconciliation; a leftover is a finding. A completed backup the platform did not know about — on the site, or in storage — is registered and verified before it is offered.

Deleting a backup

Deleting a backup removes both copies and the record. The site's copy is removed through the worker; the external copy from the storage.

On this page