Skip to main content

Create a serverless index from a backup

When restoring a serverless index from backup, you can change the index name, tags, and deletion protection setting. All other properties of the restored index will remain identical to the source index, including cloud and region by default, dimension and similarity metric, and associated embedding model when restoring an index with integrated embedding. To restore a backup into a different region than the source index, see Restore to a different region. To create a serverless index from a backup, provide the ID of the backup, the name of the new index, and, optionally, changes to the index tags and deletion protection settings:
The example returns a response like the following:
You can create a serverless index from a backup using the Pinecone console.

Restore to a different region

The create index from backup endpoint always creates the new index in the same cloud and region as the backup. To restore a backup into a different region, use the unstable version of the create index endpoint instead. Specify the backup as source_backup_id within spec.serverless and set the target region there. The following rules apply:
  • The target region must be on the same cloud provider as the backup. Restoring to a different cloud provider is not supported.
  • The backup must be in the current Pinecone project, and the new index is created in the same project.
  • The dimension, metric, and vector_type must match the source index.
  • Restoring to a different region is not supported for BYOC indexes.
Restoring to a different region is in public preview. It is available through the unstable API version and the REST API only.
For example, the following request restores a backup of a dense index hosted in the AWS us-east-1 region into a new index in the AWS us-west-2 region:
curl
Because the backup data is copied between regions, restoring to a different region can take longer than restoring within the same region. If restoring to a different region is not yet available for the backup’s region, the request fails with a 412 Precondition Failed error.

List restore jobs

You can list all restore jobs as follows.
Up to 100 restore jobs are returned at a time by default, in sorted order (bitwise “C” collation). If the limit parameter is set, up to that number of restore jobs are returned instead. Whenever there are additional restore jobs to return, the response also includes a pagination_token that you can use to get the next batch of jobs. When the response does not include a pagination_token, there are no more restore jobs to return.
The example returns a response like the following:

View restore job details

You can view the details of a specific restore job, as in the following example:
The example returns a response like the following: