Solution WordPress + WooCommerce

Plan WooCommerce backup coverage

Choose backup scope and retention assumptions around orders and customer records. A restored copy contains representative orders, products and uploads.

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

Illustrative scenario, not a customer case study: A shop owner assumes the nightly files backup includes orders. A restored copy contains representative orders, products and uploads.

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

List critical WooCommerce data, files and recovery objective

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
List critical woocommerce data, files and recovery objective; exact site identity, named approver and controlled sample data.
Action
List products, uploads, customer accounts and orders that must survive recovery, plus the maximum acceptable record gap.
Expected result
The backup scope is tied to business records.
Verify
The backup scope is tied to business records. Record the observed site, account or transaction and time in the release sheet.
If it fails
If the owner cannot state data priorities, do not assume files alone are sufficient.

Sources: WordPress roles and capabilities · WooCommerce testing orders · Site backups in xCloud

Step 2 of 5

Inspect xcloud site backup schedule and storage destination

Where
xCloud Site Backup dashboard
Permissions
Named xCloud team/site administrator; confirm target and scope.
Inputs
Inspect xcloud site backup schedule and storage destination; exact site identity, named approver and controlled sample data.
Action
In xCloud Site Backup inspect schedule, destination, retention and whether files and database are covered.
Expected result
The configured policy matches the required data.
Verify
The configured policy matches the required data. Record the observed site, account or transaction and time in the release sheet.
If it fails
If database or storage destination is missing, correct it in dashboard with the owner.

Sources: Site backups in xCloud · xCloud agent capability boundaries · WooCommerce testing orders

Step 3 of 5

Run or confirm a completed backup in the dashboard

Where
xCloud Site Backup dashboard
Permissions
Named xCloud team/site administrator; confirm target and scope.
Inputs
Run or confirm a completed backup in the dashboard; exact site identity, named approver and controlled sample data.
Action
Verify the last scheduled run completed and can be accessed; take an approved manual backup if the current point is stale.
Expected result
A specific backup identifier is available for rehearsal.
Verify
A specific backup identifier is available for rehearsal. Record the observed site, account or transaction and time in the release sheet.
If it fails
If status is pending or failed, investigate the backup job before relying on it.

Sources: Site backups in xCloud · xCloud agent capability boundaries · WooCommerce testing orders

Step 4 of 5

Restore to an isolated target and inspect sample orders

Where
xCloud Site Backup dashboard
Permissions
Named xCloud team/site administrator; confirm target and scope.
Inputs
Restore to an isolated target and inspect sample orders; exact site identity, named approver and controlled sample data.
Action
Prepare a restricted separate target and isolate outbound mail, fulfillment hooks and payment credentials before loading a copied database. Then use dashboard restore and open sample products and orders.
Expected result
The copy contains representative store records without contacting customers.
Verify
The copy contains representative store records without contacting customers. Record the observed site, account or transaction and time in the release sheet.
If it fails
If media or orders are absent, correct backup scope before the next retention cycle.

Sources: Site backups in xCloud · xCloud restore backup to another site · xCloud agent capability boundaries · WooCommerce testing orders

Step 5 of 5

Document reconciliation process for newer orders

Where
WordPress public/admin views and relevant provider evidence
Permissions
Named WordPress/app administrator or business owner; use authorized test accounts.
Inputs
Document reconciliation process for newer orders; exact site identity, named approver and controlled sample data.
Action
Document the difference between backup time and latest live orders, payments and stock changes.
Expected result
The recovery plan has a replay or reconciliation method.
Verify
The recovery plan has a replay or reconciliation method. Record the observed site, account or transaction and time in the release sheet.
If it fails
Never run an in-place restore until newer paid orders have an approved disposition.

Sources: WordPress roles and capabilities · WooCommerce testing orders · Site backups in xCloud

Maintenance

Recovery decisions

  • Before restoring, compare the chosen recovery point with newer business records. An old restore point omits orders placed after it. Use the xCloud dashboard for native restore only after the owner approves target and scope; reconcile or preserve newer data first.

    Site backups in xCloud · xCloud agent capability boundaries

  • Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident.

    Site backups in xCloud · WordPress hardening handbook

AI handoff

Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.

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

  • Review a WordPress business journey app · manual

    Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.

    Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.

    WordPress roles and capabilities

  • Configure native WordPress backup and restore dashboard · manual

    Native schedule, retention and destination changes and all restores are dashboard-only.

    Checkpoint: Use Site → Site Backup. Before restoring, confirm backup, target, scope and treatment of newer records.

    xCloud agent capability boundaries

  • Restore a backup dashboard · manual

    Native and Docker restore operations are dashboard-only. An in-place Docker restore replaces current data.

    Checkpoint: Use Site → Site Backup → Previous Backups → Restore Backup (or Restore to Another Site where offered). Confirm exact target and recovery point before proceeding.

    xCloud agent capability boundaries · Back up and restore Docker apps

Copyable agent brief

Manual checkpoints

  • The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Verify the last scheduled run completed and can be accessed; take an approved manual backup if the current point is stale.
  • The business owner compares the controlled sample with this observable result: The copy contains representative store records without contacting customers.
  • Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage

Sources

Continue

Explore the next WordPress workflow