Book a demo
Book a demo
Login

Operations WordPress

Plan a WordPress disaster recovery sequence

Define decision roles, recovery point choice, target, verification tests, and communications. 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 commerce site must recover after server loss. The owner needs an order-aware sequence for server, DNS, site data, mail and payment connections.

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 recovery objectives

Where
Business owner and incident plan
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Acceptable downtime/loss, order rate, approver
Action
Define the maximum acceptable data gap and who authorizes service restoration and customer notice.
Expected result
A prioritized recovery goal.
Verify
Compare objectives with backup cadence and last rehearsal.
If it fails
If recovery point cannot meet the goal, identify reconciliation sources now.

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

Step 2 of 5

Map dependencies

Where
xCloud site/server and external providers
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Server, DNS, backup, mail, payment, CDN
Action
Draw which components must work before checkout reopens. Record owners and credential custody for each.
Expected result
An ordered dependency list.
Verify
Trace one order from browser to gateway and email.
If it fails
If an external dependency lacks access, fix it before disaster.

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

Step 3 of 5

Prepare recovery material

Where
xCloud Site Backup and order export
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Completed backup, storage provider, recent orders
Action
Verify off-server backup access and preserve a list of transactions after its timestamp. Identify a compatible destination server/site.
Expected result
A recovery set and known data gap.
Verify
Check backup scope and sample order IDs.
If it fails
If only same-server local backup exists, plan an independent copy.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 4 of 5

Rehearse isolated rebuild

Where
Quarantined WordPress target and DNS test
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Snapshot, temporary hostname, test gateway
Action
Before starting the restored application, have network/provider owners block public traffic, outbound mail, webhooks and live payments outside the restored database. Restore to that isolated target, replace credentials with sandbox values, then test login/content and checkout. Reconcile post-snapshot orders before cutover.
Expected result
A tested sequence with measured time.
Verify
Match restored data, gateway test and media without live provider effects.
If it fails
If isolation or the copy is incomplete, repair runbook before relying on it.

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

Step 5 of 5

Define cutover gate

Where
Incident owner and operational runbook
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
DNS record, payment provider, business checks
Action
Approve DNS and traffic return only after HTTPS, checkout, mail, accounts and order reconciliation pass. Assign monitoring and rollback owner.
Expected result
A business-ready recovery gate.
Verify
Have a second operator run the checklist.
If it fails
If payments or order records disagree, keep checkout paused and communicate status.

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

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