Book a demo
Book a demo
Login

Operations WordPress

Rehearse a WordPress restore without affecting production

Use a safe target and verify the selected backup and acceptance path before an incident. 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 WordPress site has never been restored since launch. The operations lead wants a rehearsal that measures recovery time and tests login and a business action without touching production.

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

Set rehearsal objective

Where
Recovery runbook and production inventory
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
RTO goal, site ID, critical business flow
Action
Choose one recent completed backup and define what must work after restoration: admin login, page, media and a safe form or order test.
Expected result
A measurable rehearsal plan.
Verify
Confirm the target time and check list with the owner.
If it fails
If no accepted recovery target exists, document that before starting.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Site backups in xCloud

Step 2 of 5

Choose isolated destination

Where
xCloud site inventory and DNS
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Disposable WordPress site, separate hostname
Action
Pick a destination with no valuable data, verify its own backup, and ensure no customer DNS points to it.
Expected result
A safe restore target.
Verify
Compare production and target site IDs aloud.
If it fails
If the destination has live data, choose another site.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Site backups in xCloud

Step 3 of 5

Quarantine the destination

Where
Target network and provider controls
Permissions
Infrastructure, network and provider owners able to quarantine the destination before its application starts.
Inputs
Mail, payment, webhook and public access routes
Action
Before restore, have infrastructure and provider owners block public traffic and outbound mail, webhook and payment access at controls the restored database cannot overwrite. Keep the destination stopped or inaccessible until confirmed.
Expected result
A restore target that cannot send live side effects as it starts.
Verify
Verify isolation from an external browser and provider test account.
If it fails
If isolation cannot be established, do not restore the production snapshot yet.

Sources: xCloud restore a WordPress backup to another site · WordPress security hardening

Step 4 of 5

Restore and time the process

Where
xCloud Previous Backups → Restore to Another Site
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Source snapshot, target ID, start time
Action
Apply the selected backup to the quarantined destination through the dashboard, recording start and terminal times. Reapply sandbox app credentials before allowing any test traffic.
Expected result
A restored, isolated test site and observed duration.
Verify
Check restore status and core content while quarantine remains active.
If it fails
If restore fails, preserve logs and backup; do not retry on production.

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

Step 5 of 5

Validate and close gaps

Where
Restored WordPress site and runbook
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Known records and limited test user
Action
Test login, content, media and representative business action. Record elapsed time, missing external data and any manual repair.
Expected result
An honest recovery result against target time.
Verify
Compare sample record IDs and snapshot age to production baseline.
If it fails
If time or data falls short, assign a corrective action and schedule another rehearsal.

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