Book a demo
Book a demo
Login

App workflow WordPress

Recreate a WordPress site from a stored backup

Select destination, domain, backup source, and files, then verify the recreated site. 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 former WordPress site was removed from the active site list but a stored backup remains. The owner needs to reconstruct it at a new safe hostname before considering traffic cutover.

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

Locate recoverable material

Where
xCloud backup inventory and team records
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Original site ID, backup timestamp, storage access
Action
Find the documented recreate-site option and a Completed snapshot with files and database. Record original server, domain and WordPress version.
Expected result
A viable recovery source with known age.
Verify
Check that the storage provider and snapshot are still accessible.
If it fails
If files or database are missing, inventory what must be rebuilt before site creation.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 2 of 5

Prepare the new site identity

Where
xCloud server and DNS views
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Target server, temporary hostname, site owner
Action
Choose a compatible WordPress server with capacity and a hostname that cannot conflict with the original live DNS. Arrange secure administrator credential handoff.
Expected result
A safe target for reconstructed data.
Verify
Confirm DNS does not already direct customers to the temporary host.
If it fails
If the original domain is still serving elsewhere, keep it unchanged during rehearsal.

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

Step 3 of 5

Account for missing live records

Where
External systems and business owner
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Backup cut-off, orders, members, bookings
Action
Compare snapshot time with payment, CRM or booking records created later. Export or record newer items for reconciliation after recreation.
Expected result
A known recovery gap and data owner.
Verify
Count post-snapshot records in the external source.
If it fails
If no reliable record list exists, do not promise a complete recovery.

Sources: WordPress roles and capabilities

Step 4 of 5

Recreate from backup

Where
xCloud documented recreate-site flow
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Completed snapshot, server, hostname
Action
Use the dashboard recreate-site process, review the exact backup and target inputs, then wait for site creation and restore to finish.
Expected result
A new WordPress site populated from the selected backup.
Verify
Inspect task status, files, database and WordPress admin login.
If it fails
If creation fails, keep the original backup intact and investigate the reported stage.

Sources: xCloud recreate WordPress from backup · Site backups in xCloud · xCloud agent capability boundaries

Step 5 of 5

Verify before cutover

Where
Temporary public URL and WordPress admin
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Known pages, media, test form, newer-record list
Action
Test representative content and business actions. Reconcile missing post-snapshot data, then plan DNS/SSL cutover as a separate approved change.
Expected result
A validated reconstructed site and cutover checklist.
Verify
Compare sample IDs, redirects, media and external provider results.
If it fails
If data or integrations remain incomplete, leave the temporary host isolated.

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