# get_storage_restore_status

Source: https://modulify.ai/docs/api/backups/get-storage-restore-status

Reads how a storage restore is going, from its status and current step to the files written back and removed so far.

- Title: Read a storage restore
- Scope: `data:read`
- Access: Read only
- Endpoint: `POST /v1/get_storage_restore_status`

With no `restoreId` it reads the newest restore of the site, and with the `_id` that `restore_storage_backup` returned it follows that one. A site that has never had a restore answers `restore` null rather than an error, and an id that is not a restore of this site answers `Storage restore was not found!`

It answers the restore row: the backup it is restoring, the mode, a `Status` of `pending`, `running`, `completed` or `failed`, and a `Phase` of `queued`, `planning`, `safety-backup`, `writing`, `removing` or `finishing` for the step it is on. Beside them sit the running counts `FilesTotal`, `FilesWritten`, `FilesFailed`, `FilesSkipped`, `FoldersWritten`, `ObjectsToRemove`, `ObjectsRemoved` and `BytesWritten`, plus `active`, which is true only while the restore is still going.

A restore runs in the background, so `restore_storage_backup` answering does not mean it finished. The tool tells the client that until `Status` reads `completed` it must say the restore is still running and never that your files are back, never to call it done from the counts alone, and to poll with a pause between calls rather than in a tight loop. Until it ends, the storage tools that change files, `create_storage_backup` and `clear_storage_backups` are refused with a `409`.

On `failed`, `Error` carries the reason to read out and `Phase` says how far it got: a failure while writing means nothing was deleted and the restore can simply be run again, while a failure after that means some files may not be back. A row left `running` long past its heartbeat is swept to `failed` when this is read. It needs only workspace membership. See [While a restore runs](https://modulify.ai/docs/editor/backups#while-a-restore-runs).

## Request

Call it with a `POST` to `https://api.modulify.ai/v1/get_storage_restore_status`, sending the inputs below as a JSON object. The token needs the `data:read` scope.

It only reads and changes nothing, so retrying it is safe.

```bash
curl -X POST https://api.modulify.ai/v1/get_storage_restore_status \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"projectId":"PROJECT_ID"}'
```

Over MCP, the same method is the [get_storage_restore_status tool](https://modulify.ai/docs/mcp/backups/get-storage-restore-status).

## Inputs

| Input | Type | Required | Description |
| --- | --- | --- | --- |
| `projectId` | string | Yes | The site whose restore should be read. |
| `restoreId` | string | No | The restore to read, from `restore_storage_backup`. Leave it out to read the newest restore of the site. |

## Response

Every call answers with the [JSON envelope](https://modulify.ai/docs/api/requests-and-responses#the-response) of `success`, `message`, `data`, `code` and `version`. `data` holds the result described above, and on a method that returns a total, `count` carries it. The [response headers](https://modulify.ai/docs/api/requests-and-responses#headers-on-every-method-call) carry the call's `X-Request-Id` and what is left of your per-minute budget in `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset`. [Errors](https://modulify.ai/docs/api/errors) explains every status code a call can answer with.