Requirements and responsibilities
Use an identified Docker site with permission to manage backups. Inventory persistent volumes and any external database or object storage; an external dependency requires its own coordinated recovery plan.
Docker backup operations and storage constraints · Back up and restore Docker apps
Docker capture briefly stops the application. Agree on an interruption window and a maximum acceptable loss of newer writes with the business owner.
Docker backup operations and storage constraints · Back up and restore Docker apps
Use supported local, S3-compatible or SFTP storage. The Docker backup reference excludes Google Drive and pCloud. Adding or changing a storage provider is an account dashboard task.
Docker backup operations and storage constraints · xCloud agent capability boundaries
Illustrative situation
Illustrative scenario: an operator wants a recoverable booking application before an upgrade. Recovery is successful only when the expected records, administrator access and customer journey return, not merely when containers start.
Choose the approach
Keep a recoverable copy outside the application server where the supported storage configuration permits it. A local backup alone cannot protect against loss of that server.
Prefer a disposable recovery target when the dashboard offers a compatible restore-to-another-site path. Confirm the current options; otherwise rehearse using a disposable source application and its supported restore flow.
An in-place restore replaces current data. When newer bookings or orders matter, first decide how to preserve or reconcile them rather than assuming the backup merges with live records.
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 6
Identify the application and recoverable data
- Where
- Site overview and deployed Docker configuration
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Exact site UUID/domain, volumes, application version and external dependencies.
- Action
- List every persistent data location and determine which ones the backup covers. For Easy!Appointments include both application storage and MariaDB. Record an application-level consistency requirement for any database and its vendor guidance.
- Expected result
- A recovery inventory tied to one site and application version.
- Verify
- Compare the configured volumes and dependencies with the backup scope; record unsupported or external components separately.
- If it fails
- If coverage or consistency is unknown, stop and obtain the application-specific procedure before relying on the backup.
Sources: Easy!Appointments hosting, setup and deployment requirements · Docker backup operations and storage constraints
Step 2 of 6
Confirm storage, retention and access
- Where
- Account → Integrations → Storage Provider; Site → Site Backup → Backup Settings
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Supported provider, destination, schedule, retention and expected backup size.
- Action
- Configure any required storage provider in the account dashboard. Choose the supported destination and backup settings for this Docker site. Review retention against the recovery objective and available capacity before saving.
- Expected result
- A deliberate backup policy with a reachable destination.
- Verify
- Read back the saved settings and confirm access to the selected provider without copying its secrets into an agent prompt or report.
- If it fails
- If the destination is unsupported or unavailable, repair configuration or choose supported storage; do not silently substitute local-only storage.
Sources: Docker backup operations and storage constraints · xCloud agent capability boundaries
Step 3 of 6
Take the backup in the approved window
- Where
- Site → Site Backup, or a discovered authorized MCP Docker backup operation
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Exact site, destination and maintenance approval acknowledging a brief app stop.
- Action
- Notify affected operators through the agreed process, approve the interruption window, then trigger one backup. Record its identifier and follow the operation until it reaches a terminal state.
- Expected result
- A completed backup for the intended application and recovery point.
- Verify
- Inspect completion status, timestamp and selected destination. Confirm the app is reachable again after capture.
- If it fails
- If capture fails or the app does not return, investigate the reported failure and dashboard logs. A started backup is not a completed recovery point.
Sources: Docker backup operations and storage constraints · Back up and restore Docker apps
Step 4 of 6
Choose and approve the recovery target
- Where
- Site → Site Backup → Previous Backups
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Backup identifier/time, compatible target, scope, preserved newer data and isolation controls.
- Action
- Inspect the available restore controls. Select a disposable target where supported or a disposable-source rehearsal. Prevent the recovered app from sending live messages or processing real payments. For a production recovery, record newer data to preserve or reconcile and obtain approval for replacement.
- Expected result
- A specific recovery decision with known interruption and data-loss scope.
- Verify
- Read the source, backup and target aloud with the approver and verify their identities immediately before the restore.
- If it fails
- If the UI cannot provide the intended target or scope, stop and choose a supported rehearsal or recovery procedure. Do not guess a restore API.
Sources: xCloud agent capability boundaries · Back up and restore Docker apps
Step 5 of 6
Run the dashboard restore and validate data
- Where
- Site → Site Backup → Previous Backups → Restore Backup; or Restore to Another Site if offered
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Approved backup, target and recovery decision.
- Action
- Perform the selected restore through the dashboard and wait for completion. Open the application and inspect representative data known to exist at the recovery point. Check administrator access and the critical customer journey.
- Expected result
- The recovered application contains the expected data and passes its operational tests.
- Verify
- For bookings, inspect a known service/provider/appointment and test a new non-production booking. Verify external dependencies and delivery using isolated test settings.
- If it fails
- If records or functionality are missing, keep the incident open and inspect volume, version and dependency compatibility before another restore.
Sources: xCloud agent capability boundaries · Back up and restore Docker apps · Easy!Appointments hosting, setup and deployment requirements
Step 6 of 6
Record recovery evidence and restore normal operation
- Where
- Operations record and application monitoring
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Actual capture/restore times, test results, exceptions and reconciled newer records.
- Action
- Record the observed interruption, recovered timestamp, validation results and outstanding reconciliation. Restore normal external integrations only after the owner accepts the result. Assign the next backup/rehearsal review.
- Expected result
- An auditable recovery result with ownership and remaining work.
- Verify
- Confirm the live target, monitoring and booking or transaction flow before ending the maintenance window.
- If it fails
- If a business test fails, retain the incident and an explicit owner; do not report success from a green provisioning status alone.
Sources: Back up and restore Docker apps
Maintenance
Review backup completion and storage capacity on the assigned cadence. Rehearse after material application, volume or storage changes and retain the evidence with the recovery plan.
Change Docker schedules and retention through the dashboard or a discovered, approved MCP backup-settings operation. Do not run the write examples in the GET-only packaged REST fallback.
Docker backup operations and storage constraints · xCloud agent capability boundaries
Recovery decisions
Restores are manual dashboard operations. An in-place restore replaces data; confirm the chosen backup, target, acceptable interruption and reconciliation of newer records before the final action.
xCloud agent capability boundaries · Back up and restore Docker apps
Report measured recovery duration and actual recovered records from your rehearsal. This guide supplies a procedure, not a recovery-time guarantee.
AI handoff
Connect xCloud MCP in your chosen agent client and select the intended team. Discover the available tools, input schemas and granted scopes. Start with resource reads. Approve a concrete change before each write. If a required tool or permission is missing, continue in the dashboard. The packaged REST fallback accepts GET requests only; do not use it for 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
- Create and inspect Docker backups mcp · write
Backup capture briefly stops the app. Use supported local, S3-compatible or SFTP storage; the packaged REST wrapper is GET-only.
Checkpoint: Confirm site, storage, retention and the interruption window before creating a backup or changing settings. Check terminal completion.
Operation identifiers and scopes to discover
sites.docker.backup, sites.docker.backups, sites.docker.backupSettings.update
Scopes: read:sites, write:sites
Docker backup operations and storage constraints · Back up and restore Docker apps
- 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
- Add or change storage providers in the account dashboard.
- Approve replacement of current data and prepare a compatible isolated rehearsal target.
- Perform restoration in the dashboard and validate application-level records.
Feature coverage
- backup-scope (covered): Volumes and external dependencies inventoried. Identify the application and recoverable data
- storage-retention (covered): Supported destination and read-back. Confirm storage, retention and access
- interruption (covered): Approved stop and return-to-service check. Take the backup in the approved window
- restore-live-data (covered): Target and newer-data decision before replacement. Choose and approve the recovery target Run the dashboard restore and validate data
- recovery-validation (covered): Application data, business checks and evidence. Run the dashboard restore and validate data Record recovery evidence and restore normal operation