Pinecone workflow: back up and restore with collections

TL;DR: Pod indexes back up to collections: static, restorable copies. Serverless uses export or re-import instead. Backup and restore Pod indexes: collections 1. Create a collection from the index.

The fix

TL;DR: Pod indexes back up to collections: static, restorable copies. Serverless uses export or re-import instead. Backup and restore Pod indexes: collections 1. Create a collection from the index.

The fix

1. Create a collection from the index. It is a static copy; writes after the snapshot are not included.

1. Name collections by date and purpose (prod-2026-09-26-pre-migration) so restore picks the right one under pressure.

1. Restore by creating a new pod index from the collection. Verify stats and sample queries before cutting traffic.

1. Retain sensibly. Collections cost storage; keep the last N plus pre-change snapshots, not everything forever.

1. Before migrations (pod to serverless especially).

1. Before bulk deletes or re-embeds.

1. On a schedule for production indexes, with restores tested, not just created.

1. A backup you have never restored is a hope, not a backup. Test-restore to a scratch index quarterly.

1. Backing up the index but not the embedding model version and preprocessing code: a restore without the matching pipeline cannot be rebuilt or extended.

1. Deleting the source index the moment the collection exists: verify the collection is complete first (stats, sample fetch).

When to use this

• This covers exactly what the title says: Pinecone workflow.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Pinecone; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.