Book a demo
Book a demo
Login

App workflow WordPress

Configure scheduled WordPress backups

Choose frequency, destination, retention, and restore validation owner. 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 membership site receives account changes every day. The owner needs a scheduled WordPress backup policy that limits lost data and keeps enough versions to recover from a delayed defect.

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
Owner runbook and WordPress activity reports
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Member update frequency, maximum loss, retention need
Action
Estimate how many memberships or payments occur between backups and define a maximum acceptable recovery gap. Record how long a bad change might remain unnoticed.
Expected result
A documented cadence and retention rationale.
Verify
Review a sample week of member and order timestamps.
If it fails
If the business cannot tolerate the proposed gap, choose a shorter cadence or supplemental exports.

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

Step 2 of 5

Choose scope and destination

Where
xCloud 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
Files/database scope, remote provider, capacity
Action
Confirm both WordPress files and database are selected. Choose local and/or supported remote storage, checking provider credentials, capacity and access owner.
Expected result
A backup destination that covers the full site state.
Verify
Check the provider connection and latest stored snapshot.
If it fails
If provider access is broken, fix it before enabling a schedule.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 3 of 5

Configure native schedule

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
Daily/weekly frequency, retention, scope
Action
Set the supported frequency and retention in the xCloud dashboard, save the settings, and record the displayed next-run expectation. Do not claim MCP can set native schedule.
Expected result
A saved schedule tied to the named site.
Verify
Reopen the page and compare saved frequency, destination and scope.
If it fails
If settings do not persist, investigate plan or validation errors before relying on them.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 4 of 5

Observe an actual run

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
Expected run time and owner
Action
Wait for the first scheduled job, then inspect its terminal status, timestamp, storage and file/database scope.
Expected result
A completed automated backup.
Verify
Compare completion time with the agreed recovery objective.
If it fails
If no job appears or it fails, escalate and use an approved on-demand backup until repaired.

Sources: Site backups in xCloud · xCloud agent capability boundaries

Step 5 of 5

Test retention and restore

Where
Safe target WordPress site and runbook
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Older/newest snapshots and sample member
Action
Check that the expected old and new snapshots exist, then restore one to an isolated site and validate a representative member login without affecting production.
Expected result
Evidence that retention and recovery work together.
Verify
Record the snapshot age, restore result and any external payment/member reconciliation needed.
If it fails
If old snapshots vanished sooner than planned, revise retention before a delayed failure occurs.

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