Book a demo
Book a demo
Login

App workflow WordPress

Restore a backup to a different WordPress site

Select source backup and target carefully, confirm the overwrite, and validate target behavior. 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 client needs to inspect an older WordPress site without disrupting the current production site. The agency will restore a completed backup into an approved separate destination.

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

Choose source and target

Where
xCloud Sites inventory
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Source site ID, candidate target, team, server
Action
Confirm the source backup belongs to the right client and choose a separate existing WordPress destination with no irreplaceable data.
Expected result
Two distinct site IDs and a disposal plan.
Verify
Have the client owner verify source and target hostnames.
If it fails
If the target contains valuable content, create or choose another isolated site.

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

Step 2 of 5

Inspect backup and target state

Where
Source Site Backup and target overview
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Completed backup ID, target backup and storage
Action
Read the source snapshot time and file/database scope. Back up the target's current state even if it appears disposable.
Expected result
A known rollback point for the target.
Verify
Check both backup rows show Completed.
If it fails
If either backup is unavailable, postpone the cross-site action.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 3 of 5

Establish pre-start isolation

Where
Target network and provider controls
Permissions
Infrastructure, network and provider owners able to quarantine the destination before its application starts.
Inputs
Mail route, payment credentials, indexing and access
Action
Before restore, have infrastructure and provider owners block public traffic plus outbound mail, webhooks and live payments at controls the restored database cannot overwrite. Keep the destination stopped until confirmed.
Expected result
A quarantined destination before data arrives.
Verify
Confirm no customer DNS points at it and no live provider can receive a test event.
If it fails
If a live integration cannot be isolated, do not start the restored site.

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

Step 4 of 5

Restore to the other site

Where
Source 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 and exact target site ID
Action
Select the documented cross-site restore, recheck the displayed destination, and approve replacement only for the intended target.
Expected result
The destination receives the selected snapshot.
Verify
Wait for the restore job to finish and inspect target site state.
If it fails
If the dialog names production or a different team, cancel immediately.

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

Step 5 of 5

Validate the recovered copy

Where
Target admin and signed-out browser
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Known page, media item and login account
Action
Before test traffic, replace restored production credentials with sandbox values while quarantine remains in place. Then open the target URL, check login, content and a harmless site action.
Expected result
A usable review copy that remains isolated.
Verify
Compare sample content with the source snapshot and confirm no production changes.
If it fails
If URL rewriting or plugins fail, repair only the copy and preserve the source backup.

Sources: Create WordPress pages · xCloud restore a WordPress backup to another site

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