Book a demo
Book a demo
Login

App workflow WordPress

Create an on-demand WordPress backup

Choose file/database scope and storage target, run a backup, and confirm completion. 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

Before changing a booking plugin, a site owner wants a fresh WordPress recovery point that includes appointments in the database and uploaded attachments.

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

Identify required data

Where
WordPress plugin settings and xCloud site
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Site ID, appointment storage, uploads, external attachments
Action
List the records and files the booking flow uses. Check whether any calendar or mail provider keeps data outside WordPress.
Expected result
A scope list for the on-demand backup.
Verify
Ask the booking owner to identify one current appointment and attachment to verify later.
If it fails
If critical data is external, record a separate export or provider recovery path.

Sources: Manage WordPress plugins

Step 2 of 5

Check destination and storage

Where
xCloud Site → Site Backup settings
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Local/remote destination, retention, free space
Action
Read the existing backup destination and file/database scope. Confirm credentials and capacity for the selected storage provider.
Expected result
A viable backup configuration before capture.
Verify
Inspect the latest successful backup and current destination status.
If it fails
If destination is disconnected or full, repair it before requesting a backup.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 3 of 5

Start one on-demand backup

Where
xCloud Site → Site Backup → Backup Now
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Named site and approved maintenance window
Action
Start Backup Now for the chosen scope. Record job ID/time and avoid simultaneous risky edits while it runs.
Expected result
A backup job for the intended site.
Verify
Watch until the row changes to Completed.
If it fails
If the job remains Running or fails, use its error detail; do not treat it as a recovery point.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 4 of 5

Inspect the artifact

Where
xCloud Previous Backups
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Completed row, timestamp, file/database indicators
Action
Open the completed row and check site, snapshot time, storage destination and scope. Compare the time to the latest booking record.
Expected result
A backup recent enough for the upcoming plugin change.
Verify
Record the completed backup identifier and whether newer appointments exist.
If it fails
If database or uploads are missing, create a corrected backup before approving the plugin change.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 5 of 5

Rehearse a safe restore check

Where
Separate WordPress target or recovery plan
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Non-production destination and sample appointment
Action
Where feasible, restore the snapshot to another approved site and verify login, a booking and its attachment. Otherwise document the untested restore risk explicitly.
Expected result
Evidence of recoverability or a known gap.
Verify
Compare sample record and media with the source baseline.
If it fails
Never overwrite the live booking database merely to test a backup.

Sources: xCloud restore a WordPress backup to another site · Site backups in xCloud · 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