This is the most consequential ability in the directory. It replaces the live site with the contents of a backup.
Every order, post, user, setting and upload created or changed since that backup was taken is permanently lost. There is no undo, no trash and no revision to fall back on.
Before you run it
Irreversible. The current database and files are overwritten. The call refuses without confirm: true, and that gate is the only thing between a support conversation and a week of lost orders. Take a fresh backup first with updraftplus/start-backup — then the state you are about to discard is itself recoverable, and the decision stops being one-way.
At a glance
| Ability | updraftplus/restore-backup |
| Toolset | UpdraftPlus — toolset/updraftplus |
| Group | UpdraftPlus › Restoring |
| Requires | UpdraftPlus, active on the site |
| Capability | manage_options |
| Safety | Destructive — deletes stored values, and refuses to run without confirm: true |
| Repeatable | Not idempotent — each call changes the row set, so re-running is not a no-op |
| Ships in | AcrossAI Abilities Manager 0.0.34 and later |
How it works
The response includes replaced_state: what the site looked like immediately before the restore. It is recorded deliberately, so the loss is visible and quantified rather than merely implied.
Restrict the restore with components when you only need part of a set. Restoring the uploads directory alone to recover a deleted image is a very different operation from rolling the whole database back, and conflating them is how a recovery becomes an incident.
Read the set first with updraftplus/get-backup. A set missing the component you need will restore what it has and leave you worse off than before.
Input
| Name | Type | Required | What it is |
|---|---|---|---|
id | string | Yes | Backup identifier, exactly as returned by updraftplus/list-backups. |
components | array of strings | No | Restrict the restore to these components of the set. Omit to restore all of them. |
confirm | boolean | Yes — must be true | The irreversibility gate. Without it the call is refused before anything is touched. |
What comes back
| Name | Type | What it is |
|---|---|---|
backup_id | string | The set that was restored from. |
entities | array | Which components were restored. |
job_id | string or null | The restore job, where the plugin runs one. |
replaced_state | object | What the site looked like immediately before the restore, recorded so the loss is visible. |
irreversible | boolean | Always true. Stated rather than assumed. |
note | string | Anything else worth knowing. |
success | boolean | Whether the call completed. |
message | string | A one-line summary of what happened, suitable for showing a human. |
error_code | string | Present only on failure — a stable machine-readable reason, such as a missing field, a wrong field type or an unmet confirmation. |
Example
Ask your assistant:
Restore only the uploads from Monday’s backup — someone deleted the media library.
It resolves to one call:
{
"ability": "updraftplus/restore-backup",
"parameters": {
"id": "1758672000",
"components": ["uploads"],
"confirm": true
}
}Worth knowing
- Take a backup of the current state first. It costs minutes and converts a one-way door into a reversible one.
- Use
componentswherever you can. A partial restore is almost always the smaller, safer operation. - A full restore rolls back users and settings too — including, on some sites, the credentials people are currently logged in with.
- Never run this to “see what happens”. There is no staging copy behind it.
Related abilities
- Start Backup — protect the current state first
- Get Backup — confirm the set holds what you need
- List Backups — choose the right point to return to
Get the plugins:
AcrossAI Abilities Manager · AcrossAI MCP Manager
Browse the rest: Every ability, by category