Book a demo
Book a demo
Login

App workflow WordPress

Restore a WordPress site backup

Choose backup and restore scope, confirm overwrite impact, then test critical paths. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A production WordPress site lost a set of pages after an editor error. The owner must choose a recovery point without discarding form submissions received afterward.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Establish the loss boundary

Where
WordPress revisions and xCloud site history
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Missing pages, last known-good time, new submissions
Action
Identify whether the damage is limited to a page revision, files or database records. Record transactions created since the suspected loss.
Expected result
A precise restore need and list of newer data.
Verify
Check one unaffected page and the most recent form entry.
If it fails
If WordPress revision recovery suffices, avoid replacing the whole database.

Sources: Create WordPress pages

Step 2 of 5

Select a completed point

Where
xCloud Site Backup → Previous Backups
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Site ID, snapshot time, files/database scope
Action
Choose a Completed backup preceding the error. Inspect its time, destination and included scope against the missing content.
Expected result
A candidate snapshot with known data gap.
Verify
Compare snapshot time with the last good page and first new submission.
If it fails
If the point is too old or lacks database, review another backup or a narrower repair.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 3 of 5

Preserve current state

Where
xCloud Backup Now and form export
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Current entries, uploads, backup destination
Action
Create a current-state backup and export post-snapshot form records or other live data that may be lost. Note external provider state.
Expected result
An evidence copy and reconciliation list.
Verify
Wait for the current backup to finish and count exported entries.
If it fails
If the current backup fails, pause the destructive restore and secure the data another way.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 4 of 5

Restore under control

Where
xCloud Site Backup restore dialog
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Selected snapshot, exact target, approved scope
Action
With owner approval, confirm the restore preview and selected site, then apply the dashboard restore. Wait for terminal completion.
Expected result
The intended files or database return to the chosen point.
Verify
Check the restore job and compare the returned page with the snapshot expectation.
If it fails
If target or scope differs from the plan, cancel before confirmation.

Sources: xCloud restore a WordPress backup to another site · Site backups in xCloud · xCloud agent capability boundaries

Step 5 of 5

Reconcile and reopen

Where
WordPress admin and public forms
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Exported newer entries and representative test
Action
Verify pages, media, login and form delivery; reconcile newer submissions with the restored database before reopening edits.
Expected result
Recovered content with post-snapshot data accounted for.
Verify
Match record IDs and submit a harmless new form entry.
If it fails
If a newer entry is absent, import or manually reconcile from the preserved export before declaring recovery.

Sources: Create WordPress pages

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases