Backups

What a backup is

A backup of the site 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.

Run backup on a site's Backups page asks what to back up:

• Full — files and database.
• Database only — content, users and settings.
• Selection — only what you choose: plugins, themes, uploads, the database, or single folders, files and tables. Single folders, files and tables need a recent worker on the site; the dialog says so when the site's worker cannot do it yet.

A backup can carry a short note, shown with it in the list, and is stored where the site's storage policy says unless you choose otherwise in the dialog.

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

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.

While a backup runs, the top of the site's Backups page shows it as a row of phases — queued, database, files, upload, verify — with how far it is. You can leave the page; it keeps going.

Stop ends a backup that is still being made. The backup is marked stopped with who stopped it, the site is released for other work at once, and the site is told to stop as well; what it had made so far is not kept as a restore point. A backup that is already being copied to storage cannot be stopped: it already has a whole copy on the site.

The site's Backups page

At the top, a summary says whether the site is covered: the last backup and its age, the schedule and the next run, where the copies are kept and how many restore points there are. Below it, the list shows each backup with its type, its status, where it is stored, its size and who started it. Details opens everything about one backup, its copies and its contents; Restore… starts a restore from it; Resume/Retry and Retry Offload continue one that stopped. Check copies reconciles the records now.

The fleet-wide Backups page lists every backup in the workspace, with Restore offered only where a restore point exists.

Looking inside a backup

Details on a backup shows its contents without restoring anything: the database tables with their size, and the files one folder at a time, each folder with how many files it holds, their size and the newest change.

• For a backup with a copy in object storage, the contents are read from that copy, and every file can be downloaded on its own. Only that file is read from storage; nothing on the site is touched.
• For a backup whose only copy is on the site, the site is asked for each folder you open. The answer arrives with the site's next contact with the platform, usually within a minute, and works even for a site the platform cannot reach directly.

Tick folders, files or tables in the contents and choose Restore selection… to restore just those.

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.