Backups

Webcore backups protect a managed WordPress site independently of Staging snapshots. A normal site backup contains the WordPress document root and a transaction-consistent MariaDB dump together with the metadata required by the managed restore/import path.

Manual backups

Use Create Backup to create a full files + database backup before a risky production change or whenever you need an immediate recovery point.

Completed backups are listed in the site's backup inventory and can be downloaded, browsed, restored or deleted from the Panel.

Scheduled backups

Automatic backups can be enabled per site. The current scheduler supports daily or weekly execution, a node-local execution time and a retention count.

The Backups page shows whether the schedule is enabled and the most recent run where available. Retention should reflect the site's recovery requirements rather than simply using the largest possible number.

Backup inventory and ownership

The hosting node inventories backups that belong to the current managed site. Backup lookup and restore do not trust arbitrary filesystem paths supplied by the browser.

Imported and transferred backups enter the same managed inventory as locally created backups and use the same restore controls.

Import a Webcore backup

A Webcore .tar.gz or .tgz archive can be uploaded into the managed backup inventory. Uploads are streamed to the hosting node and validated before import.

The Panel currently limits uploaded backup archives to 12 GB. Imported archives are rebased to the destination site's managed identity before entering inventory.

Transfer a backup between managed nodes

For migrations between centrally managed Webcore nodes, use Transfer from Node instead of downloading a backup to an operator workstation and uploading it again.

The source node streams the archive directly to the destination node using a short-lived single-use authorization. Backup archive bytes do not pass through the Panel during this transfer.

Restore scopes

Backups support several restore scopes:

• Full — restore files and database.
• Files only — restore the site files without replacing the database.
• Database only — restore the database without replacing the site files.
• Selected files — browse the archive and restore only selected paths.

Choose the narrowest restore scope that solves the problem. Restoring an entire site is unnecessary when only one known file needs to be recovered.

Restore strategy

For recovery work that can be validated first, restore the backup to Staging. This avoids making the backup itself the first production test.

See Restore backups to Staging.

When restoring production directly, use the Panel's managed restore workflow rather than unpacking archives manually into the site. A managed restore can create a safety recovery point before destructive replacement where the selected workflow supports it.

Backups versus snapshots

A backup is part of the site's backup repository and is intended for normal recovery, export and migration. A staging snapshot is a lifecycle safety point created around Staging operations such as refresh, backup restore and push-to-live.

Production safety snapshots created before a staging push are designed for immediate rollback. They do not replace the normal backup policy.

Before deleting a backup

Confirm that a newer usable recovery point exists and that the backup is not the only known-good copy of the site. Deleting a repository backup is permanent unless another copy exists elsewhere.